Jenis-Jenis Lisensi Software: Penjelasan Lengkap

Apa Sebenarnya Lisensi Software Itu

Lisensi software adalah instrumen hukum yang memberikan izin spesifik dan terdefinisi untuk menggunakan, memodifikasi, mendistribusikan, atau berinteraksi dengan suatu software; izin ini diterbitkan oleh pihak yang memegang hak cipta atas software tersebut. Poin awal ini patut direnungkan sejenak, karena hal ini menjelaskan sesuatu yang sering mengejutkan banyak orang saat pertama kali mengenal lisensi software, yaitu secara bawaan, menurut hukum hak cipta, tidak ada seorang pun yang memiliki hak untuk menyalin, memodifikasi, atau mendistribusikan ulang software milik orang lain. Lisensi bukanlah pembatasan yang ditambahkan di atas kebebasan dasar untuk melakukan apa pun yang kita inginkan terhadap kode yang kita temukan—lisensi justru merupakan pemberian izin yang spesifik dan disengaja yang menciptakan kebebasan yang sebenarnya kita miliki. Ketiadaan lisensi sama sekali biasanya berarti kita tidak memiliki hak hukum untuk melakukan apa pun terhadap kode tersebut selain sekadar menjalankannya sebagaimana disediakan sejak awal—itu pun jika diizinkan.

Inilah alasan mengapa ketentuan lisensi sangatlah penting, baik dalam satu arah maupun arah sebaliknya. Lisensi yang restriktif membatasi apa yang boleh kita lakukan dibandingkan dengan apa yang sebenarnya dilarang sepenuhnya oleh hukum hak cipta. Lisensi yang permisif memberikan kebebasan yang jauh lebih besar daripada ketentuan hukum standar. Kombinasi spesifik antara izin yang diberikan, kewajiban yang ditetapkan, dan pembatasan yang dipertahankan itulah yang sebenarnya membedakan satu lisensi dengan lisensi lainnya—bukan sekadar gagasan samar dan informal seperti "terbuka" (open) versus "tertutup" (closed), yang—seperti akan dijelaskan pada bagian-bagian selanjutnya—sangat tidak menggambarkan keragaman nyata yang ada di dalam kategori-kategori luas tersebut.

Lisensi Software Proprietary

Lisensi software proprietary—yang terkadang disebut sebagai lisensi sumber tertutup (closed-source)—merupakan model lisensi software tradisional yang secara historis mendominasi industri, serta tetap menjadi standar bagi sebagian besar aplikasi desktop komersial, software perusahaan (enterprise), dan produk konsumen. Dalam lisensi proprietary, kode sumber software sama sekali tidak disediakan bagi pengguna, dan lisensi tersebut hanya memberikan serangkaian izin yang terbatas dan didefinisikan secara spesifik—biasanya berupa hak untuk menginstal dan menjalankan software pada sejumlah perangkat tertentu, dengan batasan yang melarang rekayasa balik (reverse engineering), redistribusi, atau modifikasi.

Dokumen yang secara konkret menetapkan ketentuan-ketentuan ini bagi sebagian besar software konsumen dan bisnis adalah End User License Agreement, yang secara umum disingkat sebagai EULA—yaitu teks panjang yang muncul saat proses instalasi, yang sebagian besar pengguna lewati begitu saja tanpa membacanya. EULA biasanya merinci secara tepat jumlah perangkat atau pengguna yang dicakup oleh lisensi, apakah lisensi tersebut bersifat permanen atau berbasis langganan, larangan tegas terhadap rekayasa balik atau dekompilasi software, batasan tanggung jawab vendor jika software menyebabkan kerugian atau kehilangan data, serta kondisi spesifik yang memungkinkan lisensi tersebut dicabut sepenuhnya.

Lisensi proprietary memberikan kendali penuh kepada vendor software atas distribusi, penetapan harga, dan pengembangan produk, serta melindungi rahasia dagang yang sangat berharga dan keunggulan kompetitif yang mungkin akan terungkap jika kode sumber dasarnya dipublikasikan. Sebagai konsekuensinya, dari sudut pandang pengguna maupun ekosistem yang lebih luas, terdapat kurangnya transparansi yang nyata (kita tidak dapat memverifikasi secara independen apa yang sebenarnya dilakukan oleh software tersebut, termasuk apakah software itu mengumpulkan data dengan cara yang mungkin tidak kita duga), ketergantungan penuh pada vendor untuk pembaruan, perbaikan bug, dan dukungan berkelanjutan, serta—jika vendor menghentikan dukungan produk sepenuhnya atau gulung tikar—tidak adanya jalur hukum bagi komunitas untuk mengambil alih pemeliharaan secara mandiri, karena sejak awal tidak ada pihak di luar perusahaan asli yang memiliki hak hukum untuk mengakses atau memodifikasi kode sumber dasarnya.

Apa yang Membuat Lisensi Benar-benar "Open Source"

Sebelum membahas lisensi open source secara spesifik, penting untuk memahami apa sebenarnya yang membuat sebuah lisensi memenuhi syarat sebagai open source dalam pengertian yang ketat, bukan sekadar memiliki kode sumber yang kebetulan dapat dilihat publik di suatu tempat. Open Source Initiative (OSI) memiliki definisi formal yang diakui secara luas, dan sebuah lisensi harus memenuhi beberapa kriteria khusus untuk mendapatkan sertifikasi open source yang sesungguhnya, yaitu software harus dapat didistribusikan ulang secara bebas tanpa royalti, kode sumber harus disediakan (bukan hanya binary hasil kompilasi), modifikasi dan karya turunan harus diizinkan, serta lisensi tersebut tidak boleh mendiskriminasi bidang penggunaan tertentu ataupun kategori orang atau organisasi tertentu.

Perbedaan ini penting karena istilah "source available" dan "open source" sering kali—dan tak jarang secara sengaja—disamakan dalam materi pemasaran, padahal keduanya benar-benar merupakan hal yang berbeda. Sebuah perusahaan dapat memublikasikan kode sumbernya secara terbuka di GitHub namun menyertakan lisensi yang melarang penggunaan komersial atau melarang penggunaan software tersebut untuk membangun produk pesaing—dan lisensi semacam itu, terlepas dari seberapa transparan kode sumbernya, tidak memenuhi definisi formal open source dari OSI karena adanya diskriminasi terhadap bidang penggunaan tertentu. Perbedaan ini dibahas lebih lanjut pada bagian mengenai lisensi source-available di bagian lain panduan ini, namun hal ini perlu ditekankan sejak awal, karena banyak sekali kebingungan nyata di bidang ini yang bermula dari anggapan bahwa "kode dapat dilihat publik" sama artinya dengan "open source", padahal keduanya merupakan klaim yang berbeda secara substansial maupun hukum.

Lisensi Open Source yang Permisif

Lisensi permisif adalah kelompok lisensi open source yang lebih longgar dan tidak terlalu membatasi. Lisensi ini memberikan hak yang sangat luas—untuk menggunakan, memodifikasi, dan mendistribusikan ulang software, termasuk sebagai bagian dari produk berpemilik (proprietary)—dengan kewajiban yang relatif minimal bagi siapa pun yang melakukannya.

Lisensi MIT kemungkinan besar merupakan lisensi open source yang paling banyak digunakan di dunia, yang dihargai khususnya karena keringkasan dan kesederhanaannya, di mana lisensi ini memberikan izin yang pada dasarnya tidak terbatas untuk menggunakan, menyalin, memodifikasi, menggabungkan, menerbitkan, mendistribusikan, melisensikan ulang, dan bahkan menjual salinan software tersebut. Satu-satunya syarat penting adalah bahwa pemberitahuan hak cipta asli dan teks lisensi harus disertakan dalam setiap salinan substansial atau bagian dari software tersebut. Tidak ada persyaratan apa pun agar modifikasi yang kita buat dirilis secara publik, dan tidak ada pula persyaratan bahwa produk yang lebih besar yang memuat kode berlisensi MIT harus bersifat open source.

Lisensi Apache 2.0 memberikan izin yang sama luasnya dengan Lisensi MIT, namun dengan dua tambahan yang sangat penting, khususnya dalam konteks komersial dan perusahaan. Lisensi ini mencakup pemberian hak paten secara eksplisit—kontributor secara tegas melisensikan paten apa pun yang mereka miliki yang mau tidak mau akan dilanggar oleh kontribusi mereka sendiri; hal ini secara signifikan melindungi pengguna hilir dari risiko litigasi paten tertentu yang sama sekali tidak ditangani oleh Lisensi MIT. Lisensi ini juga mengharuskan setiap modifikasi pada berkas berlisensi Apache didokumentasikan dan ditandai secara jelas sebagai perubahan, yang meningkatkan transparansi mengenai apa yang sebenarnya diubah dari versi asli tanpa mengharuskan kode yang telah dimodifikasi tersebut dirilis secara publik.

Lisensi BSD (yang memiliki beberapa varian khusus, terutama versi 2-klausa dan 3-klausa) secara fungsional sangat mirip dengan Lisensi MIT dalam hal kebebasan yang diberikannya. Namun, versi 3-klausa memiliki tambahan ketentuan yang melarang penggunaan nama proyek asli atau nama kontributornya untuk mempromosikan produk turunan tanpa izin tertulis khusus sebelumnya—sebuah perlindungan terbatas dan spesifik agar merek proyek tidak digunakan untuk menyiratkan adanya dukungan yang sebenarnya tidak pernah diberikan.

Hal yang menyatukan semua lisensi permisif ini adalah prinsip dasar bahwa lisensi-lisensi tersebut pada dasarnya tidak membebankan kewajiban apa pun terkait bagaimana karya turunan tersebut dilisensikan di kemudian hari. Sebuah perusahaan dapat mengambil kode berlisensi MIT atau Apache, mengintegrasikannya secara langsung ke dalam produk komersial berpemilik yang sepenuhnya tertutup, dan tidak pernah merilis satu baris pun dari kode hasil pengembangan mereka sendiri—dan hal ini sepenuhnya serta secara eksplisit diizinkan berdasarkan ketentuan lisensi-lisensi tersebut; inilah alasan utama mengapa lisensi-lisensi itu menjadi pilihan standar yang paling dominan untuk infrastruktur, library, dan perangkat open source yang secara khusus ditujukan agar dapat diadopsi secara komersial seluas mungkin.

Lisensi Copyleft: Kuat dan Lemah

Mekanisme inti copyleft adalah pemanfaatan sifat pembatas bawaan dalam hukum hak cipta—yaitu fakta bahwa tanpa lisensi, tidak ada pihak yang memiliki hak untuk menyalin atau memodifikasi suatu karya sama sekali—secara khusus untuk menjamin kebebasan yang berkelanjutan, alih-alih membatasinya sebagaimana lazimnya dalam model software berpemilik (proprietary). Lisensi copyleft memberikan hak luas untuk menggunakan, memodifikasi, dan mendistribusikan ulang software, namun disertai dengan ketentuan khusus yang disengaja, yaitu jika kita mendistribusikan versi yang telah dimodifikasi—atau dalam beberapa kasus, karya lebih besar yang memuat kode berlisensi tersebut—kita wajib merilis karya hasil modifikasi itu dengan ketentuan lisensi yang sama, serta menyediakan kode sumbernya bagi siapa pun yang menerimanya. Istilah umum untuk menggambarkan prinsip ini, yang dicetuskan oleh gerakan software bebas (free software movement), adalah bahwa copyleft memastikan kebebasan software bersifat "melekat"; kebebasan tersebut terus terbawa ke setiap karya turunan, sehingga mencegah pengembang hilir untuk mengubah status kode menjadi tertutup (private) dan menghalangi pengguna berikutnya mendapatkan kebebasan yang sama seperti yang diberikan oleh lisensi aslinya.

Lisensi copyleft yang kuat (strong copyleft) menerapkan ketentuan ini secara luas; memodifikasi kode—atau dalam beberapa penafsiran, bahkan menautkannya secara erat dalam program yang lebih besar—akan memicu kewajiban untuk merilis karya gabungan hasil akhirnya di bawah ketentuan copyleft yang sama. Lisensi copyleft yang lemah (weak copyleft) menerapkan prinsip dasar yang serupa namun dengan cakupan yang lebih terbatas; kewajiban copyleft biasanya hanya berlaku khusus untuk modifikasi pada berkas kode berlisensi itu sendiri, sementara kode tersebut secara eksplisit diizinkan untuk digunakan sebagai library dalam aplikasi yang lebih besar dengan lisensi terpisah (termasuk aplikasi yang sepenuhnya berpemilik), tanpa mengharuskan aplikasi besar tersebut untuk tunduk pada ketentuan copyleft yang sama.

Mengenal Lebih Dalam Keluarga Lisensi GPL

GNU General Public License, yang secara umum disingkat GPL, adalah lisensi copyleft kuat yang paling dikenal dan memiliki signifikansi historis tinggi. Lisensi ini awalnya disusun oleh Richard Stallman dan Free Software Foundation (FSF) secara khusus untuk menuangkan prinsip-prinsip filosofis gerakan software bebas ke dalam bentuk lisensi nyata yang memiliki kekuatan hukum.

Berdasarkan ketentuan GPL, jika kita mendistribusikan software yang memuat kode berlisensi GPL, karya gabungan yang dihasilkan tersebut juga wajib dilisensikan di bawah GPL, dan kode sumber lengkapnya harus disediakan bagi siapa saja yang menerimanya. Kewajiban ini berlaku khusus untuk kegiatan distribusi; menjalankan kode GPL yang telah dimodifikasi semata-mata untuk keperluan internal—tanpa pernah mendistribusikan software hasil modifikasi tersebut kepada pihak di luar organisasi kita—tidak memicu kewajiban apa pun menurut standar GPL untuk merilis modifikasi kita ke publik. Hal ini sering kali mengejutkan banyak orang yang baru pertama kali mengenal lisensi tersebut.

GNU Lesser General Public License, atau LGPL, adalah padanan lisensi copyleft lemah yang dirancang khusus untuk pustaka library software. Lisensi ini mengizinkan aplikasi berpemilik untuk melakukan penautan dengan library berlisensi LGPL tanpa mengharuskan aplikasi tersebut tunduk pada kewajiban copyleft GPL. Namun, lisensi ini tetap mewajibkan agar setiap modifikasi yang dilakukan secara langsung terhadap library berlisensi LGPL tersebut dirilis dengan ketentuan LGPL yang sama jika modifikasi itu didistribusikan. Perbedaan ini dibuat agar perlindungan copyleft tetap praktis diterapkan pada library dasar yang memang dibutuhkan oleh software berpemilik, tanpa secara efektif memaksa setiap aplikasi yang menggunakan library tersebut untuk menjadi software open source sepenuhnya sebagai dampak sampingan yang tak terelakkan.

GNU Affero General Public License, atau AGPL, memperluas cakupan kewajiban copyleft GPL standar untuk menangani skenario yang tidak tercakup sepenuhnya oleh GPL asli, yaitu software yang dijalankan sebagai layanan jaringan, bukan didistribusikan sebagai aplikasi tradisional yang diinstal di perangkat pengguna. Di bawah GPL standar, sebuah perusahaan dapat mengambil kode berlisensi GPL, memodifikasinya secara ekstensif, dan menjalankan versi modifikasi tersebut sebagai layanan web yang digunakan jutaan orang setiap hari, tanpa pernah secara teknis "mendistribusikan" software tersebut dalam pengertian tradisional—sehingga, jika ditafsirkan secara ketat, perusahaan tersebut tidak memiliki kewajiban untuk merilis modifikasi yang telah mereka buat. AGPL menutup celah khusus ini—yang terkadang disebut sebagai "celah SaaS"—dengan mewajibkan agar pengguna yang berinteraksi dengan aplikasi berlisensi AGPL melalui jaringan juga diberikan akses ke kode sumber yang telah dimodifikasi, meskipun secara teknis software tersebut tidak pernah didistribusikan kepada mereka sebagai salinan yang dapat diinstal dengan cara konvensional.

Lisensi Domain Publik dan Lisensi yang Setara dengan Domain Publik

Software yang benar-benar berada dalam domain publik sama sekali tidak dilindungi oleh hak cipta; artinya, siapa pun dapat menggunakan, memodifikasi, atau mendistribusikan ulang software tersebut untuk tujuan apa pun, tanpa batasan dan tanpa kewajiban untuk mencantumkan atribusi. Dalam praktiknya, menempatkan karya software modern secara resmi dan jelas ke dalam domain publik yang sesungguhnya merupakan hal yang rumit secara hukum di banyak yurisdiksi. Hal ini dikarenakan hukum hak cipta di sejumlah negara tidak menyediakan mekanisme hukum yang jelas dan diakui secara universal yang memungkinkan pencipta untuk melepaskan hak cipta mereka secara sukarela dan tidak dapat ditarik kembali sepenuhnya.

CC0, yang dikembangkan oleh Creative Commons khusus untuk mengatasi celah hukum ini, berfungsi sebagai pernyataan dedikasi yang setara dengan domain publik: lisensi ini melepaskan semua hak cipta dan hak terkait sejauh yang diizinkan oleh hukum di yurisdiksi tertentu, serta menyertakan ketentuan lisensi publik cadangan untuk yurisdiksi di mana pelepasan hak secara penuh dan tanpa syarat tidak dimungkinkan secara hukum. Hal ini memastikan bahwa dampak praktisnya tetap konsisten, terlepas dari hukum hak cipta yurisdiksi mana yang berlaku. The Unlicense memiliki fungsi yang serupa secara garis besar, yakni secara eksplisit mendedikasikan software ke domain publik dengan ketentuan cadangan yang setara bagi yurisdiksi yang tidak mengakui pelepasan hak penuh sebagai tindakan yang sah secara hukum.

Lisensi-lisensi ini mewakili tingkat kebebasan (sifat permisif) teoretis yang paling maksimal—benar-benar tidak ada lagi batasan yang dapat diterapkan melampaui titik ini. Lisensi ini umumnya dipilih oleh developer yang ingin membuat pernyataan yang sangat jelas dan tidak ambigu bahwa mereka tidak menetapkan syarat apa pun terkait bagaimana karya mereka digunakan di kemudian hari; langkah ini bahkan melampaui persyaratan atribusi minimal yang ada pada Lisensi MIT.

Lisensi Source-Available: Kategori Baru yang Menjadi Perdebatan

Sebuah kategori lisensi yang benar-benar baru—dan di sebagian kalangan komunitas open source menjadi subjek perdebatan aktif—telah muncul sebagai respons khusus terhadap ketegangan bisnis yang sulit diatasi dengan baik oleh lisensi open source tradisional. Situasi ini melibatkan perusahaan yang mengembangkan software open source sejati, namun kemudian menyaksikan penyedia layanan cloud besar mengambil software tersebut, menyediakannya sebagai layanan berbayar yang menjadi pesaing, dan meraup porsi nilai komersial yang sangat besar tanpa memberikan kontribusi berarti kembali ke proyek aslinya.

Lisensi source-available membuat kode sumber proyek dapat dilihat secara publik—sering kali di platform yang sama dengan tempat proyek open source tradisional di-hosting, seperti GitHub—namun menerapkan batasan komersial khusus yang tidak memenuhi definisi formal Open Source Initiative (OSI). Batasan yang paling umum adalah larangan menawarkan software tersebut sebagai layanan hosting yang menjadi pesaing. Business Source License (BSL, atau juga disebut BUSL), yang digunakan oleh perusahaan seperti MariaDB dan CockroachDB, adalah contoh yang dikenal luas: lisensi ini biasanya membatasi penggunaan untuk tujuan produksi atau komersial selama periode awal tertentu, namun menyertakan ketentuan bawaan di mana lisensi tersebut secara otomatis beralih menjadi lisensi open source tradisional yang sesungguhnya (umumnya Apache License atau GPL) setelah jangka waktu tertentu berlalu. Server Side Public License (SSPL), yang digunakan oleh MongoDB, menerapkan pendekatan yang serupa namun berbeda; lisensi ini secara khusus mewajibkan siapa pun yang menawarkan software berlisensi tersebut sebagai layanan untuk juga merilis kode sumber lengkap dari seluruh infrastruktur layanan pendukungnya—bukan sekadar software database-nya saja. Ini merupakan kewajiban yang jauh lebih luas dan lebih berat dibandingkan ketentuan layanan jaringan (network-service provision) dalam AGPL yang sebenarnya sudah mencakup cakupan luas.

Lisensi-lisensi ini benar-benar menjawab masalah bisnis nyata dan sah yang terus dihadapi oleh perusahaan-perusahaan yang sejak awal berbasis open source. Namun, secara sengaja dan berdasarkan definisinya, lisensi ini bukanlah open source menurut definisi formal OSI. Penggunaan istilah "open source" untuk mendeskripsikan lisensi-lisensi ini—sesuatu yang terkadang dilakukan perusahaan dalam materi pemasaran dan memicu kekesalan nyata di kalangan pendukung open source—telah menjadi sumber ketegangan dan perbedaan pendapat yang nyata serta berkelanjutan di dalam komunitas software yang lebih luas.

Lisensi Ganda dan Open Source Komersial

Lisensi ganda adalah sebuah model bisnis—bukan sekadar jenis lisensi tunggal—di mana perusahaan merilis basis kode yang sama persis di bawah dua lisensi yang benar-benar berbeda secara bersamaan, sehingga pengguna dapat memilih lisensi mana yang sesuai dengan situasi spesifik mereka. Pola yang umum digunakan adalah menawarkan software tersebut secara gratis di bawah lisensi copyleft yang ketat seperti GPL, sembari menyediakan lisensi komersial berbayar terpisah bagi perusahaan yang ingin memasukkan kode tersebut ke dalam produk berpemilik tanpa terikat oleh kewajiban copyleft GPL.

Model ini berhasil karena secara langsung dan sengaja memanfaatkan sifat restriktif copyleft sebagai daya tawar komersial yang nyata: perusahaan yang ingin menggunakan software tersebut dalam produk komersial closed-source tidak dapat melakukannya secara sah hanya dengan lisensi GPL gratis, karena tindakan tersebut akan mewajibkan mereka untuk turut merilis kode sumber produk berpemilik mereka sendiri—sehingga mereka memilih untuk membayar lisensi komersial terpisah yang secara eksplisit membebaskan mereka dari kewajiban tersebut. Selama sebagian besar sejarahnya, MySQL merupakan salah satu contoh paling terkenal dari penerapan model bisnis lisensi ganda ini; pola serupa pun masih umum ditemukan saat ini di kalangan banyak perusahaan yang berbasis pada open-source-native yang mencari jalan berkelanjutan untuk meraih pendapatan komersial nyata, tanpa harus sepenuhnya meninggalkan penawaran open source yang tersedia secara bebas.

Lisensi Perangkat Lunak di Era Data Pelatihan AI

Sebuah dimensi baru dalam lisensi software—yang terus berkembang pesat dan aktif—telah muncul sebagai respons langsung terhadap praktik penggunaan kode sumber dalam jumlah besar yang tersedia untuk umum guna melatih model AI pembuat kode. Ini adalah isu yang pada dasarnya tidak pernah menjadi persoalan lisensi nyata sebelum hadirnya generasi asisten pemrograman berbasis AI saat ini.

Persoalan lisensi spesifik di sini adalah apakah tindakan melatih model AI menggunakan kode sumber yang tersedia untuk umum dan dilindungi lisensi—serta kemudian membuat model terlatih tersebut menghasilkan kode baru yang mungkin sangat mirip, atau dalam beberapa kasus yang terdokumentasi terbukti mereproduksi potongan materi pelatihan asli secara persis (kata demi kata)—benar-benar mematuhi ketentuan spesifik dari lisensi awal kode tersebut. Hal ini terutama berlaku untuk lisensi copyleft yang membebankan kewajiban nyata dan spesifik terhadap karya turunan. Persoalan ini belum memiliki penyelesaian yang pasti, baik secara hukum maupun teknis, dan telah menjadi ranah perdebatan serta sengketa aktif yang melibatkan litigasi, perhatian regulator, dan diskusi industri, di mana orang-orang yang berwawasan luas dan rasional pun dapat sampai pada kesimpulan yang sangat berbeda.

Beberapa proyek open source mulai mengambil langkah proaktif dengan secara eksplisit menambahkan ketentuan khusus ke dalam lisensi mereka sendiri—atau ke dalam dokumen kebijakan pendamping yang terpisah dan jelas—untuk mengatur apakah pelatihan model AI menggunakan kode mereka diperbolehkan atau tidak berdasarkan ketentuan lisensi proyek yang ada. Ini merupakan kategori pertimbangan lisensi yang benar-benar baru; para developer yang merilis software open soruce saat ini semakin dituntut untuk memikirkan hal tersebut secara langsung dan eksplisit—sesuatu yang bahkan tidak menjadi pertimbangan berarti bagi siapa pun yang merilis software lima tahun yang lalu.

Cara Memilih Lisensi yang Tepat

Jika tujuan utamanya adalah adopsi seluas mungkin—termasuk oleh perusahaan komersial yang mungkin ingin memasukkan kode tersebut ke dalam produk closed-source (sumber tertutup) mereka tanpa kewajiban tambahan apa pun—maka lisensi permisif seperti MIT atau Apache 2.0 umumnya merupakan pilihan awal yang tepat. Inilah alasan mengapa sebagian besar infrastruktur, library, dan developer tools open source yang fundamental menggunakan lisensi permisif sebagai standar, alih-alih lisensi copyleft.

Jika tujuan utamanya adalah memastikan software—serta karya turunan apa pun yang dibangun di atasnya di masa depan—tetap benar-benar bebas dan terbuka untuk selamanya (dengan secara eksplisit mencegah skenario di mana seseorang mengambil kode tersebut, meningkatkannya secara substansial, lalu menutup akses komunitas luas terhadap peningkatan tersebut), maka lisensi copyleft seperti GPL adalah pilihan yang lebih selaras secara filosofis maupun praktis. Hal ini dilakukan dengan menerima konsekuensi nyata bahwa beberapa perusahaan mungkin enggan mengadopsi software tersebut justru karena adanya kewajiban copyleft itu.

Jika tujuan utamanya adalah membangun bisnis berbasis open source yang berkelanjutan dan menghasilkan pendapatan, namun tetap berpartisipasi secara bermakna serta memberi manfaat bagi ekosistem open source yang lebih luas, maka lisensi ganda atau salah satu model lisensi source-available yang lebih baru dapat menjawab ketegangan komersial tersebut secara lebih langsung dibandingkan lisensi yang murni permisif atau murni copyleft.

Dan jika software tersebut bersifat proprietary (milik eksklusif) dan komersial—di mana model bisnisnya benar-benar bergantung pada pengendalian distribusi dan perlindungan rahasia dagang yang nyata—maka EULA (End User License Agreement) tradisional tetap menjadi pilihan standar yang tepat, dengan ketentuan khusus dalam perjanjian tersebut yang disesuaikan secara cermat dengan model bisnis yang sedang dijalankan.

Jadi, lisensi software bukanlah kategori yang seragam atau monolitik. Kebiasaan umum untuk membagi seluruh ranah ini ke dalam dikotomi sederhana antara "proprietary" (kepemilikan eksklusif) dan "open source" justru mengaburkan perbedaan praktis yang bermakna—perbedaan yang sebenarnya menentukan apa yang boleh dan tidak boleh kita lakukan secara hukum terhadap suatu kode tertentu.