Açık Kaynak (Open Source) Nedir?
Kısa tanım
Açık kaynak (open source), kaynak kodu herkesin inceleyebileceği, kullanabileceği, değiştirebileceği ve yeniden dağıtabileceği şekilde lisanslanmış yazılımdır. Belirleyici olan, kodun internette görünür olması değil, lisansın bu hakları açıkça tanımasıdır. Open Source Initiative'in (OSI) Açık Kaynak Tanımı'na uyan lisanslar bu kapsamdadır; MIT, Apache 2.0 ve GPL en bilinen örneklerdir. Linux, PostgreSQL ve React açık kaynak projelerdir.
Diğer adları: open source, açık kaynak yazılım, açık kaynak kod, OSS, FOSS
Kodun görünmesi yetmez, lisans belirler
GitHub'da herkese açık duran bir depo kendiliğinden açık kaynak değildir. Lisans dosyası olmayan kod, telif hukuku açısından varsayılan olarak “tüm hakları saklı” kabul edilir: okuyabilirsiniz, ama kopyalama, değiştirme ve dağıtma izniniz yoktur. Bir yazılımı açık kaynak yapan şey, bu hakları açıkça tanıyan bir lisansla yayımlanmasıdır.
Hangi lisansın açık kaynak sayılacağı konusunda en yaygın referans OSI'nin Açık Kaynak Tanımı'dır. Tanım on ölçüt içerir; serbest yeniden dağıtım, kaynak koduna erişim ve türev çalışmalara izin bunların başındadır. Daha az bilinen ama pratikte önemli bir ölçüt, lisansın belirli bir kullanım alanını yasaklayamamasıdır. “Kodu görebilirsiniz ama ticari olarak kullanamazsınız” diyen bir lisans bu nedenle açık kaynak değil, source-available (kaynağı erişilebilir) sayılır. Son yıllarda bazı veritabanı ve altyapı projelerinin bu tür lisanslara geçmesi, “açık kaynak” etiketinin neden dikkatle okunması gerektiğini gösterdi.
Benzer bir ayrım “free software” (özgür yazılım) hareketinde de vardır. Oradaki “free”, bedava değil özgür anlamındadır; FOSS kısaltması iki geleneği birlikte anar.
İzin verici ve copyleft lisanslar
Açık kaynak lisansları, türev çalışmalara ne yükledikleri açısından iki ana gruba ayrılır. Aşağıdaki tablo kavramsal bir özettir, hukuki görüş değildir; somut bir ürün ve dağıtım modeli için lisans metni okunmalı, gerekirse bir hukukçuya danışılmalıdır.
| Grup | Örnekler | Temel yükümlülük |
|---|---|---|
| İzin verici (permissive) | MIT, BSD, Apache 2.0 | Telif ve lisans bildirimini korumak. Kod kapalı kaynaklı bir ürünün içinde kullanılabilir. Apache 2.0 ayrıca açık bir patent lisansı içerir. |
| Zayıf copyleft | LGPL, MPL 2.0 | Kütüphanenin kendisinde yapılan değişiklikler aynı lisansla paylaşılır; onu kullanan uygulamanın geri kalanı genellikle kapsam dışında kalır. |
| Güçlü copyleft | GPL | Türev çalışma dağıtılıyorsa bütünü aynı lisansla ve kaynak koduyla birlikte sunulmalıdır. |
| Ağ copyleft'i | AGPL | GPL'e ek olarak, değiştirilmiş yazılım kullanıcılara ağ üzerinden hizmet olarak sunuluyorsa da kaynak kodu sağlanmalıdır. |
GPL'in yükümlülükleri yazılımın dağıtılmasıyla tetiklenir. Kendi sunucunuzda çalışan ve kullanıcıya yalnızca web arayüzü olarak ulaşan bir SaaS ürünü bu nedenle GPL'in klasik kapsamına girmeyebilir; AGPL tam olarak bu boşluğu kapatmak için yazılmıştır. Mobil uygulama veya kuruluma verilen masaüstü yazılımında ise tablo farklıdır, çünkü yazılım kullanıcıya dağıtılır.
Bedava mı, ucuz mu?
Açık kaynak yazılımın lisans bedeli genellikle yoktur, ama toplam maliyeti sıfır değildir. Güncellemeleri takip etmek, güvenlik yamalarını uygulamak, sürüm yükseltmelerinde kırılan yerleri düzeltmek ve gerektiğinde destek almak birinin işidir. Pek çok proje de bu yüzden ticari bir modelle birlikte yaşar: ücretli destek, barındırılan (managed) sürüm ya da çekirdeği açık, kurumsal özellikleri ücretli “open core” yaklaşımı.
Öte yandan açık kaynak, özel yazılım projelerinin neredeyse tamamının temelidir. Bir web uygulaması tipik olarak açık kaynak bir işletim sistemi, veritabanı, programlama dili ve framework üzerinde çalışır; ekip yalnızca işe özgü kısmı yazar. Kaynak koduna erişebilmek, bir tedarikçinin ürünü bırakması ya da fiyatı değiştirmesi riskine karşı da güvence sağlar.
Bir projeye açık kaynak bağımlılık eklerken
- Lisans uyumu: Paketin lisansı ürününüzün dağıtım modeliyle uyumlu mu? Paketin kendi alt bağımlılıkları da hesaba katılmalıdır.
- Bakım durumu: Son sürüm ne zaman çıktı, açık hata kayıtlarına cevap veriliyor mu, proje tek bir gönüllünün omzunda mı?
- Güvenlik: Bilinen güvenlik açıkları için otomatik tarama yapılıyor mu, yamalar hızlı çıkıyor mu?
- Gerçek ihtiyaç: Birkaç satırla yazılabilecek bir iş için yeni bir bağımlılık eklemek, saldırı yüzeyini ve bakım yükünü gereksiz yere büyütür.
Kullanılan bileşenlerin ve lisanslarının listesini tutmak (SBOM, yazılım malzeme listesi) hem lisans denetiminde hem de yeni bir güvenlik açığı duyurulduğunda “bizi etkiliyor mu?” sorusuna dakikalar içinde cevap vermekte işe yarar.