Menggunakan lisensi berbeda untuk cabang berbeda dari repositori yang sama
Saya memiliki repositori Git dengan proyek berukuran sedang di GitHub. Karena ada beberapa komponen yang bergantung pada pustaka GPL, repositori saat ini juga dilisensikan di bawah GPL. Namun, pustaka berlisensi GPL hanya digunakan oleh beberapa komponen (yang dapat diisolasi), dan sisa proyek dapat digunakan secara sempurna tanpa komponen tersebut. Oleh karena itu, saya ingin melisensikan semua yang tidak memiliki ketergantungan pada pustaka GPL apa pun di bawah lisensi MIT. Apa praktik terbaik untuk mencapai ini?
Ide saya adalah memiliki dua cabang yang berbeda: satu cabang berisi kode lengkap dan dilisensikan di bawah GPL. Cabang lain menghapus semua fungsionalitas yang bergantung pada kode GPL dan dilisensikan di bawah MIT. Apakah layak dan / atau umum memiliki lisensi berbeda untuk cabang berbeda dari repositori yang sama? Jika tidak, apa alternatif yang lebih baik?
Mungkinkah masalah bahwa, secara teknis, riwayat lengkap dari cabang non-GPL yang baru itu pernah menyertakan kode GPL? Atau tidak apa-apa selama semua kode GPL dihapus dari cabang itu sebelum saya menambahkan file lisensi MIT baru di cabang?
Perhatikan bahwa pertanyaan ini agak mirip, tetapi saya merasa pertanyaan saya lebih mementingkan implementasi teknis . Artinya, dapatkah saya meletakkan dua file LISENSI yang berbeda di direktori root dari repositori, tergantung pada cabang mana kita saat ini?
Jawaban
Cabang Git tidak bekerja dengan baik untuk mempertahankan “edisi” berbeda dari proyek yang sama, karena tidak ada cara yang baik untuk berbagi perubahan di seluruh cabang tanpa menggabungkannya sepenuhnya. Jadi hanya karena alasan teknis, saya mendorong Anda untuk tidak menggunakan cabang berlisensi berbeda. Cabang semacam itu juga sangat tidak dapat ditemukan oleh pengguna.
Sebaliknya, simpan semua kode dalam satu cabang utama, tetapi simpan kode berlisensi yang berbeda di folder yang berbeda dan perjelas kode mana yang termasuk dalam lisensi apa.
GPL tidak mengharuskan kode downstream apa pun berada di bawah GPL. Ini mensyaratkan bahwa setiap karya turunan (secara keseluruhan) berada di bawah lisensi GPL yang sama. Tetapi ini dapat dipenuhi bila setiap komponen yang Anda tulis sendiri berada di bawah lisensi yang kompatibel dengan GPL, seperti MIT. Untuk menghindari keraguan, Anda juga dapat melisensikan ganda komponen tersebut sebagai "MIT atau GPL". Ini penting untuk lisensi yang tidak kompatibel, misalnya "Apache-2.0 atau GPL-2.0-only".
Jadi praktik terbaiknya adalah memisahkan bagian yang tercakup GPL dari bagian yang telah Anda tulis sendiri sepenuhnya, dan menggunakan LISENSI tingkat atas untuk menjelaskan bagian apa yang tersedia di bawah lisensi tertentu. Jika Anda ingin melakukan ini dengan sangat akurat, Anda bahkan dapat mengadopsi copyrightformat file Debian yang dapat dibaca mesin yang mengaitkan pola glob dengan lisensi. Anda bisa menyimpan teks lisensi penuh baik di dalam file lisensi yang sama, atau mungkin sebagai file terpisah suka LICENSE.GPL.txt, LICENSE.MIT.txtatau di direktori masing-masing.
Karena Anda saat ini menawarkan seluruh kode di bawah GPL, bergerak MIT untuk beberapa bagian akan membutuhkan relicensing . Ini sepele jika Anda adalah kontributor tunggal, karena Anda sebagai pemegang hak cipta tunggal dapat mengeluarkan lisensi sesuka Anda. Tetapi jika ada kontributor lain, Anda harus mendapatkan persetujuan mereka untuk pemberian lisensi kembali atau harus menghapus kontribusi mereka (yang bisa sangat rumit karena umumnya memerlukan penulisan ulang komponen yang dimulai dengan status terakhir sebelum kontribusi yang tercakup dalam GPL). Saya tidak berpikir itu penting bahwa sejarah Git akan menunjukkan file-file yang sama dengan yang tercakup dalam GPL bahkan setelah pelisensian ulang. Lisensi lama masih berlaku untuk versi lama tersebut, lisensi baru masih berlaku untuk versi baru tersebut.