Mendeklarasikan banyak lisensi dalam proyek GitHub

Selama bertahun-tahun, saya telah menjadi penggemar berat lisensi pada hal-hal yang dibagikan secara online untuk memudahkan orang lain untuk menentukan apakah dan bagaimana mereka dapat menggunakan kembali hal-hal tersebut. Sebelum GitHub mulai dengan lembut 'mendorong' para penggunanya untuk memasukkan file LICENSE dengan repo mereka, saya tidak benar-benar tahu cara terbaik untuk melakukan ini dengan kode - terutama kode yang dibagikan secara publik di GitHub! - tapi saya sudah mencoba memanfaatkan file LICENSE sejak saat itu.

Saya sekarang dalam situasi di mana saya telah bekerja pada proyek kecil dengan beberapa orang lain, yang memerlukan penyebutan beberapa lisensi (karena kode pihak ketiga & perpustakaan serta file non-kode). Sementara mitra saya membahas masalah ini agak 'sembarangan' - disarankan agar saya 'hanya meletakkan kode online apa adanya, tidak ada yang peduli' -, saya lebih suka melakukan ini dengan benar. Masalahnya adalah: Saya tidak tahu bagaimana orang seharusnya menyebutkan beberapa (berbeda) lisensi di GitHub.

Saya telah melihat beberapa solusi berbeda di GitHub, oleh karena itu sulit bagi saya untuk menilai apakah jawaban untuk pertanyaan yang sedikit berbeda ini asli. Yang ingin saya ketahui adalah yang mana dari yang berikut - jika ada - yang paling umum, atau jika ada cara lain, tambahan untuk melakukan ini.

Buat satu file LICENSE tunggal dan letakkan deskripsi semua lisensi yang berbeda di sana. ( Pertanyaan : Haruskah mereka dimasukkan dalam urutan tertentu? Apakah saya akan memulai file dengan menyebutkan nama-nama semua lisensi yang terkandung di dalamnya, untuk gambaran yang lebih baik)?
Buat satu file LISENSI per lisensi yang digunakan dan nama mereka LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.mddll seperti yang disarankan dalam jawaban terkait. ( Pertanyaan : Penamaan akan didasarkan pada nama proyek? Bukan nama lisensi? Jika saya menggunakan lebih dari satu lisensi untuk materi yang disumbangkan sendiri, akankah saya menyebutkan semuanya dalam 'utama' LICENSE.md? Jika tidak, apa yang akan saya lakukan sebagai gantinya?)
Buat dua file LICENSE : satu daftar lisensi untuk konten 'utama', yaitu semua kode / aset yang telah dibuat sendiri; satu untuk semua bahan pihak ke-3. ( Pertanyaan seperti di atas : apakah ada skema penamaan tertentu yang akan digunakan, dan urutan mana yang akan mencantumkan materi pihak ke-3?)

Terakhir, jika saya memahami berbagai penjelasan dan proyek GitHub mengenai API Lisensi mereka dengan benar, hanya file LICENSE 'utama' yang akan dipertimbangkan ketika menentukan lisensi repo (meskipun saya belum dapat mengetahui lisensi mana yang akan diambil. jika beberapa disebutkan).

licensing github

— Kay
sumber

Jadi miliki README dan satu atau lebih file LISENSI. Ini bukan ilmu roket.

— Robert Harvey

Mengenai halaman tertaut: itu tidak ada hubungannya dengan distribusi file lisensi, itu harus dengan API Lisensi GitHub yang menentukan / melaporkan kembali pada lisensi repo. Ketika saya bertanya tentang lisensi / penggunaan file LICENSE pada GitHub secara khusus, bukan open source atau git secara umum, cara proyek open source 'digambarkan' untuk dilisensikan dengan dilisensikan di sana juga relevan. 'Ini bukan ilmu roket' tidak terlalu membantu, btw., Esp. tidak dalam konteks pertanyaan saya yang berfokus pada GitHub.

— Kay

Saya mungkin menyarankan agar README Anda memiliki bagian tentang perizinan, cukup dengan menyatakan bahwa ada beberapa lisensi dan memberi informasi untuk setiap lisensi, nama file LICENSE yang ada di dalamnya?

— Erik Eidt

@ Imibis saya sadar akan hal itu dan sama sekali bukan pertanyaan saya. Saya secara khusus meminta jawaban mengenai 'jalan mana yang paling masuk akal bagi manusia' (di: GitHub).

— Kay

@immibis: "Tidak ada kompiler yang akan membacanya" - masalahnya adalah bahwa sebenarnya, ini tidak berlaku untuk Github. Github memang menggunakan alat otomatis untuk menentukan lisensi "the" yang diterapkan pada isi repositori. Nama lisensi yang ditentukan kemudian akan ditampilkan di bar judul repositori, bersama dengan beberapa informasi yang lebih umum yang memberikan pengunjung dengan kesan dasar proyek (misalnya jumlah kontributor dan rilis).

— ATAU Mapper

Jawaban:

Anda dapat menggunakan mekanisme apa pun untuk memasukkan lisensi yang Anda sukai, asalkan menjadi jelas bagi pengunjung proyek Anda, lisensi mana yang berlaku untuk bagian mana dari proyek tersebut.

Preferensi saya adalah:

Letakkan setiap perpustakaan pihak ketiga yang Anda gunakan di direktori sendiri. Direktori ini harus berisi semua file yang merupakan bagian dari distribusi perpustakaan, termasuk file lisensi dan readme.
Dalam file lisensi Anda sendiri, rujuk hanya ke lisensi kode Anda sendiri
Dalam file readme proyek Anda, sebutkan perpustakaan pihak ketiga mana yang Anda gunakan dan lisensi perpustakaan mana yang didistribusikan. Untuk detail lisensi lengkap, lihat file lisensi di direktori perpustakaan.

— Bart van Ingen Schenau
sumber

Bagaimana Anda menangani file LISENSI Anda sendiri dalam kasus lisensi ganda konten sendiri dalam skenario ini? Yaitu jika Anda menggunakan lisensi yang berbeda untuk bagian proyek yang berbeda (kode vs file media) atau jika Anda ingin mendistribusikan kode Anda di bawah dua (atau lebih) lisensi perangkat lunak yang berbeda? Menempatkan info tambahan di README sangat masuk akal dan saya juga akan melakukannya, tetapi saya sangat tertarik dengan cara menangani file LICENSE di GitHub (yang menurut saya, didorong untuk memberi pengunjung / pemirsa proyek tinjauan singkat).

— Kay

Jika (bagian) dari kode saya sendiri memiliki dua lisensi, saya akan menambahkan dua (atau lebih) file lisensi ke proyek, satu untuk setiap lisensi, dan membuatnya jelas dalam file readme lisensi mana yang berlaku dalam hal ini.

— Bart van Ingen Schenau

Bart, terima kasih telah berbagi bagaimana Anda akan melakukannya - itu jauh lebih bermanfaat daripada beberapa komentar yang saya dapatkan. :) Sementara itu saya benar-benar telah menghubungi GitHub tentang hal itu dan akan membiarkan pertanyaan ini terbuka untuk saat ini kalau-kalau ada yang keluar dari sana.

— Kay

Ketika Anda mendapat jawaban dari Github, kirimkan informasi itu sebagai jawaban sendiri untuk pertanyaan ini.

— Bart van Ingen Schenau

Saya pasti akan jika itu ok dengan mereka karena mungkin menarik untuk mengetahui untuk orang lain juga!

— Kay

Dalam presentasi pembuat SPDX ( slide 12 ), sangat jelas:

Isi dari LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Anda dapat menambahkan dua file LICENSE tambahan, kemudian: LICENSE.Apache-2.0dan LICENSE.GPL-2.0-or-later.

Dalam semua kasus, README.mdharus mengandung pengidentifikasi lisensi SPDX :

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

Anda bisa melakukannya seperti itu:

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

Catat itu Apache-2.0 OR GPL-2.0-or-laterdan Apache-2.0 AND GPL-2.0-or-laterbuat perbedaan besar. Yang pertama berarti bahwa pengguna dapat memilih antara keduanya (yang merupakan kasus biasa!) Dan yang kedua menunjukkan bahwa pengguna harus mematuhi kedua lisensi. Lihat juga multi lisensi di Wikipedia.

Perhatikan bahwa saya menggunakan Daftar Lisensi SPDX 3.0 yang baru (pada 2017-12-28 ) di sini. Versi 2017 miliki GPL-2.0adalah pengidentifikasi untuk GPL 2.0, tetapi tidak jelas apakah itu berarti "hanya GPL 2.0" atau "GPL 2.0 atau versi yang lebih baru".

— koppor
sumber

Saya akhirnya menghubungi dukungan GitHub secara langsung sehubungan dengan pertanyaan saya dan mereka mengatakan tidak apa-apa untuk mengutip mereka jika saya menjelaskan jawaban mereka hanya dimaksudkan sebagai saran, bukan rekomendasi.

Tim kami tidak memiliki rekomendasi khusus untuk ditawarkan saat ini, tetapi kami akan memastikan untuk bertanya dan memperbarui Anda jika kami memiliki hal lain untuk dibagikan!

Balasan asli mereka memiliki yang berikut untuk ditawarkan:

Satu saran adalah memiliki satu file LICENSE untuk sebagian besar kode Anda, dan menambahkan teks lisensi untuk sisa bahan pihak ke-3 dalam file README Anda.

Cara lain adalah agar setiap jalur memiliki file LISENSI sendiri saat masuk akal. Jadi, jika, misalnya, repositori Anda memiliki jalur berikut: libs / awesome-lib-v2 / Anda bisa memiliki libs / awesome-lib-v2 / LICENSE.

Dalam kasus terakhir, Anda mungkin ingin menyebutkan bahwa dalam file README dan / atau file LICENSE di root Anda.

Anda juga dapat mempertimbangkan hanya menggunakan satu file LICENSE di root repositori Anda, dan menambahkan subbagian untuk materi, kode, dan sebagainya pihak ketiga mana pun.

— Kay
sumber