Lisensi Open Source: GPL, MIT, Apache, dan SPDX untuk Developer

Salah satu keputusan yang paling sulit dibatalkan datang setelah kode ditulis: lisensi mana yang Anda tempelkan di repository. Salah memilih berarti Anda tidak bisa menarik kode itu kembali tanpa izin penulis lain. Artikel ini membandingkan GPL, MIT, dan Apache-2.0 berdasarkan teks lisensinya, lalu menunjukkan cara mencatat lisensi dengan identifier SPDX yang benar.

Ringkasan

• Permissive memberi hak pakai luas; copyleft mewajibkan karya turunan tetap bebas.
• Apache-2.0 memberi lisensi paten yang otomatis berakhir bila Anda menggugat paten.
• GPL-3.0 mensyaratkan seluruh karya turunan berlisensi GPL, bukan hanya berkas aslinya.
• AGPL-3.0 menambah satu kewajiban: pengguna lewat jaringan harus mendapat akses ke source.
• SPDX punya 740 entri; 32 identifier sudah deprecated, termasuk GPL-3.0.

Copyleft dan Permissive: Dua Filosofi

Bedanya bukan soal banyaknya klausul, melainkan satu pertanyaan: apakah penerima bebas menutup kode Anda di dalam produk tertutup?

Permissive menjawab ya. Anda wajib mempertahankan hak cipta dan pemberitahuan lisensi, setelah itu penerima bebas memakai kode di aplikasi proprietary, menjualnya, dan memodifikasinya tanpa membuka sumbernya.

Copyleft menjawab tidak. GPL-3.0 Pasal 5(c) menyatakannya langsung:

You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.

Kata kuncinya the entire work, as a whole. Bukan hanya berkas yang Anda ubah, melainkan karya gabungan secara utuh. Namun GPL tetap membedakan agregat dari karya gabungan. Klausul agregat menyatakan bahwa sebuah kompilasi disebut agregat bila memuat karya terpisah yang bukan perpanjangan karya berlisensi, dan “Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate”. Inilah alasan GPL tidak otomatis menyelimuti semua yang ada di satu folder atau satu container image.

Dua Lisensi Permissive yang Paling Sering Dipakai

MIT

Teks MIT hanya satu paragraf. Intinya dimulai dari “Permission is hereby granted, free of charge, to any person obtaining a copy of this software”, dan satu-satunya syarat adalah mempertahankan pemberitahuan hak cipta dan lisensi.

Saya menyukainya karena sifatnya: hanya satu syarat, dan syarat itu mudah dipenuhi. Kekurangannya jelas: teks itu tidak menyebut hak paten sama sekali. Berbeda dengan Apache-2.0, lisensi MIT tidak memberi license to practice yang tegas, sehingga cakupannya bisa diperdebatkan oleh pihak yang berbeda.

Satu catatan yang sering terlewat: FSF sendiri tidak menyarankan sebutan “MIT License”. Organisasi MIT telah menerbitkan banyak lisensi berbeda, sehingga nama itu ambigu; FSF lebih memilih sebutan Expat License atau X11 License. Dalam praktik, “MIT” tetap dipahami hampir semua orang, jadi risikonya rendah.

Apache-2.0

Apache-2.0 punya dua kekuatan yang tidak dimiliki MIT.

Pertama, klausul paten. Pasal 3 memberi “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license”, lalu menambahkan aturan pembatalan: “If You institute patent litigation against any entity … alleging that the Work or a Contribution … constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.” Kalau seseorang mencoba jebakan paten, lisensi paten mereka padam. Inilah alasan FSF merekomendasikan Apache-2.0 di atas permissive longgar lainnya.

Kedua, Pasal 4 memberi empat syarat redistribusi yang konkret: berikan salinan lisensi, beri tanda jelas pada berkas yang diubah, pertahankan semua pemberitahuan hak cipta dan paten, dan reproduksi isi berkas NOTICE bila ada. Pasal 6 menegaskan lisensi ini tidak memberi hak atas merek dagang.

Copyleft: GPL, LGPL, AGPL, dan MPL

Tabel di atas menyortir lisensi berdasarkan rekomendasi FSF, sedangkan tangga berikut mengurutkannya menurut luas kewajiban yang menyertainya. Perhatikan bahwa urutan itu tidak sama dengan urutan “ketat”: Apache-2.0 tetap permissive, hanya saja ia membawa klausul paten yang tidak dimiliki MIT.

AGPL layak dibedakan karena satu klausul yang tidak dimiliki GPL biasa. AGPL-3.0 Pasal 13 mewajibkan, jika Anda memodifikasi program, versi modifikasi Anda “prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version”.

Ini menutup celah SaaS. Pada GPL biasa, meng-hosting aplikasi di server Anda tidak dianggap sebagai “penyampaikan”, sehingga aplikasi proprietary yang menutup sumbernya tetap sah secara lisensi.

MPL-2.0 mengambil arah lain. Copyleft-nya berhenti di tingkat berkas: hanya berkas MPL yang Anda ubah yang wajib tetap terbuka, bukan seluruh aplikasi. Klausul 3.3 membuat berkas MPL dapat digabung dengan GPLv2, LGPLv2.1, atau AGPLv3, dengan syarat berkas MPL itu sendiri tetap dapat diperoleh dalam bentuk aslinya. Artinya penggabung boleh menolak dan memberi tahu lewat keterangan “Incompatible With Secondary Licenses” bila memang tidak mau memakai jalur tersebut. Praktisnya, pengguna kombinasi itu boleh memakai modul MPL apa adanya, atau melisensikan seluruh karya turunannya ke bawah GNU GPL.

SPDX: Cara Mencatat Lisensi dengan Benar

Manifest proyek seperti package.json, Cargo.toml, atau metadata paket hampir selalu memakai SPDX identifier, bukan teks bebas. SPDX License List berisi 740 entri; versi 3.29.0 dirilis 2026-09-16.

Masalah paling sering adalah identifier yang sudah deprecated. Saya memvalidasi daftar itu terhadap dataset resmi:

MIT                    VALID
Apache-2.0             VALID
GPL-3.0-only           VALID
GPL-3.0-or-later       VALID
MPL-2.0                VALID
GPL-3.0                DEPRECATED
LicenseRef-Proprietary NOT IN LIST

Ada 32 identifier deprecated, termasuk GPL-2.0, GPL-3.0, AGPL-3.0, LGPL-2.1, dan varian GPL-3.0+. Penyebabnya GPL-3.0 lama tidak menjelaskan apakah penerima boleh naik ke versi GPL berikutnya, sehingga digantikan dua identifier eksplisit: GPL-3.0-only (hanya versi 3) dan GPL-3.0-or-later (versi 3 atau yang lebih baru). Itu bukan perbedaan teknis, melainkan perbedaan hak yang sangat besar bagi pengguna.

Sebaliknya, BSD, Apache 2.0, dan MIT License bukan SPDX identifier yang sah meski paling sering diketik manusia. Untuk lisensi internal perusahaan, bentuk LicenseRef- memang bukan anggota SPDX list karena memang disediakan untuk lisensi custom di luar daftar.

Kompatibilitas: Aturan Praktis

FSF mengelompokkan lisensi ke dalam dua kubu, GPL-compatible dan GPL-incompatible. Beberapa kombinasi berikut sering disalahpahami.

Perhatikan baris ketiga. Banyak proyek menulis GPLv2 tanpa frasa “atau versi berikutnya”, lalu tidak bisa dipakai bersama GPLv3 meski sangat mungkin niatnya begitu. Menulis GPL-2.0-or-later sejak awal menghilangkan ambiguitas ini.

Praktik: Menempelkan dan Memeriksa Lisensi

Tempelkan teks lisensi penuh di berkas LICENSE di root repository. Bila sebagian proyek punya lisensi berbeda, letakkan berkas lisensi di direktori masing-masing, bukan hanya memberi tahu dalam README.

Saya menguji ini di repository sementara. LICENSE berisi teks Apache-2.0 penuh, NOTICE, dan docs/LICENSE-MIT ter-commit bersama. Berkas lisensi yang hanya berisi satu baris Copyright otomatis ditandai perlu ditinjau manual, karena penerima tidak bisa tahu ketentuan apa yang berlaku di sana.

Untuk memeriksa dependensi, klasifikasi berdasarkan isi file LICENSE. Hasil audit atas 26 modul di module cache Go lokal:

Tidak ada GPL atau AGPL di sana, jadi tidak ada kontaminasi copyleft. Tapi percayai hasil seperti ini dengan hati-hati. Versi pertama klasifier saya melaporkan 4 modul GPL, dan itu salah. go-simpler.org/musttag dan go-simpler.org/sloglint sebenarnya MPL-2.0, karena klausul secondary-license MPL menyebut “GNU General Public License” di dalam teksnya sendiri.

Aturannya sederhana: periksa MPL, AGPL, dan LGPL sebelum GPL, atau lebih baik lagi pakai detektor SPDX daripada grep.

Kesimpulan

Mulailah dari satu pertanyaan: apakah Anda masih tenang ketika kode ini dipakai di dalam produk closed-source? Kalau ya, Apache-2.0 memberi perlindungan paten dan syarat redistribusi yang jelas. Kalau Anda justru ingin memastikan perubahan Anda tetap terbuka, GPL-3.0 dengan frasa -or-later adalah pilihan paling aman. Apa pun pilihan Anda, catat identifier SPDX yang valid, tempelkan teks lisensi penuh, dan audit dependensi dengan alat yang benar.

Satu peringatan terakhir: artikel ini menjelaskan mekanisme dan istilah, bukan nasihat hukum. Untuk kasus komersial yang berisiko tinggi, konsultasikan ke profesional hukum.

Status default: artikel ini ditulis sebagai draft: true dan belum dipublikasikan.