1 puan yazan GN⁺ 2025-10-17 | 1 yorum | WhatsApp'ta paylaş
  • Liquibase, mevcut açık kaynak lisansından Functional Source License(FSL) lisansına geçti
  • FSL, Open Source Initiative (OSI) ölçütlerine göre resmî bir açık kaynak lisansı olmamasına rağmen, README gibi yerlerde proje hâlâ açık kaynak olarak tanıtıldığı için bunun sorun olduğu öne sürülüyor
  • Toplulukta, FSL’nin resmî açık kaynak kriterlerini ihlal ettiği yönünde görüşler ile FSL’nin açık kaynak gerekliliklerini karşıladığı yönündeki karşıt görüşler dile getirildi
  • Proje içinde README’deki açık kaynak ifadeleri için düzeltme çalışmaları sürüyor
  • FSL’nin rekabetçi kullanımı sınırlayan maddeleri gibi nedenlerle OSI Open Source Definition (Açık Kaynak Tanımı) içindeki bazı maddelerle çeliştiği belirtiliyor

Sorunun özeti

  • Liquibase projesinin lisansı kısa süre önce Functional Source License(FSL) olarak değiştirildi
  • Ancak README.md gibi resmî belgelerde Liquibase hâlâ açık kaynak bir proje olarak tanıtılıyor, bu da topluluk içinde kafa karışıklığına ve görüş ayrılıklarına yol açıyor

Bildirimin içeriği ve tartışma

  • Sorunu açan kişi, Liquibase’in FSL’ye geçmiş olmasına rağmen hâlâ açık kaynak olduğunu belirtmesinin problemli olduğunu vurguluyor
  • Liquibase de FSL’nin bir açık kaynak lisansı olmadığını daha önce ifade etmişti
  • Proje belgelerinde açık kaynak teriminin artık kullanılmaması için README ve diğer belgelerde düzeltme yapılması talep ediliyor

Topluluk ve ilgili kişilerin görüşleri

  • Bazı katılımcılar, FSL’nin OSI onaylı açık kaynak lisanslarının kriterlerini karşıladığını savunuyor ve FSL resmî incelemeden geçip OSI onaylı bir lisans hâline gelirse ortada sorun kalmayacağını düşünüyor
  • Buna karşılık başka katılımcılar, FSL içindeki “izin verilen amaç” maddesi gibi unsurlar nedeniyle OSI Açık Kaynak Tanımı’nın çeşitli maddelerinin (1, 3, 5 ve 6. maddeler) ihlal edildiğini özellikle vurguluyor
  • “Fair Source” ile “gerçek açık kaynak” ayrımının altını çizerek, FSL’nin Fair Source olarak sınıflandırılması gerektiğini savunan görüşler de var

Sorunun çözüm süreci ve belge düzeltmeleri

  • Projeye katkı veren bir kişi, yapılan eleştiriye yanıt olarak README.md üzerinde değişiklik yapıyor ve açık kaynak ifadelerini kademeli olarak kaldırıyor
  • Ancak depo genelinde hâlâ bazı open source, oss ifadeleri kaldığı için ek inceleme ve temizlik yapılması planlanıyor

Açık Kaynak Tanımı ve FSL(Functional Source License) sorunu

  • Richard Fontana gibi açık kaynak dünyasının önde gelen isimleri, FSL’nin rekabetçi kullanımı yasaklayan maddeler gibi hükümler nedeniyle OSI Açık Kaynak Tanımı’nı ihlal ettiğini açıkça belirtiyor
  • Açık Kaynak Tanımı’nda “alan, kişi ve kuruluşlara karşı ayrımcılık yapmama” gibi maddeler bulunuyor ve rekabetçi kullanım yasağı buna aykırı kabul ediliyor
  • FSL’nin 2 yıl sonra MIT veya Apache License’a dönüşerek tamamen açık kaynak hâline gelmesi planlanıyor, ancak o zamana kadar kısıtlayıcı şartlar yürürlükte kalıyor

Sonuç ve mevcut durum

  • Bu konu, Liquibase’in açık kaynak olarak etiketlenmesinin düzeltilmesi sürecinde topluluğun şeffaflık talebini ve açık kaynağın özüne dair tartışmaları hızlandırıyor
  • README gibi resmî belgelerde düzeltme çalışmaları başlamış durumda ve Fair Source ile açık kaynak arasındaki ayrım ölçütleri somut bir örnek üzerinden tartışılıyor
  • OSI onayı olup olmamasından bağımsız olarak, lisansın fiilî koşulları uluslararası açık kaynak topluluğunda önemli bir anlam taşıyor

1 yorum

 
GN⁺ 2025-10-17
Hacker News görüşü
  • 4.x sürümünü artık kullanamaz hale gelme ihtimaline karşı alternatif aramaya başladım
    OSS lisansından ücretli modele geçişte, birilerinin faydalı bir yazılımdan gelir elde etmek istemesini anlıyorum
    Ama açık kaynaktan lisans değiştirmek bana bir tür yem-değiştir taktiği gibi geliyor
    Böyle kararlar güveni anında yok ediyor ve bugün para kazandırması zor olsa da uzun vadede potansiyeli olan kullanıcı kitlesini de kaybettiriyor
    Elastic ve TerraForm örneklerinden zaten önemli dersler çıkarılmış olmasını beklerdim
    Flyway de her an benzer bir yola gidebilir, bu yüzden ona olan güvenim de azaldı
    Eğer bir fork çıkmazsa, bizim gerçek kullanımımıza uyan bir migration kütüphanesini doğrudan kendimiz yazmayı da düşünüyorum
    Liquibase'i sadece kullanışlı olduğu için kullanıyorduk, asla vazgeçilmez değildi

    • EventstoreDB (şimdi KurrentDB) ve NATS'in de hizmet güvenilirliği açısından şüphe uyandırdığını düşünüyorum
      EventstoreDB zaten lisans değiştirdi, NATS ise kullanıcı tepkisi nedeniyle sadece plan aşamasında geri adım attı
      Artık bu tür hamleler bir çeşit iş stratejisine dönüşmüş gibi geliyor

    • Açık kaynağın en büyük avantajı, eski sürümleri istediğin zaman fork edip kullanabilmek
      Bence bu geçiş, özünde ürün fiyatını artırmaktan çok da farklı değil

    • Yalnızca Postgres için olsa da otomasyonu bir adım ileri taşıyan pgroll adlı bir proje de var

    • Flyway (Apache lisansı) dışında da Atlas (Apache), Sqitch (MIT) gibi hâlâ açık kaynak olan yeterince lisans var

    • Elastic'in lisans değişikliği kendi bakış açılarından gerçekten başarısız mıydı, merak ediyorum
      Hisse fiyatı bir süre düşmüştü ama şirketin kendisi hâlâ gayet sağlam durumda
      Benim tanıdığım arama ve RAG alanındaki geliştiricilerin hepsi hâlâ Elastic NV'nin sunduğu Elasticsearch'ü kullanıyor (açık kaynak fork veya alternatif yok)
      Özellikle Elastic'in en önemli gördüğü ana müşteri kitlesine (ücretli müşteriler) bakınca, bunun güven yıkımı değil tam tersine bir geri tepme etkisi yarattığı bile söylenebilir
      Gerçek gelir de 2020'ye kıyasla iki kat büyüdü

  • Hâlâ açık kaynak olduğunu iddia eden görüşler var ama Liquibase, FSL'in açık kaynak lisansı olmadığını kendisi de açıkça belirtiyor
    Liquibase resmî blog duyurusu

    • Bu değişikliğin üzerinden daha bir ay bile geçmediği için README'ye henüz düzgün yansımamış olabilir diye düşünüyorum
      Son dönemde yalnızca kaynağı açık olup açık kaynakmış gibi markalanan projelerin çoğalması üzücü
  • Liquibase güçlü bir copyleft (ör. GNU AGPL) yerine Apache'yi seçtiyse, başka şirketlerin kapalı kaynak türevler üretmesini elbette beklemeliydi
    Sonuçta bu Liquibase'in kendi seçimi olduğu için, sorumluluğun da Liquibase'te olduğunu düşünüyorum

    • Belirli bir sürenin ardından otomatik olarak Apache'ye dönen bir yapı gibi görünüyor
      Bunun daha iyi mi yoksa daha kötü mü olduğundan emin değilim

    • Şirketler aslında AGPL gibi lisanslarla da kendi hedeflerine rahatlıkla ulaşabilir
      Redis de geçiş yaptı ve topluluk tepkisi de olumluydu
      Liquibase AGPL dual lisans modelini seçseydi, kullanıcıların bundan rahatsız olacağını sanmıyorum

  • Buna sanırım "2 yıl gecikmeli açık kaynak" ya da "2 yıl sonra açık kaynak" demek lazım
    Ben buna daha çok "işe yaramaz hale geldiğinde açık kaynak" gözüyle bakıyorum
    Bu yaklaşımın özü, gerçek özgürlüğe saygı duyuyormuş imajı verip pratikte öyle olmaması gibi geliyor

    • Eski sürümlerin bu kadar hızlı işe yaramaz hale gelmesi de pek sık olmaz
      Bunu benim özgürlüğüme saygısızlık olarak görmüyorum
      Amaç, şirketlere (insanlara değil) bazı sınırlamalar getirmek

    • Kurumsal dünyada açık kaynağın özü bence "özgürlük"ten çok güven ve şeffaflık
      Sadece kaynağın açık olması bile, yasal/gelir modeli sorunları olmadan FOSS'un avantajlarını sunabilir
      İnternette açık kaynak modeline yönelik aşırı bir kör güven eğilimi var
      2 yıllık karma politika da bana yeterince makul geliyor; yeni lisansı istemeyen eski sürümü kullanır

    • Gecikmeli açık kaynak, İngilizcedeki 'late' gibi çift anlam taşıyor

    • #source-washing

  • Yeni lisansa aşina değilseniz FSL ayrıntı açıklaması bağlantısına bakabilirsiniz

    • FSL hakkında ek bağlam: bunu Sentry geliştirdi; neden böyle bir lisansa ihtiyaç duyduklarını ve hangi sorunu çözmeye çalıştıklarını Sentry blogunda görebilirsiniz

    • Bana göre kabul edilebilir tek kapalı kaynak lisansı BuSL, yani "Business Source License"
      4 yıllık sürenin sonunda mutlaka açık kaynak oluyor ve o zamana kadar da kaynak açık kalıyor
      Gereksiz lisans çoğalmasını da önlüyor
      Business Source License wiki sayfasına da bakılabilir

    • 2 yıllık sürenin fazla kısa olup olmadığını merak ediyorum
      Büyük şirketler açısından 5 yıllık yazılımlar da gayet kullanılabiliyor; ben de Redis'in 2012 sürümünü ya da Postgres'in 2020 sürümünü hâlâ yeterince iyi buluyorum

  • Bu tür vakaların geçmişini ve şirket listesini derlemiştim
    İlgili blog yazısında topladım; başka bildiğiniz varsa paylaşın lütfen

  • Pro özellikler, topluluk sürümünün sözdizimini sürekli bozduğu için ortada hiç şeffaflık yokmuş gibi hissettirdi
    Elbette yapılan işin adil bir karşılığı olmalı ama "bir zamanlar açık kaynaktık, sonra usulca değilmişiz gibi oldu" durumu fazla yaygınlaştı
    Bu geçişler sanki kimse fark etmesin isteniyormuş gibi hep sessiz sedasız yapılıyor

    • Aslında FSL sıradan bir geliştiricinin günlük akışını pek etkilemiyor
      Somut zararın ya da asıl sorunun tam olarak ne olduğunu merak ediyorum
      Hatta rekabetçi alanlarla rekabet dışı alanların ayrılmasını beğeniyorum
  • Yorumların genel havası bana biraz tuhaf geldi
    Çoğu kişi sadece "base" kısmını görüp alakasız servisler öneriyor ya da kaynak açıksa bunun zaten açık kaynak olduğunu savunuyor

  • Liquibase'in lisans değiştirdiğini bilmiyordum
    Aslında neredeyse her web framework için alternatif var ve Alembic ile Flyway gibi framework'ten bağımsız seçenekler de çok
    Bu noktada biraz garip görünüyor

  • Bu mesele Keycloak gibi OSS projelerinde de sorun çıkarabilir
    CNCF politikası gereği açık kaynak olmayan lisanslar kullanılamadığı için Keycloak, Liquibase'i kullanamayabilir
    Debian, Fedora gibi dağıtımlarda da OSS lisansı şartları olduğu için, Liquibase'e bağımlı projelerin bu dağıtımlara girip giremeyeceğini merak ediyorum
    Keycloak sorun ayrıntısı bağlantısı

    • Liquibase Debian ve Fedora'nın ana depolarına alınamaz
      Ama ayrı depolarda ya da rpm fusion non-free gibi özel depolarda yer alabilir