GitHub projesinde birden fazla lisans bildirme

Yıllardır, çevrimiçi olarak paylaşılan şeylere lisans verme konusunda, başkalarının söz konusu şeyleri tekrar tekrar kullanıp kullanmamalarını ve nasıl tekrar kullanabileceklerini belirlemelerini kolaylaştırmak için harika bir hayranım. GitHub, kullanıcılarına nazikçe LICENSE dosyalarını repoları eklemeye zorlamadan önce, kodla - en iyi nasıl yapılacağını bilmiyordum - özellikle GitHub'da genel olarak paylaşılan kod! - ama LICENSE dosyalarını o zamandan beri iyi kullanmaya çalıştım.

Şimdi , bazı lisanslardan söz edilmesini gerektiren (üçüncü taraf kodları ve kütüphaneler ve kod dışı dosyalar nedeniyle) küçük bir projede çalıştığım durumdayım . Ortaklarım konuyla ilgili daha 'özensiz' bir konuyu ele alırken - 'sadece olduğu gibi çevrimiçi kod koymam, hiç kimsenin umursayamayacağı' önerildi - bunu doğru yapmayı tercih ederim. Sorun şudur: GitHub'taki birkaç (farklı) lisanstan nasıl bahsedilir?

GitHub'da birkaç farklı çözüm gördüm , bu yüzden biraz farklı bir sorunun cevabının otoriter olup olmadığına karar vermem zor . Bilmek istediğim şey, aşağıdakilerden hangisidir - eğer varsa - en yaygın olanı veya başka yapmanın başka yolları varsa.

1. Oluşturun tek LİSANS dosyası ve orada tüm farklı lisansların açıklamaları koydu. ( Sorular : Belli bir sıraya konmalı mılar? Daha iyi bir gözden geçirme için dosyadaki tüm lisansların adlarından söz ederek dosyadan başlayabilir miyim?)
2. Bağlantılı cevapta önerildiği şekilde , kullanılan lisans başına bir LİSANS dosyası oluşturun ve bunları adlandırın , vb. ( Soru : Adlandırma proje adlarına göre mi yapılacak? Lisans adları değil mi? Kendine katkıda bulunan materyal için birden fazla lisans kullansaydım, hepsinden 'ana' da söz eder miydim?LICENSE.mdLICENSE.LibNameA.mdLICENSE.AssetsB.mdLICENSE.md
3. İki LİSANS dosyası oluşturun : Biri 'ana' içerik için lisansları listeliyor, yani kendi yarattığı tüm kodlar / varlıklar; tüm 3. parti malzemeler için bir tane. ( Yukarıdaki gibi sorular : birisinin kullanacağı belirli bir adlandırma şeması var ve hangisinin 3. parti materyallerini listeleyeceğini sıralıyor musunuz?)

Son olarak, Lisans API'leri ile ilgili çeşitli GitHub açıklamalarını ve projelerini doğru bir şekilde anladıysam, bir repo lisansı belirlenirken yalnızca “ana” LİSANS dosyası göz önünde bulundurulacak (hangi lisansın alınacağına karar veremesem de) eğer birkaçından bahsedilirse).

Projenizin bir ziyaretçisine, hangi lisansın projenin hangi kısmı için geçerli olduğu açıkça anlaşıldığı sürece, istediğiniz lisansları dahil etmek için herhangi bir mekanizmayı kullanabilirsiniz.

Tercihim şöyle olurdu:

• Kullandığınız her üçüncü taraf kütüphanesini kendi dizinine yerleştirin. Bu dizin , lisans ve benioku dosyaları dahil olmak üzere kitaplığın dağıtımının bir parçası olan tüm dosyaları içermelidir .
• Kendi lisans dosyanızda, yalnızca kendi kodunuzun lisansına bakın.
• Projenizin benioku dosyasında, hangi üçüncü taraf kütüphanelerini kullandığınızı ve her bir kütüphanenin hangi lisans altında dağıtıldığını belirtin. Tam lisans ayrıntıları için kütüphanenin dizinindeki lisans dosyasına bakın.

SPDX yaratıcılarının sunumunda ( slayt 12 ), çok açık:

İçeriği LICENSE:

Apache-2.0 OR GPL-2.0-or-later

İki ek LİSANS dosyası daha sonra ekleyebilirsiniz: LICENSE.Apache-2.0ve LICENSE.GPL-2.0-or-later.

Her durumda, bir SPDX lisans tanımlayıcısı README.mdiçermelidir :

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

Böyle yapabilirsin:

## 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`

Bunu unutmayın Apache-2.0 OR GPL-2.0-or-laterve Apache-2.0 AND GPL-2.0-or-laterbüyük bir fark yaratır. Birincisi, kullanıcının her ikisi (normal durumdur!) Arasında seçim yapabileceği ve ikincisi kullanıcının her iki lisansa da uyması gerektiği anlamına gelir . Ayrıca Wikipedia'da çoklu lisans bölümüne bakınız .

Burada yeni ( 2017-12-28 itibariyle ) SPDX License List 3.0 kullandığımı unutmayın. 2017'nin sürümleri GPL-2.0GPL 2.0 için tanımlayıcıydı, ancak bunun "yalnızca GPL 2.0" veya "GPL 2.0 veya daha sonraki bir sürüm" anlamına geldiği belli değildi .

Sonunda sorumla ilgili olarak doğrudan GitHub desteğine başvurdum ve cevaplarının önerileri değil , sadece öneri olduğunu açıkladıysam, teklif etmenin uygun olduğunu söylediler .

Ekibimizin şu anda önerebileceği herhangi bir öneri yok, ancak paylaşacak başka bir şeyimiz olursa size sormaya ve güncellemeye dikkat edeceğiz!

Orijinal cevapları size aşağıdakileri sunmaktaydı:

Önerilerinizden biri, kodunuzun çoğunluğu için bir LİSANS dosyasına sahip olmak ve README dosyanızdaki 3. taraf malzemelerin geri kalanına ait lisansların metnini eklemektir.

Başka bir yol, her yolun bir anlam ifade ettiği zaman kendi LİSANS dosyasına sahip olmasıdır. Bu nedenle, örneğin, deponuzda aşağıdaki yol bulunursa: libs / awesome-lib-v2 / libs / awesome-lib-v2 / LICENSE olabilir.

İkinci durumda, kökünüzdeki README dosyasında ve / veya LICENSE dosyasında belirtmek isteyebilirsiniz.

Ayrıca, havuzunuzun kökününde yalnızca bir LICENSE dosyası kullanmayı düşünebilir ve herhangi bir 3. parti malzeme, kod ve benzeri için alt bölümler ekleyebilirsiniz.