Kod GitHub dalam Produk Komersial: Lesen dan Perkara yang Perlu Disemak

Anda sedang membina produk dan menemui bahagian yang sudah siap di GitHub: pustaka, templat atau keseluruhan projek yang melakukan tepat seperti yang anda perlukan. Claude mencadangkan supaya anda memasukkannya ke dalam projek anda. Kemudian anda teragak-agak: kod itu nampaknya tersedia untuk umum, tetapi bolehkah anda menggunakannya, apatah lagi menjual produk yang mengandunginya? Mungkinkah pengarangnya mengambil tindakan terhadap anda kemudian?

Saya akan menerangkannya mengikut turutan: sebab kod terbuka di GitHub bukan dengan sendirinya suatu kebenaran, lesen yang membolehkan anda menggunakan kod dan menjual produk, syarat copyleft yang boleh mewajibkan sumber sepadan bagi karya diliputi, dan cara menyemak lesen dalam masa seminit sebelum menggunakan kod itu. Tiada jawapan “bergantung pada situasi”.

Maklumat praktikal tentang penggunaan Ailoot terdapat dalam dokumentasi.

Betulkah anda boleh menggunakan kod secara percuma jika kod itu berada di GitHub?#

Perangkap utamanya ialah perkataan “terbuka”. Anda boleh melihat kod sumber, jadi anda mungkin beranggapan bahawa kerana kod itu tidak disembunyikan, anda dibenarkan menggunakannya. Logik itu salah. “Terbuka untuk dibaca” dan “dilesenkan untuk digunakan” ialah dua perkara yang berbeza.

Secara lalai, setiap karya kreatif, termasuk kod, dilindungi hak cipta sejak ia dicipta. Sehingga pengarang memberikan kebenaran secara jelas, anda tidak boleh menggunakannya. Begitulah cara GitHub menerangkannya pada halaman rujukan lesennya sendiri.

Lapisan kedua ialah GitHub sendiri. Orang ramai berpendapat bahawa kerana mereka bersetuju dengan peraturan GitHub dengan menerbitkan kod, mereka juga boleh menggunakan kod orang lain dari situ. Peraturannya menyatakan hal yang sebaliknya. Dengan menjadikan repositori awam, pengarang hanya membenarkan orang lain melihat dan membuat fork — iaitu, membuat salinan dalam GitHub sendiri. Hal itu tidak membenarkan penggunaan kod tersebut dalam kerja anda sendiri.

Kata kunci terdapat dalam ayat terakhir: “dalam lingkungan ciri GitHub” dan “hak tambahan datang daripada lesen”. Fork kekal dalam GitHub. Sebaik sahaja anda mahu menggunakan kod itu dalam produk anda sendiri, apatah lagi menjualnya, anda memerlukan lesen berasingan daripada pengarang. Tiada lesen, tiada hak — walaupun kod itu berada tepat di depan mata.

Apakah yang menentukan sama ada anda boleh menggunakan kod orang lain?#

Semuanya bergantung pada satu fail. Repositori yang diselenggara dengan baik mengandungi fail lesen — biasanya LICENSE, kadangkala LICENSE.md, atau sebutan terus dalam README. Inilah kebenaran daripada pengarang yang menyatakan syarat penggunaan kod tersebut. GitHub biasanya memaparkan nama lesen pada bar sisi halaman repositori sebelum anda membuka fail itu sendiri.

Untuk mengelakkan kekeliruan dengan bahasa undang-undang, anda boleh membaca lesen dengan meneliti tiga soalan tentang keadaan anda:

1. Bolehkah anda menggunakan kod ini dalam produk komersial yang dibayar oleh orang ramai?
2. Bolehkah anda mengubah suai kod itu mengikut keperluan anda?
3. Adakah anda perlu membuka kod sumber produk anda selepas itu, atau bolehkah anda merahsiakannya?

Hampir semua perbezaan antara lesen berpunca daripada jawapan yang berlainan kepada soalan ketiga. Bagi dua soalan pertama, lesen terbuka popular biasanya menjawab “ya”: gunakannya, ubah suainya, jualnya. Namun, orang sering tersangkut pada persoalan sama ada lesen itu memaksa anda membuka kod sendiri. Seterusnya, kita akan meneliti jenis-jenis utama berdasarkan tiga soalan ini.

Lesen manakah yang membolehkan anda menggunakan kod dan menjual produk?#

Mari kita mulakan dengan berita baik. Bagi seseorang yang sedang membina produk untuk dijual, pilihan terbaik ialah kumpulan lesen yang dipanggil lesen permisif. Terdapat beberapa jenis, tetapi tiga yang paling biasa ialah MIT, Apache 2.0 dan BSD. Ketiga-tiganya menjawab “ya” kepada dua soalan pertama dan membolehkan anda merahsiakan kod sumber anda sendiri.

Lesen yang paling biasa dan paling mudah ialah MIT. Teksnya muat dalam satu perenggan.

Secara ringkasnya, MIT membolehkan anda melakukan hampir apa sahaja dengan kod itu, termasuk menjual produk dan merahsiakan kod sumber anda sendiri. Satu-satunya kewajipan ialah menyertakan teks lesen dan baris atribusi. Contohnya, Babel, .NET dan Rails dikeluarkan di bawah MIT, jadi besar kemungkinan anda sudah menggunakan kod di bawah lesen ini.

Apache 2.0 berfungsi dengan cara yang sama, tetapi menambah dua perkara penting. Pertama, perlindungan jelas terhadap tuntutan paten: pengarang kod berjanji untuk tidak menyaman anda berkaitan paten pada kod ini. Kedua, terdapat beberapa lagi keperluan rasmi untuk penggunaan.

BSD (dalam versi 2 klausa dan 3 klausa) pada asasnya serupa dengan MIT: gunakannya, ubah suainya, jualnya dan kekalkan notis hak cipta. Saya telah meletakkan ketiga-tiganya dalam jadual supaya anda dapat melihat perbezaannya sekali imbas.

Cara menggunakan maklumat ini: jika anda melihat MIT, Apache 2.0 atau BSD pada kod orang lain, anda boleh berasa lega: anda boleh menggunakan kod itu dalam produk komersial, mengubah suainya dan merahsiakan kod sumber anda sendiri. Anda hanya perlu memastikan fail lesen dan atribusi daripada bahagian yang diambil tidak dibuang.

Bagaimanakah kewajipan sumber GPL dan AGPL terpakai?#

Copyleft mengekalkan karya diliputi dan terbitannya di bawah lesen sama apabila syarat berkenaan terpakai. Di bawah GPLv3, mengedarkan salinan sumber atau kod objek karya diliputi atau terbitan gabungan memerlukan pematuhan lesen serta kewajipan sumber sepadan. Ia tidak terpakai secara automatik kepada setiap program bebas dalam produk atau pelayan sama.

Ambil contoh perkhidmatan web. Mengehos pustaka GPL pada pelayan sendiri tanpa memberikan salinan kepada pengguna tidak memerlukan penerbitan seluruh perkhidmatan dengan sendirinya. Mengedarkan aplikasi gabungan diliputi kepada pelanggan boleh mencetuskan kewajipan GPL; periksa integrasi dan lesen kod sebelum menentukan sumber yang mesti disertakan. Klien pelayar dihantar kepada pengguna ialah soalan pengedaran berasingan.

AGPLv3 menambah syarat rangkaian: jika anda mengubah program dan pengguna berinteraksi dengan versi itu secara jauh, ia mesti menawarkan sumber sepadan secara jelas kepada pengguna tersebut. Ini lebih tepat daripada mengatakan sekadar mengehos komponen AGPL membuka setiap bahagian bebas perkhidmatan.

Untuk produk proprietari, periksa karya diliputi, cara komponen digabungkan, sama ada salinan diedarkan dan sama ada interaksi rangkaian AGPL terpakai. Pilih alternatif permisif serasi atau dapatkan kebenaran berasingan jika tidak boleh memenuhi kewajipan berkenaan. Penggunaan komersial sendiri dibenarkan; isunya pematuhan lesen serta integrasi sebenar.

Apakah yang patut anda lakukan jika repositori langsung tidak mempunyai fail lesen?#

Kesilapan yang biasa dilakukan ialah menganggap bahawa jika tiada lesen, tiada sekatan dan anda boleh menggunakan kod itu secara bebas. Sebenarnya sebaliknya. Tiada lesen bukan bermakna ada kebenaran; secara lalai, ini bermakna tiada kebenaran. Kod tanpa lesen kekal di bawah perlindungan penuh hak cipta pengarang dan anda tidak boleh menggunakannya.

Peraturan yang kita mulakan tadi terpakai sekali lagi: secara lalai, kod dilindungi hak cipta, dan tanpa kebenaran jelas, anda tidak boleh menyalin, mengubah suai atau mengedarkannya. Keupayaan untuk melihat dan membuat fork dalam GitHub tidak mengatasi halangan itu — keupayaan tersebut tidak memberikan anda hak untuk menggunakan kod itu dalam produk sendiri.

Jika kod itu tiada lesen tetapi anda benar-benar memerlukannya, inilah tindakan yang boleh diambil:

1. Hubungi pengarang. Tanya sama ada anda boleh menggunakan kod itu dan apakah syaratnya, sama ada terus melalui bahagian perbincangan repositori atau melalui e-mel. Kadangkala pengarang terlupa menambah lesen dan akan menambahkannya apabila diminta.
2. Cari pengganti. Hampir setiap tugasan mempunyai repositori serupa yang kedua, ketiga dan kesepuluh — antara repositori itu, anda akan menemui satu yang mempunyai lesen MIT atau Apache yang sesuai.
3. Jangan gunakannya. Jika anda tiada kebenaran dan tiada pengganti, kod itu bukan milik anda dan anda tidak boleh memasukkannya ke dalam produk yang ingin anda jual. Godaan untuk berfikir “siapa yang akan tahu?” akan berakhir dengan buruk sebaik sahaja produk itu mula menjana wang dan menarik perhatian.

Bagaimana jika Claude sendiri menambahkan kod orang lain ke dalam projek?#

Terdapat satu lagi lapisan di sini yang mudah dikelirukan dengan perkara pertama. Satu hal jika anda melawat repositori dan menyalin fail daripadanya: ketika itu, semua perkara di atas tentang lesen menjadi tanggungjawab langsung anda. Hal lain pula apabila Claude menulis kod untuk anda sebagai respons kepada permintaan anda.

Dalam keadaan biasa, AI menghasilkan teksnya sendiri yang disusun untuk tugasan anda, bukannya menyalin fail orang lain. Persoalannya kemudian beralih kepada bidang lain: siapakah pemilik kod yang dijana, dan bolehkah anda menjualnya? Topik itu luas dan tersendiri; saya membincangkannya dalam artikel tentang pemilikan kod yang ditulis oleh AI.

Namun, ada pengecualian yang perlu diingati. Kadangkala AI menghasilkan bahagian kod milik orang lain yang boleh dikenal pasti, hampir perkataan demi perkataan — keseluruhan fungsi daripada pustaka terkenal. Dalam keadaan itu, lesen pustaka tersebut tetap terpakai, tanpa mengira siapa yang menekan kekunci secara fizikal. Oleh itu, blok kod siap guna yang besar dan diambil Claude secara keseluruhan perlu diperiksa seperti kod yang anda salin sendiri.

Cara menyemak lesen sebelum menggunakan kod: langkah-langkah#

Mari kita rangkum semuanya dalam senarai semak ringkas untuk memeriksa mana-mana kod pihak ketiga sebelum memasukkannya ke dalam projek anda. Ikuti langkah-langkah ini dari atas ke bawah.

1. Cari nama lesen pada halaman repositori

   Buka repositori di GitHub. Nama lesen biasanya kelihatan pada lajur sebelah kanan atau di bawah senarai fail — contohnya, “MIT License”, “Apache-2.0” atau “GPL-3.0”. Jika ruangnya kosong dan tiada fail lesen, itu sudah menjadi tanda amaran; semak semula perkara ini pada langkah terakhir.

2. Buka fail lesen itu sendiri

   Cari LICENSE, LICENSE.md atau COPYING dalam senarai fail lalu bukanya. Pastikan namanya sepadan dengan yang tertera pada bar sisi dan lesen itu terpakai pada kod yang anda gunakan, bukannya hanya pada bahagian repositori yang berasingan.

3. Kenal pasti jenisnya: permisif atau copyleft

   MIT, Apache 2.0 dan BSD ialah lesen permisif; anda boleh menggunakan kod itu dalam produk komersial tertutup. GPL dan AGPL ialah copyleft; periksa karya diliputi, pengedaran dan sebarang syarat rangkaian AGPL sebelum menentukan kewajipan sumber. Nama sahaja tidak membuktikan komponen bebas yang diliputi.

4. Bandingkan dengan keadaan anda

   Jawab tiga soalan: adakah anda menjual produk itu, adakah anda mengubah suai kod tersebut, dan adakah anda mahu merahsiakan kod sumbernya? MIT, Apache dan BSD sesuai untuk produk tertutup yang dijual. Untuk GPL dan AGPL, tentukan karya diliputi atau gabungan yang memerlukan sumber sepadan serta bila kewajipan dicetuskan; nilai sama ada anda boleh memenuhi syarat itu.

5. Tiada lesen bermakna jangan gunakannya

   Jika tiada fail lesen dan README tidak menyatakan apa-apa tentang kebenaran, anda tidak boleh menggunakan kod itu. Hubungi pengarang dan minta kebenaran, atau cari pengganti setara dengan lesen yang sesuai. “Tersedia untuk umum” bukanlah kebenaran.

Semakan ini nampak menyusahkan sehinggalah kali pertama produk anda berkembang, mula menjana wang dan seseorang bertanya tentang kod pihak ketiga yang terkandung di dalamnya. Dua minit pada permulaan lebih murah daripada menangani pertikaian kemudian. Saya membincangkan secara berasingan perkara yang perlu dilakukan pada produk anda selepas itu supaya ia tidak terhenti selepas pelancaran: Saya membina produk dengan AI; apa seterusnya.

Lawati Ailoot.