Bir bakışta FOSS lisanslaması: ince farklar
Ücretsiz ve açık kaynaklı yazılımın (FOSS) avantajları hızlı bir şekilde açıklanmaktadır: birçok tarafça test edilmiş ve ideal olarak projelerinize hızlı bir şekilde entegre edilebilen yüksek kaliteli yazılım bileşenleri sağlar. Bunun temelinde bilginin herkesin serbestçe erişebileceği ortak bir mal olduğunu ilan eden idealist bir temel yatmaktadır. Özgür Yazılım Vakfı'nın (FSF) kurucusu ve GNU projesinin başlatıcısı Richard M. Stallmann, bugün kırk yaşına giren hareketin manevi babası sayılabilir.
Duyuru
Manuela Astrid Weixlbaumer bir avukattır ve Linz/Avusturya'daki otomasyon uzmanı KEBA'da fikri mülkiyet uzmanı ve uyum görevlisi olarak çalışmaktadır. Fikri mülkiyet, dijitalleşme ve kadınların güçlendirilmesi konularını ele alan “kiraz derleyicisi” adlı vlog'u yönetiyor.
Geliştiriciler için bu başlangıçta pratik bir konudur, ancak iş bağlamında FOSS'un kullanımı rahatsız edici olabilir ve şüphe uyandırabilir. Özgür yazılım lisanslama ortamı değişiyor; dereceler ve sonuçlar vardır. Copyleft etkisi birçok kez ilgi odağı olmuştur: özel mülk yazılımla birlikte kullanılan açık yazılım, lisansıyla hibrit bir ürünün kapalı kısımlarına bile “bulaşır” ve bu da kaynak kodunun açıklanmasını gerektirir. Artık birçok şirket güvenlik listeleri istiyor. Hangi lisansların kullanılması gerektiğini, bunların nasıl farklılık gösterdiğini ve hangi alanlarda daha fazla dikkat edilmesi gerektiğini belirtirler.
Kısa bir tanım
FOSS, özgür ve açık kaynaklı yazılım için tarafsız kolektif bir terim olarak hizmet eder: Richard M. Stallman'ın liberal-idealist yaklaşımını Linus Torvalds'ın daha pragmatik yaklaşımıyla birleştirir. FOSS, yazılımın serbestçe ve lisans ücreti ödemeden kullanılabileceği anlamına gelir. Ve kaynak koduna serbestçe erişilebilir; kullanıcılar yazılımı değiştirebilir ve dağıtabilir.
FOSS ile yakından ilişkili olan yazılımlar, ücretsiz yazılımlar, paylaşılan yazılımlar ve kamuya açık yazılımlardır. Ancak bunların bazıları, özellikle de genellikle ticari yazılım olarak sınıflandırılan ücretsiz ve paylaşılan yazılımlar olmak üzere FOSS'tan önemli ölçüde farklılık gösterir. Bu nedenle ticari yazılım, özel yazılım ve kapalı kaynak FOSS'a aykırıdır. FOSS, üç ana lisans kategorisini tanır: katı copyleft lisansları, sınırlı copyleft lisansları ve izin veren lisanslar.
Katı copyleft
Copyleft, telif hakkının küçük kardeşi gibidir; ancak telif hakkının aksine Özgürlük kopyalamayı, değiştirmeyi ve dağıtımı yönetir. Copyleft sadece yazılım sektöründe değil, genel olarak telif hakkı lisanslama alanında da karşımıza çıkıyor. FOSS ile ilgili olarak copyleft, copyleft lisansından lisanslanan veya türetilen yazılımın (türev çalışma) yalnızca FOSS lisansının koşulları altında yeniden dağıtılabileceği anlamına gelir. Türev çalışma kavramı, copyleft'in var olup olmadığının belirlenmesinde belirleyici kriterdir.
Uygulamada bu, yazılımın aynı copyleft lisansı altında yeniden dağıtılması gerektiği anlamına gelir. Lisans metnine bağlı olarak, bu aynı lisans olmalıdır veya daha sonraki bir sürüme de başvurabilir – bu örneğin “yalnızca” veya “veya-” seçenekleriyle sunulan GPL (GNU Genel Kamu Lisansı) için geçerlidir. daha sonra “koşullar.
Bu nedenle copyleft yazılımı izin veren veya özel bir lisans altına yerleştirmek mümkün değildir. Yazılım, aynı zamanda lisans koşullarına göre onu değiştirme ve yeniden dağıtma yetkisine sahip olan topluluğun kullanımına açık kalır.
Copyleft lisansları aynı zamanda kötü şöhretli “viral etki” olan kaynak kodunun ifşa edilmesi gibi yükümlülükleri de beraberinde getirdiğinden, bunun şirketler üzerinde önemli bir etkisi olabilir. Bağlantılı özel bileşenlerin kapsamına ve kalitesine bağlı olarak, güvenlik açıkları veya ticari sırlar potansiyel olarak kamuya açıklanabileceğinden, bu durum şirketler için sorumsuzluk teşkil edebilir. Copyleft lisansının başlıca örneği GPL-2.0, onun revize edilmiş versiyonu GPL-3.0'ın yanı sıra AGPL-3.0, CPL-1.0 ve EPL-1.0'dır.
Standart olarak GPL 2.0
Klasik olanı ve özellikle pratikte geçerli olanı, Linux çekirdeğinin de lisanslandığı GPL 2.0'dır. Çok sayıda içtihat örneği sayesinde bu artık bir norm haline geldi. Almanya'da bu anlamda ilk öncü karar, GPL-2.0'ın genel koşullarının durumunu tanıyan ve Almanya'daki etkinliğini onaylayan Münih I Bölge Mahkemesi'nin (Az. 21 O 6123/04, 19 Mayıs 2004) kararıydı. 2007'de tanıtılan GPL 3.0, daha sonra GPL 2.0'da var olan boşlukları doldurdu; örneğin, GPL 3.0 ile çok daha zor hale gelen tivoizasyonla ilgili. Bu, orijinal olarak özgür yazılımla çalışan cihazlara özel mülk yazılımın yüklenmesini içerir.
GPL 2.0 ve GPL 3.0 gereklilikleri, lisanslar kapsamında dağıtılan programların tüm sürümleri için geçerlidir. Bu, bir programın değiştirilmemiş veya tadil edilmiş herhangi bir dağıtımının lisans koşullarına uygun olması gerektiği anlamına gelir. Temel taahhütler şunları içerir:
- Lisans metninin programın her kopyasıyla birlikte teslim edilmesi. Bu, basılı formatta veya metin dosyası olarak mümkündür ancak internetteki lisans metnine bağlantı yeterli değildir.
- Lütfen programın herhangi bir kopyasını dağıtırken bir telif hakkı bildirimi ekleyin. Burada GPL örnek metnini kılavuz olarak kullanmalısınız.
- Kaynak koduna erişilebilirlik yaratın. Bir program nesne kodu halinde derlenmişse veya çalıştırılabilir olarak sağlanmışsa, ilgili kaynak koduna da buradan erişilebilmelidir. Bu, kaynak kodunun tamamının bir veri taşıyıcısına sağlanması, teslimat için yazılı bir teklifte bulunulması veya kodun programın dağıtıldığı web sitesinde sunulması yoluyla yapılabilir.
Sınırlı copyleft lisansları, bağlantı istisnası veya sınıf yolu istisnası gibi istisnalarıyla birlikte özellikle GPL'yi içerir. Bunun en önemli örneği, farklı versiyonları da bulunan LGPL'dir (Kısıtlı Genel Kamu Lisansı). Program bileşenlerini, özellikle kitaplıkları dinamik olarak bağlarken, katı copyleft kuralına istisnalar sağlar. Dinamik bir bağlantı, statik bir bağlantının aksine, türev bir çalışmanın oluşturulmasını engeller, bu nedenle madde, copyleft'i tetiklemek için kritik öneme sahiptir.
Burada bağımsız kalan iki yazılım bileşeni arasında yalnızca gevşek bir bağlantı vardır. Bu tür istisnalar güçlü bir copyleft'i zayıf bir copyleft'e dönüştürebilir. Ayrıca, örneğin bir bağlantı biçimindeki teknik uygulamanın, lisans koşullarının geçerliliği açısından ne kadar belirleyici olabileceğini de açıkça göstermektedir.
İzin verilen lisanslar
İzin verilen lisansların en önemli temsilcileri arasında MIT lisansı, BSD hükümleri ve Apache lisansları yer alır. Bunlar copyleft maddesi olmayan ve daha düşük lisanslama gereksinimleri olan lisanslardır. Apache lisansının farklı versiyonları mevcuttur. Copyleft türev çalışmaları zorunlu kılmaz ancak yine de telif hakkı bildirimlerinin eklenmesi, lisans metninin eklenmesi ve sorumluluk reddi beyanı gibi belirli lisanslama gereksinimlerine uyulmasını gerektirir.
MIT lisansı son derece liberaldir; tek şartı lisans metninin ve telif hakkı bildiriminin sağlanmasıdır. Geliştiriciler ayrıca, telif hakkı bildirimini ve lisans metnini saklamak gibi izin verilen lisansın koşullarını yerine getirdikleri sürece, değiştirilen yazılımı yeni bir lisans kapsamında yayınlayabilirler. Bu başka bir açık kaynak lisansı veya özel bir lisans olabilir.
İzin veren lisanslar genellikle birbirleriyle de birleştirilebilir. Lisansların uyumluluğu oldukça pratik öneme sahiptir: örneğin A lisansı, B lisansının hariç tuttuğu bir şeye izin veriyorsa, bunlar birbirleriyle uyumlu değildir; bu durum özellikle copyleft alanında geçerlidir.
Pratik tavsiyeler
Bir şirketin nasıl ve hangi lisansları kullanacağı konusunda endişesi varsa, önceden kesin belgeler (malzeme listesi, malzeme listesi) çok önemlidir. Sonuçta bir üründe kullanılan FOSS bileşenleri hakkında bilgi sağlar. En azından bileşeninizin adını ilgili sürümdeki FOSS lisanslarıyla birlikte belirtin. Güvenilir bir liste yardımcı olabilir ancak yalnızca kılavuz olarak kullanılmalıdır.
Tabii ki, personel eğitimi de önemlidir: Şirkette yasal olarak atanan kişilerin ideal olarak programlamaya temel bir ilgisi olmalıdır; aynı zamanda ilgili geliştirme ekibinden en az bir kişi, ekip tarafından kullanılan bileşenlerin lisanslanmasını da kontrol etmelidir. Piyasada ayrıca FOSS'un analizine yardımcı olan tarama araçları da sunulmaktadır: şüphe durumunda bu tür araçlar yasal kesinlik yaratılmasına yardımcı olur ancak tek karar verme aracı olarak uygun değildir. Bu nedenle son kontrol daima sorumlu bir kişi tarafından gerçekleştirilmelidir.
Her zaman şu soru akla gelecektir: “FOSS bileşenini lisansa uygun çalışacak şekilde projeye nasıl dahil edebiliriz?” Ve eğer bu mümkün değilse seçenekler iki yola ayrılır: Ticari veya izin veren lisansı içeren bir alternatif var mı? Yoksa gerekli bileşeni kendimiz mi programlamalıyız?
(kki)