Bu faydalar ayrı ayrı topluluğun farklı bölümlerini güvence altına alıyor ancak bunları bağımsız kâr gütmeyen yapılarda toplamak katılımcıların kendilerini doğrudan ilgilendirmeyen durumlar hakkında gereğinden fazla ilgilenmekten kurtarır. Bu itibarla böyle bir kuruluşu oluşturmak genellikle tartışmalı değildir çünkü herkes bir fayda görebilir.
Elbette bir kuruluşu başlatmak topluluk ilişkileri sorunlarını çözmüyor. Eğer topluluk üyeleri arasında güven krizi gibi bir fonksiyon bozukluğu mevcutsa, sadece birleştirmek büyük ihtimalle bunu çözmeyecektir. Topluluk ilişkilerini ve güven sorunlarını birleşmeden önce çözmek önemli aksi takdirde bu sorunlar kuruluşun yapısı ve tüzüğü içerisine yerleşir, belirsiz bir biçimde sürer gider.
Apache Software Foundation ve Eclipse Foundation gibi uzun vadeli varlıkların istikrarlı büyüyüşü, OpenStack ve LibreOffice gibi büyük projeler için kuruluşların takdim edilmesi ve OW2, OuterCurve gibi genel amaçlı kuruluşların varlığı, açık kaynağın daha ileri gitmesini teşvikte kuruluşların artan önemini gösteren kanıtların bolluğunu ortaya koyuyor.
Tüm bu kuruluşlar temsil ettikleri aktivitelerin istikrarında güveni arttırıyor ve kurumsal katılımı cesaretlendiriyor. Bunların daha fazlasını göreceğiz.
2. Açık kaynak lisans seçeneklerinin çoğalması
Günümüz açık kaynak hareketinin bir diğer anahtar sürücüsü mevcut lisans seçeneklerinin büyük hacmi ve açık kaynak lisans seçeneklerinin değişim şeklidir; topluluğun önemini fark eden kurumsal organizasyonların artan katılımı sağ olsun.
Tüm yazılım otomatik olarak kendisini yazanı için olan telif hakkı korumasından faydalanıyor, kaynağın parçaları ve derlenmiş binary’ler dahil olmak üzere kaynak kodunun kopyalarını veya türevlerini kimin yapabileceği üzerinde kontrol sağlıyor. Yazılımın çalıştırılabilir sürümünün kullanılabilmesi için bir bilgisayar üzerine, yürütülebilmesi için bellek içine kopyalanması gerektiğinden, yazılımın herhangi bir kullanımı için telif hakkı sahibinden bir lisans alma zorunluluğu bulunuyor.
Açık kaynağın ilk günlerinde, telif hakkını lisanslamak için yaygın olan iki seçenek vardı. Bill Joy’un pragmatik istediğini yap görüşünü paylaşan insanlar onun öncülük ettiği Unix Berkeley System Distribution (BSD) üzerinde kullandığı gibi lisansları seçti. Richard Stallman’ın yazılım özgürlüğü sosyal mühendisliği ister görüşünü paylaşan diğerleri onun GNU Project için geliştirdiği General Public Licence’ı seçti; ona bu ad verildi çünkü bu genelin yararına olan bir lisans.
Bu fikirlerin işletmeler tarafından benimsenmesi Açık Kaynak Tanımı’nı lisansları açık kaynak olarak kategorize etme aracı olarak yaratmak için önemli bir motivasyondu. 1998’de diğerlerinin Mozilla projesinin deneyimini kopyalamak istedikleri açıktı ve bir yandan sıklıkla yazılım özgürlüğü dağıtma gereksinimini önemsemezken çalışmalarını “serbest” olarak açıklıyorlardı; günümüz gıda endüstrisindeki firmaların “organik” tanımını kullanmaları ama bu tanımın arkasındaki bütünlüğü sağlamamaları gibi. Bununla mücadele etmek üzere gerçekten “serbest” yazılımı işaret etmek için “açık kaynak” tanımını desteklemek adına Open Source Initiative oluşturulmuştu. Bu noktada herhangi bir kişi için yazılımı kullanma, üzerinde çalışma, değiştirme ve dağıtma özgürlüğünü sağlayan lisanslar OSI tarafından onaylanabilecekti.
GPL kullanmaktan kaçınmak isteyen işletmeler Mozilla projesi örneğini izleme eğilimindeydi ve kendi lisanslarını oluşturdular. Sonuç olarak açık kaynak döneminin ilk birkaç yılı içinde OSI tarafından 60’ın üzerine yeni lisans onaylandı. Fakat bu artışın bir maliyeti vardı. Açık kaynak lisansları sıklıkla birbirine karışmaz; kendinizinkini yaptığınızda, projenizi izolasyona mahkum edersiniz. Bu tür bir yeni bir lisans oluşturmak, açık kaynak içindeki lisansın rolünün temel bir yanlış anlaşımını ortaya çıkartan bir problemdir; ona geleneksel bir iki taraflı yasal anlaşma gibi yaklaşarak. Aksine bir açık kaynak lisansı çok taraflı bir anlaşmadır, Eben Moglen’in bir zamanlar belirttiği gibi “topluluk için anayasa”dır.
Son yıllarda yeni projeler topluluk formasyonu ve fonksiyonunu devreye sokmada lisansın rolünün daha fazla farkında oldu. Sonuç Apache Licence veya BSD/MIT lisansları gibi liberal lisanslara yönelik bir trend oldu. Böylelikle kurumsal katılımcıların katılımı için algılanan engelleri ortadan kaldırıyor. OpenStack, örneğin, liberal lisanslamayı kullanıyor.
Buna rağmen liberal BSD Unix lisansını kullanan projeler bazen, çalışmalarını katkısız olarak yürüten işletmelerden şikayet ediyor; copyleft (telif hakkının belirli bir kısmından feragat edildiği eser) için bir rol olduğunu hatırlatarak. Çoğu topluluk çalışmalarının kâr amaçlı olarak tüketildiği, hep alındığı ama hiç verilmediği zamanlarda kızdırılıyorlar. Bu adalet hissinin, GPL’den BSD’ye kayan göstergeyi, en iyi yakın zamanda yenilenen Mozilla Public Licence, MPLv2 ile temsil edilen orta zemine çevirmesi muhtemel. MPLv2 belirgin bir biçimde GPL ile uyumlu ve liberal lisanslarla karışmayı önleyen hiçbir madde içermiyor, onu günümüzün çoğu açık kaynak topluluklarının hassasiyetleriyle hizaya getiriyor. Proje tarafından yönetilen dosyalardaki değişikliklerin yayınlanması için zayıf bir copyleft koşulunu içeriyor ancak geliştiricilerin derlenmiş binary’leri istedikleri şekilde kullanmaları özgürlüğünü veriyor; bunları özel ürünler yaratmak üzere açık kaynak olmayan kodlarla karıştırmak da dahil.
