Açık kaynak yazılım lisansımı neden kökte tutmak zorundayım?

Neredeyse tüm açık kaynak yazılım lisansları kullanıcıların (veya en azından avukatlar genellikle talep ettiklerini önerir) kullanıcıların tam lisansı korudukları projenin köküne dahil etmelerini gerektirir.

Konuştuğum bir avukat, bunun bir mücevher davasına tam bir lisansın dahil edilmesi gerektiğinde CD çağının bir mirası olduğunu öne sürüyor.

Ama bugün, bulut çağında yaşıyoruz. Örneğin, neden tam lisansı web sitemde barındıramıyorum ve kaynak lisansımın başlığına bu lisansın başlığını + URL'sini ekleyemiyorum?

Bonus: genellikle yerleşmiş lisans kök bozulmadan tutulması gerektiğini kabul etti ederse FSF OSI bunu bir lisans onaylamadı neden olabilir URL ile başvurun ve bu lisansı oluşturmasını tutma birisi nedir?

— samthebrand
kaynak

Akla gelen bir sorun, URL'lerin değişebileceği veya durdurulabileceğidir.

— Aaron Kurtzhals

'İnternet her yerde bulunmaz' en açık neden olacaktır (birileri yazılımınızı indirirken internete sahip olsalar bile, genişletmek / değiştirmek istediklerinde bu kullanıcılar tarafından kullanılamayabilir).

— TZHX

BÜTÜN LİSANSIN neden köke dahil edilmesi gerektiğini veya tüm lisansın neden KÖK'e dahil edilmesi gerektiğini mi soruyorsunuz?

— DougM

Sadece burada yanlış bir ikilemden söz ettiğimizi belirtmek; Lisansın neden kökünde olması gerektiğini ve bunun yerine neden bir URL'de çevrimiçi olamayacağını soruyorsunuz? Kimseden bahsedilmeyen üçüncü bir seçenek var; lisans yazılımla birlikte gelir ancak bir "dokümanlar" dizininde veya başka bir şeyde bulunur ve kod dosyalarının başlığındaki yorum bunu yansıtır. Lisansın neden yazılımla birlikte paketlenmesi gerektiğine ilişkin iyi nedenlere katılıyorum, ancak bu bir docs dizinine gitmede durmuyor.

— James

Neredeyse her zaman kökünde olmasının nedeni, bulmak kolaydır. Projenizi indirdiğimde, root'a göz atıyorum ve gördüğüm ilk şeylerden biri lisans. Bu kadar basit

— JohnL

Yanıtlar:

Gönderen GPL SSS (ama tavsiye tüm lisanslar için geçerlidir):

GPL neden programın her kopyasına GPL'nin bir kopyasını dahil etmeyi gerektirir?

Programın bir kopyasını alan herkesin haklarının ne olduğunu bilmesi için çalışmanın lisansının bir kopyasını dahil etmek çok önemlidir.

Lisansın kendisi yerine lisansla ilgili bir URL eklemek cazip olabilir. Ancak, URL'nin beş yıl veya on yıl sonra hala geçerli olacağından emin olamazsınız. Bundan yirmi yıl sonra, bugün bildiğimiz URL'ler artık mevcut olmayabilir.

Programda kopyaları olan kişilerin, ağda gerçekleşecek tüm değişikliklere rağmen lisansı görmeye devam etmelerini sağlamanın tek yolu, lisansın bir kopyasını programa dahil etmektir.

(benimkini vurgula)

Lisansınızı barındıran site çöktüğü veya URL yollarını değiştirdiği anda, yazılımınızın kopyalarına sahip kişiler artık hangi hakları güvenli bir şekilde kullanabileceklerini doğrulayamazlar. Bir şekilde, tam URL'nin sonsuza kadar çevrimiçi olacağını garanti edebileceğinizi varsayalım: kullanıcıların yazılımınızı kullanımının yasal olduğunu doğrulama yeteneği, yine de belirli bir URL'ye bağlanma yeteneğine bağlıdır. Bu gereksinim şehrinize / ülkenize / gezegeninize zahmetli olmasa da, başka bir yerde zahmetli olabilir. Bu gereksinimi, özellikle de geçici çözüm (tam lisans metni dahil) önemsiz olduğunda dayatmamalısınız.

Bu şikayeti "Ne olmuş? URL aşağı iniyorsa veya erişilebilir değilse" GNU GPL v3 "gibi açık bir tanımlayıcı yeterli olacaktır. GPL'nin tam metin kopyaları bol; kullanıcılar lisansın kendileri. " Birkaç sorun hemen akla geliyor:

Bu, daha az net olan lisans tanımlayıcıları için genelleme yapmaz ("BSD lisansı" ifadesi akla gelir).
Bu, daha az yaygın olan veya özelleştirilmiş lisanslar için iyi bir genelleme yapmaz ("bağlantı istisnaları olan GPL" akla gelir: hangi bağlantı istisnaları?). Bir kullanıcının adıyla güvenilir bir şekilde bulmasını beklemenin makul olması için bir lisansın ne kadar yaygın olması gerekir?
Bu, kullanıcıların yazılımı aldıkları anda bir bağlantısı olsa bile, durumun böyle olmayabileceği bir İnternet bağlantısına sahip olmasını gerektirir. (Ve yazılımı aldıklarında İnternet erişimi olmayabilir: "CD çağı" henüz dünyanın pek çok yerinde sona ermemiştir. Ek bir durum olarak, yaygın İnternet erişimi olan ancak büyük bölümlerini sansürleyen ulusal nüfusları göz önünde bulundurun .) Serbestçe yeniden dağıtılabilir yazılımın bir sonucu, bir alıcının yazılımınızın bir kopyasını doğrudan sizden ya da başlangıçta beklediğiniz bir dağıtım kanalı aracılığıyla alamamasıdır.

Lisans bağlantılarına karşı son bir argüman MichaelT'ın aşağıdaki yorumu ile belirtilmiştir: lisansı dinamik olarak, geriye dönük olarak değiştirmenize izin verebilir. Bu kasıtlı olarak yapılabilir, ancak yazılımın sürümleri arasında lisansı değiştirdiyseniz, ancak her iki sürüm için de aynı lisans bağlantısını kullandıysanız, böylece eski lisansınızı varolduğundan ötürü kazara da yapabilirsiniz. Böyle bir geçiş, eski kopyalarını mevcut sürümden farklı bir lisans altında aldığını kanıtlaması gereken insanlar için zorluk ekler.

Peki, lisansı neden proje kökünde tutmak zorundayım?

Ben avukat değilim, ama herhangi bir çarpıcı fikirler görmedim do proje kök lisansları tutmak gerekir. Lisansın eserin her bir kopyasına eşlik etmesi gerektiğini belirten GPL bile, çalışmaya nasıl eşlik etmesi gerektiği konusunda sessizdir . (Bunun nedeni, GPL'nin "kök dizin" kavramının anlamlı olmadığı yazılım dışı bağlamlarda uygulanabilmesi olabilir.)

Lisansı kök dizinde tutmak muhtemelen iyi bir fikirdir, çünkü kullanıcının lisansı görme olasılığını en üst düzeye çıkarır ve böylece hem kullanıcı hayal kırıklığını hem de bazı belirsiz dizinde lisansı gizlemeye çalıştığınız için size karşı şikayetlerin olasılığını en aza indirir. Çok sayıda lisansınız varsa, bunların tümünü kendi klasörlerine yerleştirmek daha mantıklı olabilir ve her bir bileşenin lisansını bulmak için dosya yollarını içeren belirgin bir README projesi içerir.

Lisansınızı dizin köküne yerleştirmek de işe yarar bir uygulamadır, çünkü bir bütün olarak çalıştığından farklı şekilde lisanslanan modüllerin lisanslarını belirsizleştirebilir. Projem FooProj'un bağımsız modül BarMod'u kullandığını varsayalım. Bağımsız modül MIT lisanslıyken FooProj GPL lisanslı olabilir. FooProj'u ilk açtığımda, kökte GPL'nin bir kopyasını görüyorum ve bir bütün olarak çalışmanın GPL lisanslı olduğunu anlıyorum. BarMod klasörüne indiğimde orada yeni bir lisans dosyası görüyorum ve bu klasörün içeriğinin MIT lisanslı olduğunu anlıyorum. Tabii ki, bu sadece yararlı bir yardımdır; modüllerinizin lisansını her zaman açıkça bir README, NOTICE veya benzeri bir dosyada belirtmeniz gerekir.

Özetle, dosya kökünü kullanmak kolaylık ve netlik konusudur. Yasal olarak bağlayıcı herhangi bir açık kaynak lisans metni görmedim ve bunun yasal olarak gerekli olmasının herhangi bir nedenini de bilmiyorum. Lisansın alıcı tarafından keşfedilmesi oldukça kolay olmalıdır; lisansın proje köküne dahil edilmesi bu kriteri yerine getirmek için yeterlidir, ancak gerekli değildir.

— apsillers
kaynak

BSD lisansı altında site.com/foo/license.txt için uzak bir siteye bağlanma olasılığını da göz önünde bulundurun, ancak o zamandan beri GPL v3 altında yeniden yayınlandı ve hangi site.com/foo/license. txt şimdi içeriyor. Ancak indirdiğiniz sürümün farklı hakları var.

Bu cevabı doğru olarak işaretledim, çünkü OSS lisanslaması hakkındaki geleneksel ve yasal bilgeliği ortaya koyuyor. Bununla birlikte , bu düşünce, içinde yaşadığımız bu destekli, sürüm kontrollü dünya için biraz paranoyak olarak beni etkiliyor. Kökte bulunan bir lisans. Ve risk daha büyük olsa bile, kod yorumlarında harici olarak barındırılan lisanslara atıfta bulunmanın aksine, geliştiricileri yazılımlarına tam lisansları dahil etmeye zorlayacak kadar şüpheliyim.

— samthebrand

FYI, belki de OSS lisansı için gelecek şeylerin bir işareti: Creative Commons 4.0 , lisans sahiplerinin atıf bilgilerini içeren ayrı bir sayfaya bağlanmasına izin verir.

— samthebrand

Ama bugün, bulut çağında yaşıyoruz. Örneğin, neden tam lisansı web sitemde barındıramıyorum ve kaynak lisansımın başlığına bu lisansın başlığını + URL'sini ekleyemiyorum?

Buna izin veren lisanslar var. Örneğin Apache 2.0. Apache 2.0 yalnızca her kaynak dosyanın Apache 2.0 Lisansının standart URL'sini gösteren küçük bir başlık içermesini gerektirir. Kaynak ağacın tam lisansının çoğaltılmasına gerek yoktur.

Apache 2.0 lisansının kendisinden:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

— Chadversary
kaynak

Ekin eksik olduğunu veya en azından lisansın bir kopyasını eklediğiniz varsayımıyla çalıştığını düşünüyorum. Dan 2.0 metnin kendisi Apache lisanslı çalışmaları dağıtmak zaman:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;

— apsillers

Projenin kökünde olması gerekmemektedir. Bu sadece en yaygın yer ve bu yüzden insanların lisansı bulmak için bakacakları ilk yer. Bu nedenle, yaygın olmasa bile, insanların muhtemelen ilk bakacağı yer. Lisans bilgilendirmek için mevcut olduğundan, bilgileri gizlemek pek mantıklı değildir.

Bir URL'nin arkasına gizlerseniz, URL'nin her zaman kullanılabilir olacağına dair kesin bir garanti yoktur. Projenin kökündeki bir dosyaysa, tanım gereği her zaman kullanılabilir olacaktır.

Kısacası, burası koymak için en etkili, en kullanıcı dostu yerdir.

— Bryan Oakley
kaynak

Proje kökü, ilk göründüğü yerdir: Ağacın en üstünde, klasör hiyerarşisinin köküdür. Tüm üst düzey belgeler oraya gitmelidir: benioku, lisans, vb. Bu dosyalar okuyucuyu projenin başka bir yerinde daha derin kazmaya yönlendirebilir, ancak kök bir şey aradığım ilk yerdir.