Jelajahi filosofi perangkat lunak bebas Richard Stallman, Proyek GNU, dan GPL—serta bagaimana gagasan itu mengubah lisensi, hak pengembang, dan open source.

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.
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.
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.
“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.
Perangkat lunak bebas didefinisikan oleh empat izin dasar:
Kebebasan‑kebebasan ini tentang agensi: Anda bukan hanya konsumen alat—Anda bisa menjadi peserta yang dapat memverifikasi, menyesuaikan, dan memperbaikinya.
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.
Pikirkan hidangan restoran.
Itulah inti: perangkat lunak bebas soal kebebasan yang dibutuhkan pengguna untuk tetap mengendalikan komputasinya.
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.
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.
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.
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.
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.
Sebuah sistem operasi bukan satu program—itu seluruh tumpukan. GNU berupaya membuat semua bagian sehari‑hari yang Anda butuhkan untuk membuat komputer berguna, termasuk:
Dalam istilah sederhana: GNU membangun pipa, kabel, dan sakelar—bukan sekadar satu alat saja.
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.”
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 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.
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.
Anggap itu sebagai aturan yang mengikuti kode:
Tujuannya mencegah pola yang dikhawatirkan Stallman: seseorang mengambil kerja komunitas, memperbaikinya, lalu mengunci perbaikan itu.
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.
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.
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:
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.
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.
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.
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.
Di bawah GPL, Anda bisa:
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.
Hak‑hak itu datang dengan kewajiban saat Anda mendistribusikan perangkat lunak:
Kewajiban ini bukan jebakan—mereka adalah mekanisme yang menjaga kolaborasi agar tidak berubah menjadi ekstraksi satu arah.
Tim harus memperlakukan kepatuhan lisensi seperti kebersihan rilis. Lacak:
SBOM sederhana dan daftar periksa rilis yang dapat diulang dapat mencegah sebagian besar masalah sebelum pengacara terlibat.
Di tingkat kode, “perangkat lunak bebas” dan “open source” sering menggambarkan banyak proyek yang sama. Perbedaannya lebih tentang mengapa berbagi itu penting.
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.
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.
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.”
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.
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.
Beberapa model terbukti:
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.
Pilihan lisensi dapat membentuk siapa yang menangkap nilai:
“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.
Sebelum mengadopsi atau menggantungkan produk pada proyek FOSS, tanyakan:
GPL dan “FOSS” sering dibicarakan, tapi beberapa mitos berulang membuat hal rumit—terutama bagi tim yang hanya ingin merilis produk tanpa melanggar lisensi.
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).
Membuka kode bisa membantu keamanan, tapi itu bukan jaminan. Proyek open source bisa:
Keamanan datang dari pemeliharaan aktif, audit, pengungkapan bertanggung jawab, dan praktik operasional yang baik—bukan sekadar label lisensi.
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.
Pedoman praktis: kewajiban biasanya terpicu pada distribusi.
Saat itu penting, dapatkan penilaian tepat berdasarkan bagaimana kode digabungkan dan didistribusikan—bukan hanya asumsi.
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.
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:
Pertanyaan ini penting karena lisensi menetapkan ketentuan hukum, tetapi mereka tidak otomatis menciptakan pengambilan keputusan yang sehat.
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.
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.
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.
Jika ragu, putuskan berdasarkan tujuan: adopsi (permisif) vs timbal balik (copyleft) vs timbal balik ramah perpustakaan (copyleft lemah).
LICENSE di root repo (salin teks lisensi lengkap).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.
Buatlah membosankan dan dapat diulang:
Untuk perbandingan lebih rinci, lihat /blog/choosing-an-open-source-license dan /blog/gpl-vs-mit-vs-apache.
“Perangkat lunak bebas” berarti kebebasan, bukan harga.
Program bisa saja berharga $0 namun tetap tidak bebas jika Anda tidak dapat memeriksa, mengubah, atau membagikannya. Perangkat lunak bebas berfokus pada hak untuk menjalankan, mempelajari, mengubah, dan mendistribusikan perangkat lunak yang Anda andalkan.
Definisi ini didasarkan pada empat izin:
Jika salah satu dari ini hilang, pengguna kehilangan kontrol dan kolaborasi menjadi lebih sulit.
Karena Anda tidak dapat secara realistis mempelajari atau memodifikasi perangkat lunak tanpa akses ke kode sumber.
Akses kode sumber memungkinkan:
Copyleft menggunakan undang-undang hak cipta untuk mewajibkan “bagikan serupa” saat Anda mendistribusikan ulang.
Anda boleh menggunakan, mengubah, dan bahkan menjual perangkat lunak, tetapi jika Anda mendistribusikan versi yang dimodifikasi, Anda harus memberikan penerima kebebasan yang sama (biasanya dengan merilis kode sumber terkait di bawah lisensi yang sama).
GPL memberikan hak luas (menggunakan, mempelajari, memodifikasi, membagikan) dan meminta timbal balik saat ada distribusi.
Jika Anda mendistribusikan biner yang dilindungi GPL, Anda umumnya harus:
Seringkali, tidak.
Untuk perangkat lunak GPL, kewajiban biasanya muncul pada saat distribusi. Jika Anda memodifikasi kode GPL untuk penggunaan internal dan tidak memberikan salinan ke pihak di luar organisasi Anda, umumnya Anda tidak perlu memublikasikan perubahan tersebut.
(Kasus khusus bisa ada—anggap ini sebagai pedoman umum, bukan nasihat hukum.)
Tergantung pada bagaimana kode digabungkan.
Secara umum:
Saat hal ini penting, peta pola integrasi yang sebenarnya sebelum melakukan rilis.
Mereka menargetkan kekhawatiran yang berbeda:
Pilih berdasarkan apakah Anda menginginkan timbal balik kuat (GPL) atau timbal balik yang ramah perpustakaan (LGPL).
Biasanya tidak di bawah GPL.
Jika Anda menjalankan perangkat lunak GPL di server Anda sendiri dan pengguna hanya berinteraksi melalui jaringan, umumnya Anda tidak sedang “mendistribusikan” salinan, jadi kewajiban berbagi sumber GPL biasanya tidak terpicu.
Jika Anda ingin penggunaan melalui jaringan mengharuskan pembagian sumber, lihat AGPL dan evaluasi dengan teliti untuk model penyebaran Anda.
Ya—banyak perusahaan memonetisasi perangkat lunak bebas/terbuka melalui layanan dan pengiriman, bukan dengan membatasi hak pengguna.
Model umum meliputi:
Pilihan lisensi memengaruhi strategi: permisif dapat memaksimalkan adopsi; copyleft dapat mencegah fork tertutup dan mendukung model monetisasi berbasis timbal balik.