Open Source dan Lisensi: Yang Perlu Diketahui Developer

"Open source" jadi istilah yang semua orang pakai tapi jarang didefinisikan dengan tepat. Buat sebagian orang, artinya kode yang bisa dibaca di GitHub. Buat yang lain, artinya free software. Buat lawyer perusahaan, artinya sederet kewajiban yang bisa memengaruhi cara produk didistribusikan.

Definisi-definisi itu nggak sama, dan bedanya penting. Repository publik tanpa lisensi bukan open source. Proyek dengan lisensi yang melarang penggunaan komersial juga bukan open source. Lisensilah yang mengubah kode sumber jadi software open source.

Panduan ini membahas sisi praktisnya: apa arti open source sebenarnya, bagaimana lisensi utama berbeda, cara memilih lisensi buat proyek kamu, dan apa yang perlu dilakukan saat memakai kode orang lain.

Disclaimer: ini gambaran teknis, bukan nasihat hukum. Kalau keputusan lisensi berdampak ke bisnis kamu, konsultasikan dengan lawyer yang paham lisensi software.

Apa arti open source sebenarnya

Open Source Initiative (OSI) memelihara Open Source Definition. Sebuah lisensi harus memenuhi kriteria di dalamnya untuk bisa disebut open source. Yang penting antara lain:

Redistribusi bebas. Kamu boleh memberikan software itu, termasuk sebagai bagian dari produk yang lebih besar.
Source code. Kode sumber harus tersedia dalam bentuk yang bisa dipakai.
Derived works. Kamu boleh memodifikasi kode dan mendistribusikan versi kamu dengan ketentuan yang sama.
Integritas source penulis. Lisensi boleh mewajibkan versi modifikasi ditandai dengan jelas, tapi nggak boleh melarang distribusinya.
Tanpa diskriminasi. Lisensi nggak boleh mengecualikan orang, kelompok, atau bidang penggunaan.
Distribusi lisensi. Hak yang sama berlaku buat siapa pun yang menerima software tanpa perlu perjanjian terpisah.
Tanpa batasan tambahan. Kamu nggak boleh menambah syarat yang membatasi hal yang sudah diizinkan lisensi.
Netral teknologi. Lisensi nggak boleh bergantung pada teknologi atau interface tertentu.

Free Software Foundation menjelaskan ide serupa lewat empat kebebasan:

Menjalankan program untuk tujuan apa pun.
Mempelajari cara kerjanya dan mengubahnya.
Mendistribusikan salinan.
Mendistribusikan versi modifikasi.

"Free" di sini berarti kebebasan, bukan harga. Kamu boleh menjual free software. Yang nggak boleh adalah mencabut kebebasan yang diberikan lisensi ke orang yang menerimanya.

Open source, free software, dan source-available

Istilahnya tumpang tindih, tapi nggak identik:

Free software adalah istilah yang lebih tua, terkait FSF dan filosofi soal kebebasan pengguna.
Open source adalah istilah yang dipopulerkan OSI, dengan penekanan pada metodologi pengembangan dan kolaborasi praktis.
Source-available berarti kamu bisa membaca source-nya, tapi lisensinya mungkin membatasi penggunaan, modifikasi, atau distribusi komersial. Source-available bukan open source.

Redis, misalnya, mengubah lisensinya pada 2024. Source-nya masih bisa dilihat, tapi ketentuan barunya nggak disetujui OSI. Itu source-available, bukan open source. Bedanya bukan sekadar semantik; itu mengubah apa yang boleh kamu lakukan secara legal.

Kenapa lisensi bukan opsional

Copyright berlaku otomatis. Begitu kamu menulis kode, kamu memilikinya, dan orang lain nggak punya hak untuk memakai, menyalin, memodifikasi, atau mendistribusikannya kecuali kamu memberi izin.

Ketentuan GitHub mengizinkan pengguna lain melihat dan melakukan fork repository publik lewat platform. Itu bukan lisensi open source. Itu nggak memberi mereka izin memakai kode kamu di produk mereka, memodifikasinya, atau mendistribusikannya ke tempat lain.

Jadi kalau kamu publish kode dan ingin orang lain memakainya, tambahkan lisensi. File lisensi bukan birokrasi; itu yang membuat niat kamu punya kekuatan legal.

Permissive vs copyleft

Sebagian besar lisensi open source masuk ke dua keluarga.

Lisensi permissive memberi sangat sedikit syarat. Kamu boleh memakai kode di software proprietary, memodifikasinya, dan mendistribusikan binary tanpa merilis source kamu sendiri. Biasanya kamu cukup mempertahankan copyright notice dan teks lisensi.

Contoh: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC.

Lisensi copyleft mewajibkan derivative work tetap memakai lisensi yang sama. Kalau kamu mendistribusikan versi modifikasi, kamu juga harus menyediakan source dengan ketentuan yang sama. Ini dirancang supaya software tetap terbuka saat berpindah tangan.

Contoh: MPL-2.0, LGPL, GPL, AGPL.

Nggak ada keluarga yang "lebih baik". Lisensi permissive memaksimalkan adopsi, terutama di perusahaan yang nggak bisa membuka kode mereka. Lisensi copyleft melindungi commons dan memastikan perbaikan kembali ke proyek. Pilihan yang tepat tergantung apa yang kamu inginkan dari proyek itu.

Lisensi yang akan sering kamu temui

MIT

MIT singkat, tua, dan sangat umum. Lisensi ini mengizinkan siapa pun memakai, menyalin, memodifikasi, menggabungkan, mempublikasikan, mendistribusikan, mensublisensikan, dan menjual software, selama mereka menyertakan copyright notice dan permission notice.

MIT nggak punya patent grant eksplisit, dan itu salah satu alasan sebagian perusahaan lebih memilih Apache-2.0. MIT juga nggak memberi hak trademark. Kamu nggak boleh memakai nama proyek untuk mengesankan bahwa fork kamu didukung proyek aslinya.

MIT adalah default yang bagus buat library kecil, tool, dan proyek yang ingin adopsi maksimal dengan friksi minimal.

Apache-2.0

Apache-2.0 permissive, tapi lebih eksplisit daripada MIT. Isinya mencakup:

Lisensi paten dari contributor.
Kewajiban mempertahankan lisensi dan file NOTICE kalau ada.
Kewajiban menyatakan perubahan signifikan di file yang dimodifikasi.
Klausul trademark yang nggak memberi hak atas merek proyek.

Patent grant adalah alasan utama perusahaan besar menyukainya. Ini mengurangi risiko contributor mengklaim paten di kemudian hari.

Apache-2.0 kompatibel dengan GPLv3, tapi nggak dengan GPLv2-only. Detail kompatibilitas ini penting saat kamu menggabungkan kode dari proyek berbeda.

BSD-2-Clause dan BSD-3-Clause

Lisensi BSD permissive dan mirip MIT. Versi dua klausul mewajibkan mempertahankan copyright notice dan disclaimer. Versi tiga klausul menambah klausul "no endorsement": kamu nggak boleh memakai nama penulis atau contributor untuk mempromosikan derivative kamu tanpa izin.

Lisensi ini umum di sistem operasi, kode networking, dan proyek yang ingin lisensi permissive sederhana dengan bahasa disclaimer yang eksplisit.

ISC

ISC secara fungsi mirip MIT tapi lebih pendek dan sederhana. Lisensi ini umum di utility kecil dan proyek yang dikelola orang yang lebih suka teks legal minimal.

MPL-2.0

Mozilla Public License 2.0 adalah jalan tengah. Copyleft-nya di level file: kalau kamu memodifikasi file yang dilindungi MPL dan mendistribusikannya, file itu harus tetap MPL. Kamu boleh menggabungkannya dengan file proprietary dalam karya yang lebih besar, selama file MPL tetap MPL.

MPL 2.0 juga menyertakan patent grant dan kompatibel dengan GPLv2-or-later, LGPL, dan AGPL lewat mekanisme secondary license.

Ini pilihan bagus buat library atau aplikasi di mana kamu ingin perbaikan pada inti tetap dibagikan, tapi nggak ingin memaksa semua file di produk yang lebih besar jadi terbuka.

LGPL

Lesser General Public License adalah copyleft lemah yang dirancang untuk library. Kamu boleh menautkan aplikasi proprietary ke library LGPL, asalkan kamu mengizinkan pengguna mengganti atau menautkan ulang library tersebut dan membagikan modifikasi yang kamu buat pada library itu sendiri.

LGPL 2.1 dan LGPL 3.0 berbeda di detail, terutama soal installation information dan combined works. Kalau kamu menyematkan library LGPL di perangkat atau produk proprietary, baca versi spesifiknya dengan teliti.

GPL-2.0 dan GPL-3.0

GNU General Public License adalah lisensi strong copyleft yang paling dikenal. Kalau kamu mendistribusikan derivative work, kamu harus melisensikan seluruh karya di bawah GPL dan menyediakan source code yang sesuai.

GPLv3 menambahkan beberapa hal dibanding GPLv2:

Patent grant eksplisit.
Aturan anti-tivoization untuk perangkat konsumen.
Kompatibilitas dengan Apache-2.0.
Bahasa yang lebih kuat soal instalasi dan hak pengguna.

GPLv2-only dan GPLv3 nggak kompatibel satu sama lain. Proyek yang menyatakan "GPL-2.0-only" nggak bisa langsung mengambil kode GPLv3. Proyek yang menyatakan "GPL-2.0-or-later" memberi kamu opsi memakai ketentuan GPLv3.

GPL nggak melarang menjual software. Yang dilarang adalah mendistribusikan binary tanpa menyediakan source dan kebebasan yang sama ke penerimanya.

AGPL-3.0

Affero GPL adalah GPLv3 plus klausul network. Kalau kamu memodifikasi software dan membiarkan pengguna berinteraksi dengannya lewat jaringan, kamu harus menawarkan source yang sesuai kepada mereka.

Ini menutup "celah SaaS" di mana perusahaan memodifikasi software GPL, menjalankannya sebagai layanan, dan nggak pernah mendistribusikan binary. Kalau kamu membangun produk hosted di atas kode AGPL, kewajibannya bisa berlaku ke kamu.

Public domain dedication

Sebagian proyek mencoba melepaskan copyright sepenuhnya:

Unlicense adalah public domain dedication yang disetujui OSI.
0BSD adalah lisensi permissive yang disetujui OSI tanpa kewajiban atribusi.
CC0 adalah public domain dedication dari Creative Commons. Banyak dipakai untuk data dan konten, tapi nggak disetujui OSI dan nggak direkomendasikan FSF untuk software.

Public domain dedication memang simpel, tapi bisa canggung di yurisdiksi yang nggak mengizinkan penulis melepaskan hak moral tertentu. Lisensi permissive sering jadi pilihan yang lebih aman.

Lisensi Creative Commons

Lisensi Creative Commons dirancang untuk karya kreatif, bukan software. CC BY dan CC BY-SA umum dipakai untuk dokumentasi, artikel, gambar, dan dataset.

Jangan pakai lisensi CC untuk kode. Lisensi CC nggak membahas paten, distribusi source, atau linking seperti lisensi software. Kalau kamu ingin lisensi konten yang permissive, CC BY 4.0 adalah pilihan yang wajar. Kalau ingin share-alike, pakai CC BY-SA 4.0.

Lisensi CC dengan NC (non-commercial) atau ND (no derivatives) bukan open source dan bukan free software. Keduanya membatasi penggunaan dengan cara yang nggak diizinkan definisi OSI.

Source-available bukan open source

Sejumlah perusahaan sekarang mempublikasikan source dengan lisensi yang terlihat terbuka tapi nggak disetujui OSI. Contoh umum:

SSPL (Server Side Public License): mewajibkan service provider merilis source seluruh stack layanan mereka. Ini nggak disetujui OSI.
Elastic License 2.0: membatasi penawaran software sebagai managed service dan penghapusan fitur license key.
BSL 1.1 (Business Source License): membatasi penggunaan produksi sampai tanggal perubahan, setelah itu berubah jadi lisensi open source.
Commons Clause: bukan lisensi mandiri, tapi batasan tambahan yang sering ditempel ke lisensi permissive untuk melarang penjualan software.

Lisensi-lisensi ini bisa jadi keputusan bisnis yang sah. Mereka cuma bukan open source. Kalau kebijakan perusahaan kamu bilang "open source only", dependency source-available perlu review terpisah.

Perbandingan singkat

Lisensi	Keluarga	Boleh dipakai di produk proprietary?	Wajib membagikan modifikasi?	Patent grant
MIT	Permissive	Ya	Tidak	Tidak eksplisit
Apache-2.0	Permissive	Ya	Tidak	Ya
BSD-3-Clause	Permissive	Ya	Tidak	Tidak eksplisit
ISC	Permissive	Ya	Tidak	Tidak eksplisit
MPL-2.0	Weak copyleft	Ya, dengan syarat	Ya, untuk file MPL	Ya
LGPL-3.0	Weak copyleft	Ya, dengan syarat	Ya, untuk library	Ya
GPL-3.0	Strong copyleft	Ya, tapi derivative harus GPL	Ya, seluruh karya	Ya
AGPL-3.0	Strong copyleft	Ya, tapi network use memicu kewajiban source	Ya, seluruh karya	Ya
Unlicense / 0BSD	Public domain-ish	Ya	Tidak	Tidak

Tabel ini ringkasan, bukan pengganti membaca lisensi. Frasa "dengan syarat" di baris copyleft itu bobotnya besar.

Cara memilih lisensi

Mulai dari hasil yang kamu inginkan.

Kamu ingin adopsi maksimal, termasuk oleh perusahaan. Pakai MIT atau Apache-2.0. Pilih Apache-2.0 kalau paten penting buat kamu atau pengguna kamu. Pilih MIT kalau kamu ingin teks terpendek dan paling familiar.

Kamu ingin perbaikan kembali ke proyek. Pakai GPL-3.0 untuk aplikasi, AGPL-3.0 untuk layanan jaringan, dan LGPL atau MPL-2.0 untuk library.

Kamu membuat library yang akan ditautkan produk proprietary. LGPL atau MPL-2.0 biasanya lebih praktis daripada GPL. Library GPL bikin banyak perusahaan mundur.

Kamu menerbitkan dokumentasi, gambar, atau data. Pakai CC BY 4.0 atau CC BY-SA 4.0. Jangan pakai lisensi software untuk prosa.

Kamu ingin bereksperimen dengan model komersial. Kamu bisa dual-license kode kamu sendiri: copyleft untuk komunitas, lisensi komersial untuk perusahaan yang nggak bisa memenuhi syarat. Ini hanya berhasil kalau kamu memegang copyright atau punya CLA yang mengizinkannya.

Alur keputusan sederhana:

Ini kode atau konten? Kalau konten, pakai CC.
Kamu ingin derivative proprietary diizinkan? Kalau ya, permissive.
Kamu ingin modifikasi dibagikan? Kalau ya, copyleft.
Ini library? Pertimbangkan LGPL atau MPL daripada GPL.
Ini layanan jaringan? Pertimbangkan AGPL.
Paten jadi perhatian? Utamakan Apache-2.0 atau lisensi dengan patent grant.

Memakai open source dengan benar

Memakai open source bukan berarti mengabaikan lisensinya. Checklist praktisnya:

Simpan teks lisensi dan copyright notice. Kalau kamu mendistribusikan binary atau salinan source, sertakan keduanya.
Hormati file NOTICE. Proyek Apache-2.0 mungkin mewajibkan kamu mempertahankan attribution notice.
Jangan mengesankan endorsement. Kamu umumnya nggak boleh memakai nama atau logo proyek untuk mempromosikan produk kamu tanpa izin.
Lacak dependency. License scanner atau tool SBOM membantu kamu melihat saat dependency transitif berubah ketentuan.
Pahami distribusi. Kewajiban GPL muncul saat kamu mendistribusikan software, bukan saat memakainya secara internal. AGPL menambahkan network use.
Jangan menghapus license header. Kalau kamu menyalin kode ke proyek kamu, pertahankan notice yang relevan.

Penggunaan komersial diizinkan oleh sebagian besar lisensi open source. "Open source" bukan berarti "non-komersial". Ini juga bukan berarti "tanpa dukungan" atau "gratis"; perusahaan menjual support, hosting, dan layanan di sekitar software open source setiap hari.

Mitos yang sering muncul

"MIT berarti aku nggak perlu atribusi." Bukan. MIT mewajibkan kamu menyertakan copyright notice dan permission notice. Kamu nggak harus mengiklankan proyeknya, tapi kamu nggak boleh menghapus notice-nya.

"GPL berarti aku nggak boleh menjual produk." Kamu boleh menjualnya. Kamu hanya harus menyediakan source dan kebebasan yang sama ke penerima.

"Copyleft itu anti-bisnis." Banyak perusahaan membangun bisnis sukses di atas software copyleft. Kewajibannya soal menjaga kode tetap terbuka, bukan mencegah pendapatan.

"Open source lebih aman." Open source memungkinkan lebih banyak orang memeriksa kode, tapi pemeriksaan nggak dijamin terjadi. Keamanan tergantung maintenance, review, dan cara proyek dipakai.

"Lisensinya bisa diganti kapan saja." Hanya kalau kamu memegang copyright atau punya izin dari setiap contributor. Ini alasan banyak proyek memakai CLA atau DCO sejak awal.

Kalau kamu mengelola proyek

Beberapa kebiasaan bikin urusan lisensi membosankan, dan itu tujuannya:

Tambahkan file LICENSE berisi teks lisensi lengkap.
Tambahkan bagian lisensi singkat di README.
Pakai identifier SPDX di metadata package dan, opsional, di header source:

SPDX-License-Identifier: MIT

Tentukan apakah maksudnya GPL-2.0-only atau GPL-2.0-or-later, dan konsisten.
Simpan file NOTICE kalau kamu memakai dependency Apache-2.0.
Tambahkan aturan kontribusi. DCO ringan; CLA memberi lebih banyak fleksibilitas untuk relicensing di masa depan.
Kalau kamu menerima kontribusi, pastikan lisensi inbound-nya jelas. "Inbound = outbound" adalah default yang umum.

Kalau waktu maintenance kamu terbatas, pilih lisensi yang nggak akan kamu sesali dalam lima tahun. Mengubahnya nanti jauh lebih sulit daripada memilihnya dengan hati-hati sekarang.

Penutup

Open source bukan satu hal tunggal. Ini kumpulan izin yang didukung hukum copyright, dan lisensi adalah tempat izin itu hidup. Memahami beda permissive, weak copyleft, strong copyleft, dan source-available sudah cukup untuk menghindari sebagian besar kejutan.

Buat sebagian besar proyek kecil, MIT atau Apache-2.0 adalah jawaban yang tepat. Untuk library yang akan disematkan perusahaan, LGPL atau MPL-2.0 sering lebih realistis daripada GPL. Untuk layanan yang ingin perbaikannya dibagikan, AGPL adalah alat yang dirancang untuk itu.

Baca lisensinya sebelum kamu bergantung padanya. Pertahankan notice saat memakai kode. Dan kalau kamu menerbitkan sesuatu yang ingin dipakai orang lain, tambahkan lisensi. Repository publik tanpa lisensi cuma repository publik.