Perbedaan Macam‑macam Lisensi Open Source

Open source bukan sekadar kode yang tersedia di GitHub; lisensi menentukan apa yang boleh Anda lakukan dengan kode tersebut. Di bawah ini ada cerita nyata seorang developer bernama Alya yang harus memilih lisensi untuk dua proyek berbeda. Cerita ini menambah contoh konkret dan use case tiap lisensi.

Kisah Alya

Alya baru saja selesai membuat KomponBot, sebuah library Python untuk menghasilkan akord musik secara otomatis. Ia ingin membagikannya secara gratis, tapi juga ingin perusahaan tempatnya bekerja dapat menggunakannya dalam produk komersial tanpa harus meminta izin khusus.

Untuk proyek ini, Alya memilih MIT License. Kenapa? Karena MIT sangat singkat, mengizinkan penggunaan komersial, dan tidak mengharuskan pengguna menyertakan kode sumber kembali. Use case: startup musik yang mengambil KomponBot sebagai bagian dari aplikasi berbayar, tanpa beban legal tambahan.

Selanjutnya, Alya mengerjakan SecureVault, sebuah aplikasi server‑side yang menyimpan data sensitif dengan enkripsi. Karena data tersebut bersifat kritis, Alya ingin memastikan setiap perbaikan atau audit keamanan dibagikan kembali ke komunitas, sehingga semua orang mendapat manfaat.

Ia memilih GPL v3 untuk SecureVault. GPL v3 mewajibkan setiap turunan, termasuk versi komersial, harus dirilis kembali di bawah GPL. Dengan begitu, setiap perusahaan yang menambahkan fitur pada SecureVault juga harus membuka kode tersebut, menjaga keamanan tetap transparan. Use case: perusahaan keamanan yang tidak ingin menutup‑tutup perbaikan penting.

Lisensi Permisif

• MIT – contoh di atas. Cocok untuk library yang ingin diadopsi luas, termasuk komersial. Satu baris lisensi, mudah dipahami.
• BSD (2‑clause, 3‑clause) – mirip MIT, menambahkan klausul iklan atau larangan penggunaan nama pemilik. Cocok untuk sistem operasi atau perangkat jaringan.
• Apache 2.0 – menambahkan hak paten. Contoh: Hadoop, Angular. Pilihan aman untuk perusahaan yang khawatir paten.

Lisensi Copyleft

• GPL v2 / v3 – mengharuskan semua turunan dibuka kembali. Contoh: Linux kernel, WordPress. Digunakan ketika Anda ingin semua perbaikan kembali ke komunitas.
• LGPL – memungkinkan link ke pustaka dalam software proprietary asalkan pustaka itu tetap GPL. Contoh: GTK+.
• AGPL – memperluas GPL ke layanan jaringan. Jika Anda menjalankan aplikasi di server, kode harus dibagikan ke pengguna. Contoh: MongoDB, GitLab CE.

Lisensi Lainnya

• MPL 2.0 – copyleft lemah; hanya file yang diubah yang harus dibuka. Cocok untuk proyek campuran.
• EPL 2.0 – populer di ekosistem Java/Eclipse.
• Unlicense / CC0 – menyerahkan semua hak, menempatkan karya ke domain publik.

Memilih Lisensi yang Tepat

1. Jika ingin adopsi seluas‑luas dan tidak menghalangi komersial, pilih lisensi permisif (MIT, Apache 2.0).
2. Jika ingin memastikan perbaikan kembali ke komunitas, pilih lisensi copyleft (GPL, AGPL).
3. Jika proyek mencampur kode terbuka dan proprietary, pertimbangkan LGPL atau MPL.
4. Jika hanya ingin menghilangkan semua batasan, gunakan CC0/Unlicense.
5. Periksa kompatibilitas: Apache 2.0 kompatibel dengan GPL v3, tidak dengan GPL v2 tanpa tambahan.

Setiap lisensi memiliki poin penting yang harus disertakan di file LICENSE dan header di setiap file sumber. Jangan mencampur lisensi secara sembarangan; konflik dapat membuat proyek tidak dapat didistribusikan.