Kode GitHub dalam Produk Komersial: Lisensi dan Hal yang Perlu Diperiksa

Anda sedang membangun produk dan menemukan bagian siap pakai di GitHub: sebuah pustaka, templat, atau seluruh proyek yang melakukan persis apa yang Anda perlukan. Claude menyarankan untuk memasukkannya ke proyek Anda. Lalu Anda berhenti sejenak: kodenya tampak tersedia untuk umum, tetapi apakah Anda benar-benar boleh menggunakannya, apalagi menjual produk yang menyertakannya? Bisakah penulisnya menuntut Anda di kemudian hari?

Saya akan membahasnya secara berurutan: mengapa kode terbuka di GitHub bukan berarti mendapat izin, lisensi mana yang mengizinkan Anda menggunakan kode dan menjual produk, syarat copyleft mana yang dapat mewajibkan kode sumber bersesuaian untuk karya tercakup, serta cara memeriksa lisensi dalam satu menit sebelum menggunakan kode. Tanpa “tergantung situasinya.”

Informasi praktis tentang penggunaan Ailoot ada di dokumentasi.

Benarkah jika kode ada di GitHub, Anda boleh menggunakannya secara gratis?#

Jebakan utamanya di sini adalah kata “terbuka.” Anda bisa melihat kode sumbernya, sehingga tampaknya karena kode itu tidak disembunyikan, Anda boleh menggunakannya. Logika itu keliru. “Terbuka untuk dibaca” dan “berlisensi untuk digunakan” adalah dua hal berbeda.

Secara default, setiap karya kreatif, termasuk kode, dilindungi hak cipta sejak dibuat. Sampai penulis secara tegas memberikan izin, Anda tidak boleh menggunakannya. Begitulah GitHub menjelaskannya di halaman referensi lisensinya sendiri.

Lapisan kedua adalah GitHub sendiri. Orang mengira karena mereka menyetujui aturan GitHub dengan menerbitkan kode, mereka juga boleh menggunakan kode orang lain dari sana. Aturannya justru menyatakan kebalikannya. Dengan menjadikan repositori publik, penulis hanya mengizinkan orang lain melihat dan melakukan fork—yaitu membuat salinan di dalam GitHub sendiri. Itu tidak mengizinkan penggunaan kode dalam karya Anda sendiri.

Kata-kata kuncinya ada di kalimat terakhir: “dalam lingkup fitur GitHub” dan “hak tambahan berasal dari lisensi.” Fork tetap berada di GitHub. Begitu Anda ingin menggunakan kode itu dalam produk sendiri, apalagi menjualnya, Anda memerlukan lisensi terpisah dari penulis. Tanpa lisensi, tidak ada hak—meskipun kodenya terpampang jelas.

Apa yang menentukan apakah Anda boleh menggunakan kode orang lain?#

Semuanya bergantung pada satu berkas. Repositori yang dikelola dengan baik memuat berkas lisensi—biasanya LICENSE, kadang LICENSE.md, atau disebutkan langsung di README. Ini adalah izin dari penulis yang menyatakan ketentuan penggunaan kode tersebut. GitHub biasanya menampilkan nama lisensi di bilah sisi halaman repositori, bahkan sebelum Anda membuka berkasnya.

Agar tidak tersesat dalam bahasa hukum, ada baiknya membaca lisensi dengan menjawab tiga pertanyaan tentang situasi Anda:

1. Bolehkah Anda menggunakan kode ini dalam produk komersial yang dibayar orang?
2. Bolehkah Anda memodifikasi kode sesuai kebutuhan?
3. Apakah Anda harus membuka kode sumber produk Anda setelahnya, atau boleh tetap merahasiakannya?

Hampir semua perbedaan antar-lisensi bermuara pada jawaban berbeda untuk pertanyaan ketiga. Untuk dua pertanyaan pertama, lisensi terbuka populer paling sering menjawab “ya”: gunakan, modifikasi, jual. Namun, orang sering keliru saat menentukan apakah lisensi akan mengharuskan mereka membuka kode sendiri. Berikutnya, kita akan membahas jenis-jenis utama berdasarkan tiga pertanyaan ini.

Lisensi mana yang mengizinkan Anda menggunakan kode dan menjual produk?#

Mari mulai dengan kabar baik. Bagi orang yang membangun produk untuk dijual, pilihan terbaik adalah kelompok lisensi yang disebut lisensi permisif. Ada beberapa jenis, tetapi tiga yang paling umum adalah MIT, Apache 2.0, dan BSD. Ketiganya menjawab “ya” untuk dua pertanyaan pertama dan mengizinkan Anda tetap merahasiakan kode sumber sendiri.

Yang paling umum dan sederhana adalah MIT. Teksnya cukup satu paragraf.

Dengan kata sederhana, MIT memungkinkan Anda melakukan hampir apa saja terhadap kode, termasuk menjual produk dan tetap merahasiakan kode sumber sendiri. Satu-satunya kewajiban adalah menyertakan teks lisensi dan baris atribusi. Contohnya, Babel, .NET, dan Rails dirilis dengan lisensi MIT, jadi Anda hampir pasti pernah menggunakan kode berlisensi ini.

Apache 2.0 bekerja dengan cara serupa, tetapi menambahkan dua hal penting. Pertama, perlindungan tegas terhadap klaim paten: para penulis kode berjanji tidak akan menuntut Anda atas paten yang terkait dengan kode ini. Kedua, beberapa persyaratan formal tambahan untuk penggunaan.

BSD (versi 2-klausul dan 3-klausul) pada dasarnya serupa dengan MIT: gunakan, modifikasi, jual, dan pertahankan pemberitahuan hak cipta. Saya merangkum ketiganya dalam tabel agar perbedaannya terlihat sekilas.

Cara menerapkannya untuk penggunaan Anda sendiri: jika kode orang lain berlisensi MIT, Apache 2.0, atau BSD, Anda bisa tenang: Anda boleh menggunakannya dalam produk komersial, memodifikasinya, dan tetap merahasiakan kode sumber Anda sendiri. Anda hanya perlu memastikan berkas lisensi dan atribusi dari bagian yang Anda ambil tidak dihapus.

Bagaimana kewajiban kode sumber GPL dan AGPL berlaku?#

Copyleft mempertahankan karya tercakup serta turunannya pada lisensi yang sama ketika syarat relevan berlaku. Di bawah GPLv3, distribusi salinan kode sumber atau objek dari karya tercakup atau gabungan turunannya memerlukan kepatuhan terhadap lisensi serta kewajiban kode sumber bersesuaian. Ini tidak otomatis berlaku pada setiap program independen dalam produk atau server yang sama.

Ambil contoh layanan web. Menghosting pustaka GPL pada server sendiri tanpa memberikan salinan kepada pengguna tidak dengan sendirinya mewajibkan publikasi seluruh layanan. Mendistribusikan aplikasi gabungan tercakup kepada pelanggan dapat memicu kewajiban GPL; periksa integrasi serta lisensi kode sebelum menentukan kode sumber yang harus menyertainya. Klien browser yang dikirim kepada pengguna merupakan pertanyaan distribusi terpisah.

AGPLv3 menambahkan syarat jaringan: jika Anda memodifikasi program dan pengguna berinteraksi jarak jauh dengan versi itu, program harus secara jelas menawarkan kode sumber bersesuaiannya kepada pengguna tersebut. Ini lebih tepat daripada mengatakan bahwa sekadar menghosting komponen AGPL membuka setiap bagian independen layanan.

Untuk produk proprietary, periksa karya tercakup, cara komponen digabungkan, apakah salinan didistribusikan, serta apakah interaksi jaringan AGPL berlaku. Pilih alternatif permisif yang kompatibel atau dapatkan izin terpisah jika tidak dapat memenuhi kewajiban relevan. Penggunaan komersial sendiri diizinkan; persoalannya kepatuhan terhadap lisensi serta integrasi yang sebenarnya.

Apa yang harus dilakukan jika repositori sama sekali tidak memiliki berkas lisensi?#

Kesalahan umum adalah menganggap jika tidak ada lisensi, berarti tidak ada batasan dan Anda bebas menggunakan kodenya. Justru sebaliknya. Tidak adanya lisensi bukanlah izin; secara default, artinya tidak ada izin. Kode tanpa lisensi tetap sepenuhnya berada di bawah hak cipta penulis, dan Anda tidak boleh menyentuhnya.

Aturan yang kita mulai tadi kembali berlaku: secara default, kode dilindungi hak cipta, dan tanpa izin tegas Anda tidak boleh menyalin, memodifikasi, atau mendistribusikannya. Kemampuan untuk melihat dan melakukan fork di GitHub tidak menghilangkan batasan itu—kemampuan tersebut tidak memberi Anda hak untuk menggunakan kode dalam produk Anda sendiri.

Apa yang harus dilakukan dalam praktik jika kode tidak memiliki lisensi, tetapi Anda benar-benar membutuhkannya:

1. Hubungi penulis. Tanyakan langsung di bagian diskusi repositori atau melalui email apakah Anda boleh menggunakan kode tersebut dan dengan ketentuan apa. Kadang penulis hanya lupa menambahkan lisensi dan akan menambahkannya jika diminta.
2. Cari pengganti. Untuk hampir semua kebutuhan, ada repositori serupa kedua, ketiga, bahkan kesepuluh—di antaranya Anda akan menemukan yang memiliki lisensi MIT atau Apache yang semestinya.
3. Jangan gunakan. Jika Anda tidak memiliki izin dan tidak ada pengganti, kode itu bukan milik Anda, dan Anda tidak boleh memasukkannya ke produk yang ingin dijual. Godaan untuk berpikir “siapa yang akan tahu?” berakhir buruk tepat saat produk mulai menghasilkan uang dan menarik perhatian.

Bagaimana jika Claude sendiri menambahkan kode orang lain ke proyek?#

Ada lapisan kedua di sini, dan mudah tertukar dengan yang pertama. Berbeda halnya ketika Anda membuka repositori lalu menyalin berkas darinya: semua hal di atas mengenai lisensi menjadi kewajiban langsung Anda. Berbeda pula ketika Claude menulis kode untuk Anda sebagai respons atas permintaan.

Dalam kasus biasa, AI menghasilkan teksnya sendiri yang dirangkai untuk kebutuhan Anda, bukan salinan berkas milik orang lain. Pertanyaannya kemudian beralih ke ranah lain: siapa pemilik kode yang dihasilkan, dan bolehkah Anda menjualnya? Itu topik besar tersendiri, dan saya membahasnya dalam artikel tentang siapa pemilik kode yang ditulis oleh AI.

Namun, ada pengecualian yang perlu diingat. Terkadang AI menghasilkan bagian kode milik orang lain yang dapat dikenali, hampir kata demi kata—sebuah fungsi lengkap dari pustaka terkenal. Dalam kasus itu, lisensi pustaka tersebut tetap berlaku, siapa pun yang secara fisik menekan tombol. Jadi, blok besar siap pakai yang diambil Claude secara utuh harus diperiksa seolah-olah Anda menyalinnya sendiri.

Cara memeriksa lisensi sebelum menggunakan kode: langkah-langkahnya#

Mari rangkum semuanya dalam daftar periksa singkat untuk memeriksa kode pihak ketiga sebelum memasukkannya ke proyek Anda. Ikuti dari atas ke bawah.

1. Temukan nama lisensi di halaman repositori

   Buka repositori di GitHub. Nama lisensi biasanya terlihat di kolom kanan atau di bawah daftar berkas—misalnya, “MIT License,” “Apache-2.0,” atau “GPL-3.0.” Jika kolomnya kosong dan tidak ada berkas lisensi, itu sudah menjadi tanda bahaya; kembali ke hal ini pada langkah terakhir.

2. Buka berkas lisensinya

   Cari LICENSE, LICENSE.md, atau COPYING dalam daftar berkas, lalu buka. Pastikan namanya cocok dengan yang ditampilkan di bilah sisi dan lisensi itu berlaku untuk kode yang Anda gunakan, bukan hanya untuk bagian lain dari repositori.

3. Kenali jenisnya: permisif atau copyleft

   MIT, Apache 2.0, dan BSD bersifat permisif; Anda boleh menggunakan kodenya dalam produk komersial tertutup. GPL dan AGPL bersifat copyleft; periksa karya tercakup, distribusi, serta syarat jaringan AGPL sebelum menentukan kewajiban kode sumber. Nama saja tidak membuktikan komponen independen mana yang tercakup.

4. Bandingkan dengan situasi Anda

   Jawab tiga pertanyaan: apakah Anda menjual produk, apakah Anda memodifikasi kode, dan apakah Anda ingin merahasiakan kode sumber? MIT, Apache, dan BSD cocok untuk produk tertutup yang dijual. Untuk GPL dan AGPL, tentukan karya tercakup atau gabungan mana yang memerlukan kode sumber bersesuaian dan kapan kewajibannya terpicu; nilai apakah Anda dapat memenuhi syarat itu.

5. Tanpa lisensi, jangan gunakan

   Jika tidak ada berkas lisensi dan README tidak menyebutkan apa pun tentang izin, Anda tidak boleh menggunakan kode tersebut. Hubungi penulis dan minta izin, atau cari kode setara dengan lisensi yang semestinya. “Tersedia untuk umum” bukan berarti mendapat izin.

Pemeriksaan ini terasa merepotkan sampai produk Anda berkembang, mulai menghasilkan uang, dan seseorang bertanya tentang kode pihak ketiga di dalamnya. Dua menit di awal lebih ringan daripada menghadapi sengketa di kemudian hari. Saya membahas secara terpisah apa yang perlu dilakukan pada produk setelah itu agar tidak terhenti setelah peluncuran: Saya membangun produk dengan AI; apa selanjutnya.

Kunjungi Ailoot.