Richard Stallman dan Perangkat Lunak Bebas: Ide yang Mengubah Kode

Mengapa Richard Stallman Masih Penting

Perangkat lunak bukan hanya produk teknis—itu juga seperangkat izin. Siapa yang bisa menjalankannya, menyalinnya, membagikannya pada teman, memperbaiki bug, atau membuat sesuatu yang baru di atasnya? Pertanyaan‑pertanyaan itu dijawab lebih banyak oleh lisensi daripada oleh kode. Saat perangkat lunak menjadi pusat pekerjaan, komunikasi, dan riset, aturan tentang “apa yang boleh Anda lakukan” mulai membentuk inovasi sama pentingnya dengan fitur.

Richard Stallman (sering disingkat “RMS”) penting karena ia membuat aturan‑aturan itu tak dapat diabaikan. Pada awal 1980‑an, ia melihat sebuah pergeseran: semakin banyak program didistribusikan tanpa kode sumber, dan pengguna semakin sering diberi tahu mereka hanya boleh menggunakan perangkat lunak sesuai ketentuan pihak lain. Stallman memandang ini bukan sebagai ketidaknyamanan kecil, melainkan kehilangan kebebasan pengguna dan pengembang—dan ia menanggapi dengan mengusulkan serangkaian prinsip dan alat hukum yang jelas untuk melindungi kebebasan tersebut.

Apa yang dibahas (dan yang tidak dibahas) di tulisan ini

Artikel ini fokus pada gagasan Stallman dan konsekuensi praktisnya: definisi Perangkat Lunak Bebas, Proyek GNU, copyleft, dan GNU General Public License (GPL)—serta bagaimana hal‑hal ini membentuk ekosistem open source modern dan norma lisensi perangkat lunak.

Ini bukan biografi, dan bukan pula tinjauan teknis mendalam tentang kompilasi kernel atau manajemen repositori. Anda tidak perlu latar belakang pemrograman untuk mengikuti.

Pandangan seimbang dan mudah diakses

Stallman berpengaruh sekaligus kontroversial. Tujuan di sini adalah tetap faktual dan mudah dibaca: apa yang ia perjuangkan, mekanisme hukum apa yang muncul, bagaimana bisnis dan pengembang menyesuaikan diri, dan di mana perdebatan berlanjut—agar Anda bisa melihat mengapa karyanya masih memengaruhi pilihan perangkat lunak sehari‑hari.

Apa Arti “Perangkat Lunak Bebas” Sebenarnya

“Perangkat lunak bebas” mudah disalahpahami karena kata bebas terdengar seperti soal harga. Richard Stallman memakai kata bebas untuk maksud kebebasan—kemampuan pengguna mengendalikan perangkat lunak yang mereka andalkan.

Jika sebuah program gratis secara harga tetapi Anda tidak diperbolehkan memeriksanya, mengubahnya, atau membagikannya, program itu mungkin “gratis seperti bir” namun tidak bebas dalam pengertian yang Stallman pedulikan.

Empat kebebasan esensial

Perangkat lunak bebas didefinisikan oleh empat izin dasar:

• Kebebasan 0: Menjalankan program untuk tujuan apa pun.
• Kebebasan 1: Mempelajari bagaimana program bekerja dan mengubahnya agar melakukan apa yang Anda inginkan.
• Kebebasan 2: Mendistribusikan salinan sehingga Anda bisa membantu orang lain.
• Kebebasan 3: Mendistribusikan versi yang telah Anda modifikasi sehingga komunitas bisa mendapat manfaat.

Kebebasan‑kebebasan ini tentang agensi: Anda bukan hanya konsumen alat—Anda bisa menjadi peserta yang dapat memverifikasi, menyesuaikan, dan memperbaikinya.

Mengapa akses kode sumber tak bisa ditawar

Kebebasan 1 dan 3 mustahil tanpa akses ke kode sumber—instruksi yang bisa dibaca manusia. Tanpanya, perangkat lunak lebih mirip peralatan tersegel: Anda bisa menggunakannya, tetapi Anda tidak tahu apa yang dilakukannya, tidak bisa memperbaikinya ketika rusak, atau menyesuaikannya untuk kebutuhan baru.

Akses kode sumber juga penting untuk kepercayaan. Itu memungkinkan peninjauan independen (untuk privasi, keamanan, dan keadilan) dan membuatnya layak untuk mempertahankan perangkat lunak meskipun pengembang asli berhenti mendukungnya.

Analogi sederhana: resep vs makanan tersegel

Pikirkan hidangan restoran.

• Perangkat lunak proprietary seperti membeli hidangan siap saji yang tersegel: Anda bisa memakannya, tetapi Anda tidak tahu bahan‑bahannya, tidak bisa mengubah resep, dan tidak boleh membagikan salinan.
• Perangkat lunak bebas seperti mendapatkan resep: Anda bisa memasaknya di rumah, belajar bagaimana membuatnya, menyesuaikan untuk alergi, dan membagikan versi yang Anda perbaiki kepada teman.

Itulah inti: perangkat lunak bebas soal kebebasan yang dibutuhkan pengguna untuk tetap mengendalikan komputasinya.

Masalah yang Direspons Stallman

Sebelum “lisensi perangkat lunak” menjadi hal yang diperdebatkan banyak orang, banyak budaya pemrograman—terutama di universitas dan laboratorium riset—berjalan berdasarkan asumsi: jika Anda bisa memperbaiki alat, Anda berbagi perbaikannya. Kode sumber menyertai perangkat lunak, orang belajar dengan membaca karya satu sama lain, dan perbaikan menyebar lewat kolaborasi informal.

Dari norma berbagi ke perangkat lunak yang dikunci

Budaya itu mulai berubah seiring perangkat lunak menjadi produk tersendiri. Perusahaan (dan beberapa institusi) mulai memperlakukan kode sumber sebagai keunggulan kompetitif. Distribusi datang dengan syarat “dilarang berbagi”, kode berhenti disertakan, dan perjanjian kerahasiaan menjadi normal. Bagi pengembang yang terbiasa memecahkan masalah secara kolektif, perubahan ini tak hanya terasa merepotkan—itu terasa seperti perubahan aturan yang membuat pemecahan masalah komunitas berisiko secara hukum.

Kisah printer (sebagai contoh, bukan mitos)

Salah satu cerita asal yang sering diceritakan melibatkan sebuah printer di AI Lab MIT. Stallman menggambarkan bagaimana printer baru datang dengan perangkat lunak yang hanya didistribusikan dalam bentuk biner, tanpa kode sumber. Masalah praktisnya sederhana: lab ingin memodifikasi program untuk menangani notifikasi ketika terjadi paper jam atau mengarahkan pekerjaan dengan lebih cerdas. Di bawah norma “hacker” lama, seseorang akan menambal kode dan membagikan perbaikannya. Di sini, mereka tidak bisa—karena mereka tidak diizinkan melihat atau mengubah sumber.

Perlu diingat proporsinya: bukan berarti satu printer itu sendiri menciptakan gerakan global. Itu adalah contoh jelas dan mudah dipahami dari tren yang lebih luas—alat yang diandalkan orang menjadi tak dapat diperbaiki oleh penggunanya.

Mengapa ini memicu ide lisensi baru

Bagi Stallman, inti masalah bukan hanya akses teknis; melainkan hilangnya kebebasan untuk bekerjasama. Jika Anda tidak bisa mempelajari cara kerja program, Anda tidak benar‑benar mengendalikannya. Jika Anda tidak bisa membagikan perbaikan, komunitas terfragmentasi, dan semua orang akhirnya mengulang perbaikan secara pribadi.

Motivasi itu membentuk inovasi lisensi yang muncul. Alih‑alih mengandalkan itikad baik atau norma informal, Stallman menginginkan aturan yang mempertahankan kemampuan untuk menggunakan, mempelajari, memodifikasi, dan membagikan perangkat lunak—agar kolaborasi tidak bisa dicabut begitu sebuah program menjadi bernilai komersial.

Proyek GNU: Membangun OS Bebas

Langkah besar Stallman bukan hanya menulis manifesto—ia memulai upaya rekayasa praktis. Pada 1983 ia mengumumkan Proyek GNU, dengan tujuan ambisius: membangun sistem operasi lengkap yang siapa pun bisa gunakan, pelajari, ubah, dan bagikan, sambil tetap kompatibel dengan Unix sehingga orang bisa menjalankan program dan alur kerja yang sudah dikenal.

Sistem lengkap, bukan satu alat

Sebuah sistem operasi bukan satu program—itu seluruh tumpukan. GNU berupaya membuat semua bagian sehari‑hari yang Anda butuhkan untuk membuat komputer berguna, termasuk:

• Kompiler (paling terkenal GCC) sehingga pengembang bisa mengubah kode menjadi program yang dapat dijalankan
• Utilitas baris perintah inti (alat dasar untuk menyalin file, mencari teks, mengelola proses)
• Perpustakaan dan alat pengembang untuk mendukung pembangunan perangkat lunak lebih lanjut
• Shell dan editor untuk benar‑benar bekerja di mesin sehari‑hari

Dalam istilah sederhana: GNU membangun pipa, kabel, dan sakelar—bukan sekadar satu alat saja.

GNU + Linux: bagaimana kebanyakan orang mengalaminya

Pada awal 1990‑an, GNU telah menghasilkan sebagian besar “userland” ini, tetapi satu bagian penting tertinggal: kernel (bagian yang mengelola perangkat keras dan sumber daya sistem secara langsung). Ketika Linux muncul pada 1991, ia mengisi celah itu.

Itulah sebabnya banyak sistem populer hari ini menggabungkan komponen GNU dengan kernel Linux—sering disebut “GNU/Linux.”

Infrastruktur sama pentingnya dengan ide

GNU mewujudkan gagasan perangkat lunak bebas dengan menciptakan basis kerja yang bisa dibangun orang lain. Filosofi menjelaskan mengapa kebebasan itu penting; GNU menghadirkan alat yang membuat kebebasan praktis, dapat diulang, dan skala‑besar.

Copyleft dalam Bahasa Sederhana

Copyleft adalah strategi lisensi yang dirancang untuk menjaga perangkat lunak tetap bebas (dari segi kebebasan) bukan hanya pada rilis pertama, tetapi juga pada versi‑versi berikutnya. Jika Anda menerima kode yang dicopyleft, Anda boleh menggunakannya, mempelajarinya, memodifikasinya, dan membagikannya—tetapi ketika Anda mendistribusikan versi yang dimodifikasi, Anda harus meneruskan kebebasan yang sama kepada orang lain.

Alat hukum yang dibangun di atas hak cipta

Copyleft terdengar seperti “anti‑hak cipta”, tetapi kenyataannya bergantung pada undang‑undang hak cipta. Penulis menggunakan hak ciptanya untuk menetapkan aturan izin dalam lisensi: “Anda boleh menyalin dan memodifikasi ini, tetapi jika Anda mendistribusikannya, Anda harus tetap menyimpannya di bawah lisensi yang sama.” Tanpa hak cipta, tidak ada mekanisme hukum untuk menegakkan kondisi tersebut.

Ide “share alike” (dengan contoh sederhana)

Anggap itu sebagai aturan yang mengikuti kode:

• Fork: Anda mem‑fork proyek yang dicopyleft, menambah fitur, dan menerbitkan fork Anda. Anda harus memublikasikan kode sumber dan mempertahankan lisensi yang sama sehingga orang lain juga bisa mem‑fork karya Anda.
• Redistribusi: Anda mengemas program dalam produk yang Anda kirimkan ke pelanggan. Anda boleh mengenakan biaya, tetapi Anda harus menyediakan sumber dan hak yang sama kepada penerima.

Tujuannya mencegah pola yang dikhawatirkan Stallman: seseorang mengambil kerja komunitas, memperbaikinya, lalu mengunci perbaikan itu.

Copyleft vs lisensi permisif

Lisensi permisif (seperti MIT atau BSD) umumnya membiarkan Anda melakukan hampir apa pun dengan kode, termasuk mendistribusikan versi yang dimodifikasi di bawah lisensi proprietary tertutup. Lisensi copyleft (seperti GNU GPL) masih mengizinkan penggunaan dan modifikasi luas, tetapi mewajibkan turunan yang didistribusikan tetap berada di bawah syarat copyleft yang sama—sehingga kebebasan dilestarikan di hilir.

Bagaimana GNU GPL Mengubah Lisensi

GNU General Public License (GPL) mengubah lisensi perangkat lunak dengan menjadikan “berbagi” sebagai aturan yang dapat ditegakkan, bukan sekadar kebaikan. Sebelum GPL, Anda bisa menerima kode sumber, memperbaikinya, lalu mengirimkan versi tertutup yang pengguna tidak bisa pelajari atau modifikasi. GPL membalik dinamika itu: ia melindungi kebebasan pengguna dengan menambahkan kondisi pada distribusi.

Apa yang diberikan GPL—dan apa yang dimintanya sebagai balasan

Secara praktis, GPL memberi pengguna hak untuk menjalankan program untuk tujuan apa pun, membaca dan memodifikasi sumber, serta membagikan versi asli atau yang dimodifikasi.

Jika Anda mendistribusikan perangkat lunak GPL (terutama dalam produk), Anda harus meneruskan kebebasan tersebut. Itu biasanya berarti:

• Menyediakan kode sumber (atau cara yang sah untuk mendapatkannya) kepada penerima
• Menyertakan teks lisensi dan mempertahankan pemberitahuan hak cipta
• Melisensikan modifikasi Anda di bawah GPL juga, sehingga pengguna hilir tidak “terkunci” dari kebebasan yang sama

Kewajiban distribusi sumber (kapan berlaku)

Kewajiban GPL terutama muncul saat Anda mendistribusikan perangkat lunak kepada orang lain—mengirimkan biner, menjual perangkat dengan perangkat lunak, atau memberikan salinan kepada pelanggan. Jika Anda memodifikasi kode GPL untuk penggunaan internal dan tidak mendistribusikannya, biasanya Anda tidak harus memublikasikan sumbernya.

“Karya turunan” dalam istilah sederhana

Anda tidak perlu teori hukum untuk mengerti intinya: jika program Anda menggabungkan kode GPL sedemikian rupa sehingga menciptakan karya gabungan (misalnya dengan meng‑link ke dalam aplikasi Anda), hasilnya biasanya diperlakukan sebagai karya turunan dan harus didistribusikan di bawah GPL. Menjalankan program GPL, atau berkomunikasi dengannya sebagai proses terpisah lewat antarmuka standar, seringkali berbeda.

Varian GPL: v2, v3, dan LGPL

GPLv2 adalah versi klasik yang banyak dipakai. GPLv3 menambahkan perlindungan seputar perjanjian paten dan “tivoisasi” (menyertakan perangkat keras yang memblokir perangkat lunak yang dimodifikasi). LGPL dirancang untuk perpustakaan: ia memungkinkan linking dari program proprietary dalam kondisi tertentu sambil menjaga pustaka itu sendiri tetap bebas.

Hak dan Tanggung Jawab Pengembang di Bawah Lisensi Bebas

Lisensi bebas (terutama GNU GPL) tidak sekadar “mengizinkan” berbagi—mereka melindungi hak untuk mempelajari, memodifikasi, dan mendistribusikan perangkat lunak dengan cara yang sulit dicabut kemudian. Bagi pengembang, itu berarti perbaikan Anda dapat tetap tersedia bagi orang lain di bawah syarat yang sama, bukan terserap ke produk tertutup tanpa cara komunitas mendapat manfaat.

Hak yang Anda peroleh

Di bawah GPL, Anda bisa:

• Bereksperimen dengan aman: membaca sumber, mengubahnya, dan menjalankan versi yang dimodifikasi.
• Membagikan karya Anda: mendistribusikan salinan program asli atau yang dimodifikasi.
• Membangun di atas perbaikan orang lain: karena penerima harus menerima kebebasan yang sama.

Inilah mengapa GPL sering disebut sebagai “timbal balik yang dapat ditegakkan.” Jika seseorang mendistribusikan program berlisensi GPL (atau karya turunan), mereka tidak bisa menambahkan pembatasan yang menghalangi pengguna hilir melakukan modifikasi dan berbagi.

Tanggung jawab yang Anda ambil

Hak‑hak itu datang dengan kewajiban saat Anda mendistribusikan perangkat lunak:

• Mempertahankan pemberitahuan hak cipta dan lisensi.
• Menyediakan (atau menawarkan) kode sumber yang sesuai saat GPL mengharuskannya.
• Menjaga lisensi tetap utuh sehingga penerima tahu hak mereka.

Kewajiban ini bukan jebakan—mereka adalah mekanisme yang menjaga kolaborasi agar tidak berubah menjadi ekstraksi satu arah.

Catatan praktis soal kepatuhan

Tim harus memperlakukan kepatuhan lisensi seperti kebersihan rilis. Lacak:

• komponen open‑source mana yang Anda kirimkan,
• versi dan lisensinya,
• di mana Anda menyediakan sumber (atau tawaran tertulis),
• dan perubahan yang Anda buat.

SBOM sederhana dan daftar periksa rilis yang dapat diulang dapat mencegah sebagian besar masalah sebelum pengacara terlibat.

Perangkat Lunak Bebas vs Open Source: Perpecahan Nilai

Di tingkat kode, “perangkat lunak bebas” dan “open source” sering menggambarkan banyak proyek yang sama. Perbedaannya lebih tentang mengapa berbagi itu penting.

Prioritas berbeda: kebebasan vs adopsi

Gerakan Perangkat Lunak Bebas (terkait dengan Richard Stallman dan Free Software Foundation) memandang kebebasan perangkat lunak sebagai isu etika: pengguna seharusnya memiliki hak untuk menjalankan, mempelajari, memodifikasi, dan membagikan perangkat lunak. Tujuannya bukan sekadar rekayasa yang lebih baik—melainkan melindungi otonomi pengguna.

Pendekatan Open Source menekankan hasil praktis: kolaborasi lebih baik, iterasi lebih cepat, lebih sedikit bug, dan keamanan yang lebih baik melalui transparansi. Pendekatan ini nyaman mempromosikan keterbukaan sebagai model pengembangan unggul tanpa menuntut sikap moral.

Mengapa “open source” populer

Pada 1998, Open Source Initiative (OSI) memopulerkan istilah “open source” agar gagasan ini lebih ramah bisnis. “Perangkat lunak bebas” sering disalahpahami sebagai “tanpa biaya”, dan beberapa perusahaan enggan dengan pesan yang dibingkai soal hak dan etika. “Open source” memberi organisasi cara mengatakan “kita bisa bekerja seperti ini” tanpa terdengar ideologis.

Lisensi sama, pembingkaian berbeda

Banyak proyek yang menyebut dirinya open source menggunakan GNU GPL atau lisensi copyleft lainnya, sementara yang lain memilih lisensi permisif seperti MIT atau Apache. Teks hukum bisa identik; cerita yang diceritakan kepada kontributor, pengguna, dan pelanggan berubah. Satu pesan: “ini melindungi kebebasan Anda,” pesan lain: “ini mengurangi hambatan dan meningkatkan kualitas.”

Panduan keputusan sederhana

Jika prioritas tim Anda adalah memastikan pengguna hilir mempertahankan kebebasan yang sama, gunakan pembingkaian perangkat lunak bebas dan pertimbangkan copyleft.

Jika prioritas Anda adalah memaksimalkan adopsi (termasuk oleh perusahaan yang mungkin tidak ingin kewajiban timbal balik), pembingkaian open source dan lisensi permisif mungkin lebih cocok.

Jika Anda menginginkan kolaborasi luas tetapi juga ingin perbaikan kembali, gunakan bahasa open source untuk pendekatan yang lebih ramah sambil memilih lisensi copyleft untuk hasilnya.

Model Bisnis dan Insentif Dunia Nyata

Perangkat lunak bebas bukan berarti “tidak ada yang dibayar.” Itu berarti pengguna memiliki kebebasan untuk menjalankan, mempelajari, memodifikasi, dan membagikan kode. Banyak perusahaan membangun pendapatan sehat di sekitar kebebasan itu—sering dengan memungut biaya untuk hal‑hal yang organisasi benar‑benar butuhkan: keandalan, akuntabilitas, dan waktu.

Bagaimana perusahaan menghasilkan uang dengan FOSS

Beberapa model terbukti:

• Dukungan dan layanan: help desk berbayar, SLA, pelatihan, audit, fitur kustom, migrasi.
• Hosting dan penawaran terkelola: menjual versi terhost di mana pelanggan membayar untuk kenyamanan, skala, backup, dan kepatuhan.
• Dual licensing: menawarkan perangkat lunak yang sama di bawah lisensi bebas (sering copyleft) dan juga lisensi komersial berbayar bagi pelanggan yang menginginkan ketentuan berbeda.
• Open core (dengan hati‑hati): mempertahankan basis yang benar‑benar bebas sambil menjual add‑on proprietary. Ini bisa berhasil, tapi juga bisa merusak kepercayaan komunitas jika bagian “bebas” terasa sengaja dibatasi.

Twist modern pada model “penawaran terkelola” adalah munculnya platform yang dengan cepat menghasilkan dan menjalankan aplikasi. Misalnya, Koder.ai adalah platform vibe‑coding yang membantu tim membangun aplikasi web, backend, dan mobile via chat—sambil tetap mendukung ekspor kode sumber. Kombinasi itu (iterasi cepat plus kepemilikan kode) cocok dengan nilai di balik kebebasan perangkat lunak: kemampuan untuk memeriksa, mengubah, dan memindahkan perangkat lunak saat dibutuhkan.

Mengapa permisif vs copyleft memengaruhi strategi

Pilihan lisensi dapat membentuk siapa yang menangkap nilai:

• Lisensi permisif (seperti MIT/Apache) memudahkan pihak lain—termasuk vendor besar—untuk menggunakan ulang kode Anda dalam produk proprietary. Itu bisa meningkatkan adopsi, tetapi mungkin mengurangi kesempatan Anda untuk memonetisasi eksklusivitas.
• Lisensi copyleft (seperti GPL) mengharuskan redistributor hilir membagikan modifikasi di bawah syarat yang sama. Itu dapat menghalangi fork tertutup dan mendukung model bisnis berbasis layanan, distribusi tersertifikasi, atau dual licensing.

“Komersial” dan “perangkat lunak bebas” bukan lawan

“Komersial” menggambarkan bagaimana ia dijual; “perangkat lunak bebas” menggambarkan hak pengguna. Perusahaan bisa menjual perangkat lunak bebas, mengenakan biaya untuk dukungan, dan tetap menghormati kebebasan perangkat lunak.

Daftar periksa keberlanjutan

Sebelum mengadopsi atau menggantungkan produk pada proyek FOSS, tanyakan:

• Apakah ada komunitas aktif (isu, rilis, review)?
• Apakah tata kelola jelas (siapa yang memutuskan, bagaimana konflik diselesaikan)?
• Apakah pendanaan terlihat (sponsor, dukungan perusahaan, yayasan)?
• Apakah beban pemelihara berkelanjutan (bus factor, tanda kelelahan)?
• Apakah praktik keamanan terdokumentasi (ritme patch, advisori)?

Kesalahpahaman Umum tentang GPL dan FOSS

GPL dan “FOSS” sering dibicarakan, tapi beberapa mitos berulang membuat hal rumit—terutama bagi tim yang hanya ingin merilis produk tanpa melanggar lisensi.

“GPL berarti public domain”

Tidak. Public domain berarti tidak ada pemegang hak cipta yang menegakkan kondisi—siapa pun bisa menggunakan karya tanpa kewajiban.

GNU GPL adalah kebalikan dari “tanpa syarat.” Penulis menjaga hak cipta dan memberi izin luas untuk menggunakan, memodifikasi, dan membagikan—tetapi hanya jika Anda mengikuti syarat GPL (paling terkenal: membagikan sumber saat mendistribusikan biner yang tercakup).

“Open source selalu aman”

Membuka kode bisa membantu keamanan, tapi itu bukan jaminan. Proyek open source bisa:

• tidak terpelihara,
• ditinjau dengan buruk,
• rentan selama bertahun‑tahun sebelum ada yang menyadarinya.

Keamanan datang dari pemeliharaan aktif, audit, pengungkapan bertanggung jawab, dan praktik operasional yang baik—bukan sekadar label lisensi.

Klaim “lisensi viral”

Orang sering menyebut GPL “viral” seolah‑olah ia menyebar tanpa kendali. Itu metafora yang bernada negatif.

Yang biasanya dimaksud adalah copyleft: jika Anda mendistribusikan karya turunan dari kode GPL, Anda harus menyediakan sumber yang sesuai di bawah GPL. Ketentuan itu disengaja: ia melestarikan kebebasan pengguna hilir. Itu bukan “infeksi”; itu syarat yang bisa Anda pilih untuk terima—atau hindari dengan menggunakan kode lain.

“Bisakah saya menggunakan kode GPL dalam aplikasi atau layanan saya?” (tingkat tinggi)

Pedoman praktis: kewajiban biasanya terpicu pada distribusi.

• Penggunaan internal: menggunakan perangkat lunak GPL di dalam perusahaan biasanya tidak memaksa Anda untuk memublikasikan perubahan.
• Mengirim aplikasi/perangkat: jika Anda mendistribusikan program berlisensi GPL (atau karya turunannya), Anda biasanya harus menyediakan sumber dan pemberitahuan lisensi.
• SaaS / layanan web: menjalankan perangkat lunak GPL di server Anda biasanya tidak memaksa pelepasan sumber ke pengguna. (AGPL dibuat untuk menutup celah ini.)

Saat itu penting, dapatkan penilaian tepat berdasarkan bagaimana kode digabungkan dan didistribusikan—bukan hanya asumsi.

Kritikan, Kontroversi, dan Perdebatan yang Berlangsung

Richard Stallman adalah sosok yang kontroversial. Mungkin untuk mengakui itu—dan tetap membicarakan pengaruh tahan lama dari gagasan dan lisensi yang terkait dengannya.

Mulailah dengan memisahkan dua percakapan: (1) debat tentang Stallman sebagai pribadi dan anggota komunitas, dan (2) dampak terukur dari prinsip perangkat lunak bebas, Proyek GNU, dan GNU GPL terhadap lisensi perangkat lunak dan hak pengembang. Yang kedua bisa dibahas dengan sumber primer (teks lisensi, sejarah proyek, pola adopsi) bahkan ketika orang sangat berbeda pendapat tentang yang pertama.

Tata kelola dan “siapa yang memutuskan?”

Salah satu kritik berulang bukan soal lisensi, melainkan tata kelola: bagaimana proyek membuat keputusan, siapa punya otoritas, dan apa yang terjadi ketika pendiri, pemelihara, dan pengguna menginginkan hal berbeda. Komunitas perangkat lunak bebas berjuang dengan pertanyaan seperti:

• Bagaimana memilih atau mengganti kepemimpinan?
• Haruskah yayasan dipimpin anggota, dewan, atau pemelihara?
• Kapan “kebebasan” bagi pemelihara bertentangan dengan kebutuhan kontributor?

Pertanyaan ini penting karena lisensi menetapkan ketentuan hukum, tetapi mereka tidak otomatis menciptakan pengambilan keputusan yang sehat.

Inklusivitas, tata krama, dan standar komunitas

Perdebatan lain berkelanjutan tentang inklusivitas dan norma komunitas: bagaimana proyek menetapkan harapan untuk perilaku yang saling menghormati, bagaimana menyelesaikan konflik, dan seberapa ramah proyek terhadap pendatang baru. Beberapa komunitas menekankan kode etik formal; yang lain memilih aturan minimal dan moderasi informal. Tidak ada pendekatan yang otomatis “benar”, tetapi trade‑off nyata dan layak dibahas tanpa serangan pribadi.

Menjaga diskusi berlandas

Jika Anda mengevaluasi warisan Stallman, bantu agar klaim dapat diverifikasi: apa yang diwajibkan GPL, bagaimana copyleft mengubah praktik kepatuhan, dan bagaimana gagasan ini memengaruhi lisensi dan institusi berikutnya. Anda bisa bersikap kritis, mendukung, atau ragu—tetaplah menjunjung presisi, rasa hormat, dan kejelasan tentang apa yang dikritik.

Inti Praktis: Memilih Lisensi dan Berkontribusi

Hadiah praktis terbesar Stallman untuk tim sehari‑hari adalah pertanyaan yang jelas: kebebasan apa yang ingin Anda jamin ke hilir? Menjawab itu membuat “pilihan lisensi” berubah dari kesan menjadi keputusan.

Pohon keputusan sederhana

• Ingin orang lain (termasuk pesaing) menggunakan ulang kode Anda dengan syarat minimal? Pilih lisensi permisif (mis., MIT, Apache‑2.0).
• Ingin perbaikan pada kode Anda tetap dapat dibagikan saat didistribusikan? Pilih copyleft kuat (mis., GNU GPL).
• Ingin pembagian berlaku terutama pada modifikasi perpustakaan, sambil membolehkan aplikasi proprietary melakukan linking? Pilih copyleft lemah (mis., LGPL, MPL).

Jika ragu, putuskan berdasarkan tujuan: adopsi (permisif) vs timbal balik (copyleft) vs timbal balik ramah perpustakaan (copyleft lemah).

Langkah praktis untuk merilis perangkat lunak secara bertanggung jawab

1. Pilih satu lisensi per proyek dan nyatakan dengan jelas di README.
2. Tambahkan file LICENSE di root repo (salin teks lisensi lengkap).
3. Tambahkan header hak cipta jika organisasi Anda mengharuskannya.
4. Dokumentasikan dependensi (langsung dan transitif penting) serta lisensinya.
5. Jika Anda mendistribusikan biner, siapkan pemberitahuan yang diperlukan, tawaran sumber (jika relevan), dan atribusi.

Jika Anda membangun produk menggunakan pengembangan berbantuan AI (termasuk platform berbasis chat seperti Koder.ai), daftar periksa ini menjadi lebih penting: Anda tetap mengirimkan dependensi nyata, artefak nyata, dan kewajiban lisensi nyata. Kecepatan tidak menghapus tanggung jawab—ia justru membuat rutinitas kepatuhan yang dapat diulang menjadi lebih bernilai.

Buat rutinitas kepatuhan internal ringan

Buatlah membosankan dan dapat diulang:

• Hasilkan SBOM selama build.
• Simpan template file notices dan perbarui saat dependensi berubah.
• Tambahkan cek lisensi ke PR/rilis (bahkan daftar periksa 10 menit pun membantu).

Untuk perbandingan lebih rinci, lihat /blog/choosing-an-open-source-license dan /blog/gpl-vs-mit-vs-apache.