Hollanda ve AB yasaları kapsamında açık kaynak yazılım lisansları

Hemen hemen her ticari yazılım ürünü, genellikle yüzlerce olmak üzere, avukatlar yerine geliştiriciler tarafından seçilen açık kaynak bileşenleri içerir. Bu durum, hangi lisansların geçerli olduğunu, ne gerektirdiğini ve ürünün uyumlu olup olmadığını kimsenin söyleyemediği zaman sorun haline gelir. Bu makale, açık kaynak lisanslarının Hollanda ve AB yasaları kapsamında nasıl işlediğini, riskin nerede olduğunu ve nelere dikkat edilmesi gerektiğini açıklamaktadır.

Hukuki açıdan açık kaynak lisansı nedir?

Açık kaynak lisansı, koşullara bağlı olarak verilen bir telif hakkı lisansıdır. Bu bir feragat, kamu malına devir veya haklardan vazgeçme değildir ve bu açıdan Hollanda yasalarına göre diğer yazılım lisansları gibi işler . Yazar, bilgisayar programlarını eser olarak koruyan 1. ve 10. maddeler uyarınca telif hakkını saklı tutar ve lisans, aksi takdirde 12. ve 13. maddeler uyarınca münhasır hakları ihlal edecek eylemlere izin verir.

Sonuç, tanımından daha önemlidir. Kurallara uyarsanız, kopyalama ve dağıtımınız yasal olur. Kurallara uymazsanız, izin yaptığınız işlemi kapsamaz: kullanımınız telif hakkı ihlalidir, sözleşme ihlali değil. Çoğu copyleft lisansı, ihlal durumunda otomatik olarak sona ererek bunu pekiştirir — GPLv2 herhangi bir düzeltme süresi olmadan sona ererken, GPLv3 ve AGPLv3, ihlal bildirimden sonra tanımlanmış bir süre içinde düzeltilirse hakları geri verir.

Hollanda mahkemeleri bu mantığı uygulamaktadır. Rb. Amsterdam 22 Eylül 2020, ECLI:NL:RBAMS:2020:4717 sayılı kararda, çatallanmış bir kod tabanından lisans metnini ve telif hakkı bildirimini kaldıran bir dağıtıcının iznini kaybettiği ve ihlalde bulunduğu tespit edilmiştir. Çok miktarda yeni kod eklemek bağımsız bir eser yaratmamıştır: orijinal eser tanınabilir şekilde mevcut kalmıştır, bu nedenle yükümlülükler onunla birlikte devam etmiştir.

İki aile: izin verici ve copyleft

İzin verici lisanslar (MIT, BSD lisansları, Apache 2.0) telif hakkı bildirimlerini ve lisans metnini korumanız koşuluyla, kapalı kaynak kodlu ürünler de dahil olmak üzere kullanım, değişiklik ve yeniden dağıtıma izin verir.

Copyleft lisansları , yazılımı veya onun üzerine kurulu bir şeyi dağıtırken aynı lisans altında yapmanızı ve ilgili kaynak kodunu erişilebilir kılmanızı gerektirir. Kapsamları bakımından farklılık gösterirler.

Copyleft tetikleyicisi ve bağlantı sorusu

Copyleft yükümlülükleri kullanımda değil, dağıtımda geçerlidir. Dahili olarak GPL yazılımı kullanan bir şirket, ne kadar çok değişiklik yapmış olursa olsun, hiçbir şey dağıtmaz ve hiçbir şey borçlu değildir. "Dağıtım yaptık mı?" her zaman ilk sorulan sorudur ve bu nedenle konteynerler, cihazlar, bellenimler ve SDK'lar dahili araçlardan daha önemlidir.

İkinci soru daha zor. GPL, Amerikan hukukundaki türev eser kavramını ödünç alarak "Programa dayalı eser"den bahsediyor. Hollanda hukukunda böyle bir terim yok: analiz, çoğaltma ve uyarlama hakları üzerinden ilerleyerek, orijinal eserden korunan ifadenin çoğaltılıp çoğaltılmadığını sorguluyor.

Pratik örnek, bağlantı kurma işlemidir. Tescilli bir modülün GPL lisanslı bir kütüphaneye bağlanmasının, copyleft'e tabi tek bir eser oluşturup oluşturmadığı Hollanda mahkemeleri tarafından hiçbir zaman karara bağlanmamıştır ve bağlayıcı bir AB otoritesi de yoktur. Özgür Yazılım Vakfı'nın bağlantı kurmanın birleşik bir eser oluşturduğu görüşü, lisans yöneticisinin yorumudur, yasa değildir ve karşıt görüş de aynı şekilde test edilmemiştir. İnternetin en sevilen cevabı olan "dinamik bağlantı güvenli, statik bağlantı değil" ifadesinin, derleyicinin nasıl davrandığını sormayan Hollanda telif hakkı yasasında hiçbir dayanağı yoktur. Daha savunulabilir bir analiz, bileşenlerin ne kadar yakından birleştirildiğini sorar: adres alanı ve veri yapılarını paylaşıyorlar mı, kombinasyon tek bir ürün olarak mı gönderiliyor, her ikisi de tek başına çalışabilir mi, tescilli taraf copyleft tarafındaki başlıkları, makroları veya satır içi kodu yeniden üretiyor mu? Bu sorular genellikle riski çözer. Çözmedikleri durumlarda, bileşeni bir işlem sınırının arkasına izole edin, değiştirin veya ticari bir lisans alın.

AGPL ve ağ kullanımı

AGPL, telif hakkı ihlalinin dağıtım yoluyla tetiklenmesi ve SaaS sağlayıcılarının dağıtım yapmaması nedeniyle var olmuştur. Ağ maddesi, yazılımı değiştirip uzaktan etkileşim kuran kullanıcılara sunarsanız, onlara değiştirilmiş sürümünüzün ilgili kaynak kodunu da sunmanızı gerektirir.

Genellikle üç nokta gözden kaçırılıyor. Yükümlülük, hizmetin kullanıcılarına yöneliktir ki bu, açık kayıtlı bir üründe pek de rahatlatıcı değildir. Değişikliklerle tetiklenir, bu nedenle değiştirilmemiş bir bileşen bunu devreye sokmaz, ancak yamalanmış bir derleme devreye sokabilir. Ve bu, yığınınızın geri kalanı için GPL ile aynı birleşik çalışma sorusunu gündeme getirir; bu nedenle birçok şirket AGPL'yi üretim kodunda yasaklar.

Lisans uyumluluğu

Uyumluluk, lisansları aynı dağıtımda karşılanamayacak yükümlülükler getiren bileşenlerin birleştirilmesi sorunudur: izin verici lisanslar neredeyse her şeyle uyumludur, copyleft lisanslar ise yalnızca kendi şartlarının izin verdiği şeylerle uyumludur. Standart örnek Apache 2.0 ve GPLv2'dir. Apache Yazılım Vakfı ve Özgür Yazılım Vakfı, Apache 2.0'ın patent feshi ve tazminat hükümlerinin GPLv2'nin izin vermediği ek kısıtlamalar olması nedeniyle bu birleşimin izin verilmediği konusunda hemfikirdir. GPLv3, bunları kabul edecek şekilde tasarlanmıştır. Uyumluluk aynı zamanda yönlüdür: Apache kodu bir GPLv3 projesine dahil edilebilir, ancak tersi mümkün değildir. Yanlış yerde bulunan bir GPL bileşeni, yeniden lisanslama, yeniden mühendislik veya kaldırma arasında bir seçim yapmayı zorunlu kılabilir; bu da yayınlanmadan önce çok daha ucuzdur.

Atıf ve bildirim yükümlülükleri

En sık ihlal edilen yükümlülükler en az dramatik olanlardır: dağıtıma eşlik eden materyallerde telif hakkı bildirimlerinin, lisans metinlerinin, sorumluluk reddi beyanlarının ve Apache 2.0 kapsamındaki NOTICE içeriklerinin yeniden üretilmesi. MIT ve BSD dahil olmak üzere her lisans ailesi bunları zorunlu kılar. İhlal edilmelerinin nedeni, bunların kimseye ait olmaması ve düzeltilmesinin en kolay olmasıdır - genellikle ürünle birlikte gönderilen oluşturulmuş bir atıf dosyası. Yukarıdaki Hollanda davası tam olarak bu başarısızlıktan kaynaklanmıştır.

Patent verilmesi ve patent misillemesi

MIT ve BSD patentler hakkında hiçbir şey söylemiyor ve patent lisansının ima yoluyla verilip verilemeyeceği konusu belirsizliğini koruyor. Apache 2.0, her katkıda bulunandan açık, telifsiz bir patent lisansı ekledi ve buna bir misilleme maddesi de eşlik etti: Eserin ihlal ettiğini iddia ederek patent davası açarsanız, patent lisansınız sona erer. GPLv3 benzer bir hak tanıma ve kendi patent hükümlerini içeriyor.

Patent portföyüne sahip şirketler için iki önemli sonuç ortaya çıkıyor. Mühendisleriniz Apache veya GPLv3 lisanslı projelere katkıda bulunuyorsa, kendi patentleriniz kapsamında lisans veriyorsunuz demektir. Ve aynı Apache lisanslı bileşenleri kullanan bir şirkete karşı patent haklarınızı ileri sürerseniz, misilleme size güvendiğiniz bir lisansı kaybettirebilir.

EUPL ve Hollanda kamu sektörü

Avrupa Komisyonu tarafından Mayıs 2017'de uygulama kararıyla onaylanan Avrupa Birliği Kamu Lisansı sürüm 1.2, üç ayırt edici özelliği olan OSI onaylı bir copyleft lisansıdır.

• Dil. AB'nin resmi dillerinde mevcuttur ve onaylanmış tüm sürümlerin değeri aynıdır, bu nedenle Hollandalı bir yetkili makam Hollandaca sözleşme yapabilir.
• Uyumluluk. Ek bölümde, uyumlu lisanslar listelenmiştir; bunlar arasında GPLv2 ve v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ve CeCILL bulunmaktadır. Ayrıca, EUPL kodunu listedeki bir lisans altındaki kodla birleştiren türetilmiş bir çalışmanın, bunun yerine o lisans altında dağıtılmasına izin verilmektedir.
• Ulaşın. Dağıtım tanımı, eserin çevrimiçi veya çevrimdışı olarak erişilebilir hale getirilmesini kapsar. veya temel işlevlerine erişim sağlamakAyrıca, AB Halkla İlişkiler Kanunu'nun 5. maddesi, aynı işlevselliğin sunulduğu uzaktan etkileşimlerde de copyleft yükümlülüğünü sürdürmektedir. Bu nedenle, Genel Ürün Hukuku'nun (GPL) aksine, hizmet olarak sunulan yazılımları da kapsamaktadır.

Hollanda kamu sektörü müşterisi, yasal zorunluluktan ziyade politika gereği EUPL'yi (Avrupa Birliği Yazılım Lisansı) isteyebilir. 2024/903 sayılı Avrupa Birliği Birlikte Çalışabilirlik Yasası, kamu sektörü kuruluşlarını, eşdeğer olduğu durumlarda açık kaynak gibi kısıtlayıcı lisanslama şartları olmayan birlikte çalışabilirlik çözümlerine öncelik vermeye yönlendirmektedir; ulusal düzeyde, açık kaynak ilkesi, yasalara değil, kabine kararlarına ve politika çizgilerine dayanmaktadır: Dijital Devlet Yasası, dijital kimlik altyapısını kolaylaştırır ancak tüm kaynak kodunu yayınlama konusunda bağlayıcı bir yükümlülük getirmez. İhale belgelerini okuyun: EUPL gerekliliği, teslim edeceğiniz ürünü bağlar ve yeniden kullanmayı düşündüğünüz tescilli kodla uyumsuz olabilir.

Uygulamada yaptırım

Kim dava açabilir? Hak sahibi – bireysel katkıda bulunanlar veya telif hakkını elinde bulunduran vakıf veya şirket. Parçalı yazarlık pratik bir engel teşkil eder: davacı, söz konusu kodun sahipliğini kanıtlamak zorundadır. Bu durum, bir çekirdek geliştiricisinin sanallaştırma satıcısına karşı açtığı davanın yazarlık kanıtı eksikliği nedeniyle başarısız olduğu en bilinen Avrupa GPL davasını da geçersiz kılmıştır (Hamburg Yüksek Mahkemesi 8 Temmuz 2016, 310 O 89/15; Hamburg Yüksek Mahkemesi 28 Şubat 2019, 5 U 146/16 ile onaylanmıştır).

Yargı içtihatlarının ortaya koyduğu hususlar şunlardır: Alman mahkemeleri, ilk GPL ihtiyati tedbir kararıyla (LG München I 19 Mayıs 2004, 21 O 6123/04) başlayarak, açık kaynak lisanslarının geçerli olduğunu ve ihlal edilmesinin dağıtımı yasa dışı hale getirdiğini defalarca kabul etmiştir. ABD Federal Temyiz Mahkemesi de Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008) davasında aynı sonuca varmıştır: lisans şartları, yalnızca birer taahhüt değil, verilen hakkın kapsamına ilişkin koşullardır; bu nedenle ihlal, telif hakkı iddiasını ve ihtiyati tedbiri destekler. ABD'deki davalar, bir alt alıcının üçüncü taraf lehtarı olarak GPL'yi uygulayıp uygulayamayacağını araştırmaktadır. Bu, Kaliforniya Yüksek Mahkemesi önündeki Software Freedom Conservancy v Vizio davasının temel sorusudur : tüketiciler, üçüncü taraf lehtarları olarak, GPLv2 kapsamında kaynak kodunun yayınlanmasını talep edebilirler mi? 23 Aralık 2025'te mahkeme, özet yargılama yoluyla bir noktaya karar vererek, GPLv2 ve LGPLv2.1'in, işlevselliği bozulmadan cihaza yeniden kurulabilen kaynak koddan ziyade, başka yerlerde kullanılmak üzere elde edilebilen ve yeniden işlenebilen kaynak kod gerektirdiğine hükmetti. Üçüncü taraf yararlanıcı sorunu ise, birden fazla kez ertelenen duruşmaya bırakıldı. Her halükarda bu bir Kaliforniya sözleşme hukuku sorusu olduğundan, Hollanda'da bağlayıcı bir etkisi yoktur; değiştireceği şey, şikayet edebilecek kişi sayısıdır.

Hollanda mahkemesinin bu konuya yaklaşımı şu şekilde olurdu: Telif hakkı ihlali olarak, davacı mülkiyeti ve çoğaltma veya iletişimi kanıtlar; davalı lisansı ileri sürer; davacı ise şartlarının yerine getirilmediğini savunur, bu nedenle savunma başarısız olur. 6:265 BW maddesi uyarınca sözleşmesel çözüm yolları paralel olarak işler, ancak telif hakkı daha güçlü bir yoldur.

Çözümler. Genellikle ceza ödemesi içeren ve özet yargılama usulünde uygulanabilen, Madde 3:296 BW uyarınca ihtiyati tedbir; Madde 27 Aw uyarınca tazminat ve Madde 27a Aw uyarınca karların hesabı; Madde 28 Aw uyarınca geri çağırma, teslim veya imha; ve Madde 1019h Rv uyarınca makul ve orantılı yasal masrafların tam olarak karşılanması. Yazılım ücretsiz olarak dağıtıldığında, zararın miktarını belirlemek zordur ve bir Alman temyiz mahkemesi ihtiyati tedbiri onaylarken tazminat vermeyi reddetmiştir (OLG Hamm 13 Haziran 2017, 4 U 72/16). Asıl can sıkıcı olan nadiren tazminattır: asıl can sıkıcı olan ihtiyati tedbir, geri çağırma, masraf kararı ve asla yayınlamayı düşünmediğiniz kaynak kodunu yayınlamak zorunda kalmaktır.

Uyumlulukla ilgili bir sorun keşfettiğinizde

Keşif genellikle müşterinin güvenlik anketinden, durum tespiti sırasında yapılan bir taramadan veya hak sahibinden gelen bir mektuptan kaynaklanır. Ardından düzeltme şu şekilde yapılır: Eğer risk ciddi ise, etkilenen sürümün dağıtımını durdurun. Hangi bileşenin, hangi sürümün, hangi lisansın, hangi ürünlerin ve sürümlerin, hangi süre boyunca etkilendiğini belirleyin. Lisansın aslında ne gerektirdiğini anlayın - genellikle kaynak kod sürümü yerine bir atıf dosyası. Gerekli belgeleri hazırlayın: bildirimler, lisans metinleri, derleme komut dosyaları da dahil olmak üzere ilgili kaynak kodunun tamamı ve kullanıldığı yerlerde yazılı bir teklif. Uygun bir sürüm yayınlayın, ardından hak sahibine ne yaptığınızı bildirin, yapmanız gerekip gerekmediği konusunda tartışmaya girmeyin.

GPLv3 ve AGPLv3 kapsamında düzeltme süresi, hız açısından hukuki değer taşır; GPLv2 kapsamında ise düzeltme hakkı yoktur, bu nedenle çoğu yaptırım müzakere yoluyla varılan bir uyumluluk taahhüdüyle sonuçlanır. Ayrıca, ayrıcalığın avukatınızdan aldığınız tavsiyeye uygulandığını, ancak dahili bir mühendislik raporuna uygulanmadığını da unutmayın.

Birleşme ve devralmalarda ve durum tespitinde açık kaynak kodlu yazılım

Bir yazılım satın alımında, açık kaynak kodlu yazılımlar standart bir inceleme sürecidir ve temel üründeki açıklanmamış bir copyleft bileşeni, anlaşmayı gerçekten etkileyebilecek birkaç bulgudan biridir: eğer ürün kaynak kodu yayınlanmadan dağıtılamıyorsa, alıcı fiyatlandırılan varlıktan farklı bir varlık satın alıyor demektir.

Kod tabanı taraması, lisanslı bileşen envanteri ve katkıda bulunanlar ile yüklenici düzenlemeleri hakkında sorular bekleyin. Tipik sonuçlar arasında belirli bir tazminat, düzeltme yapılana kadar bir ödeme ertelemesi, kaldırmayı gerektiren bir ön koşul veya özel bir açık kaynak garantisi yer alır. Satıcılar önce tarama yapmalıdır: sizin açıkladığınız bulgular bir müzakere konusudur, alıcının danışmanının yaptığı bulgular ise bir kozdur. Alıcılar "şirket fikri mülkiyetine sahiptir" ifadesini değil, hiçbir ürünün tescilli kaynak kodunun açıklanmasını gerektiren açık kaynak içermediğine dair bir beyanı aramalıdır.

Malzeme listesi, tarama ve Siber Direnç Yasası

Yazılım malzeme listesi, bir ürünün bileşenlerinin, sürümlerinin ve lisanslarının envanteridir. Yakın zamana kadar tamamen sözleşmeye dayalı olan bu belge, artık yasal bir zorunluluk da taşımaktadır.

Siber Dayanıklılık Yasası, (AB) 2024/2847 Yönetmeliği, 10 Aralık 2024 tarihinde yürürlüğe girmiş ve kademeli olarak uygulanmaktadır. Bu yasa, üründen ziyade kuruluşu ele alan Hollanda Siber Güvenlik Yasası ile birlikte geçerlidir . 14. maddede belirtilen aktif olarak istismar edilen güvenlik açıkları ve ciddi olaylara ilişkin raporlama yükümlülükleri 11 Eylül 2026 tarihinden itibaren; uygunluk değerlendirme kuruluşlarına bildirim hükümleri 11 Haziran 2026 tarihinden itibaren; Yönetmeliğin tamamı ise 11 Aralık 2027 tarihinden itibaren (71. madde) yürürlüğe girecektir. 1. madde, üreticilerin ürün içindeki bileşenleri tanımlamasını ve belgelemesini, en azından üst düzey bağımlılıkları kapsayan, yaygın olarak kullanılan ve makine tarafından okunabilir bir formatta bir yazılım malzeme listesi hazırlamasını gerektirmektedir. Yayınlanması zorunlu değildir; piyasa gözetim yetkilileri bunu talep edebilir.

Ticari faaliyet dışında sağlanan ücretsiz ve açık kaynaklı yazılımlar, Siber Dayanıklılık Yasası (CRA) kapsamı dışında kalmaktadır. Yönetmelik, açık kaynaklı yazılımların ticari faaliyetler için geliştirilmesine sürekli destek sağlayan bir tüzel kişi olan açık kaynaklı yazılım yöneticisini, CRA'nın 24. maddesindeki daha hafif yükümlülüklerle (belgelenmiş bir siber güvenlik politikası, piyasa gözetim yetkilileriyle işbirliği ve raporlama) tanıtmaktadır. Açık kaynaklı yazılımı ticarileştiriyorsanız veya başkalarının ticarileştirdiği bir projeyi finanse ediyorsanız, hangi rolü üstlendiğinizi belirleyin. Komisyon, 27 Temmuz 2026'da ilk kılavuzunu kabul etti: C(2026) 5252 sayılı tebliğe ekli olan Siber Dayanıklılık Yasası'nın (CRA) uygulanmasına ilişkin Komisyon kılavuzu, diğer hususların yanı sıra ücretsiz ve açık kaynaklı yazılımların ne zaman kapsam içine girdiğini ele almaktadır. Yazılım malzeme listesi için bir format belirleyen bir uygulama yasası kabul edilmediğinden, Yönetmeliğin kendi standardı - yaygın olarak kullanılan, makine tarafından okunabilir bir format - şimdilik ölçüt olarak kalmaktadır.

Sürekli entegrasyon (CI) ortamında çalıştırılan yazılım bileşimi analizi, uyumluluk, lisans incelemesi ve özen gösterme işlemlerini aynı anda gerçekleştiren bir envanter oluşturur. Bu tür araçlar, tedarikçi tarafından sağlanan kodları gözden kaçırır, çift lisanslı projeleri yanlış tanımlar ve bir lisansın koşullarını okuyamaz: çıktıyı incelemenin başlangıcı olarak değerlendirin, incelemenin tamamı olarak değil.

Kendi kodunuzu yayınlarsanız: CLA'lar ve DCO

Kod yayınlayan ve dışarıdan katkı kabul eden bir şirket, birleştirdiği şeyin haklarına sahip olduğunu bilmelidir. Katkıda bulunan lisans sözleşmesi , genellikle geniş bir telif hakkı lisansı ve açık bir patent lisansı veren, özgünlük ve yetki konusunda garantiler içeren, proje ile katkıda bulunan arasında yapılan bir sözleşmedir. Bu, bir şirketin projesini daha sonra yeniden lisanslamasına veya açık kaynak lisansının yanı sıra ticari lisanslar sunmasına olanak tanır. Maliyeti ise sürtünmedir.

Linux çekirdeği ve birçok diğer proje tarafından kullanılan Geliştirici Menşe Belgesi ( Developer Certificate of Origin) , bir lisans verme belgesi değil, katkıda bulunanın kodu projenin lisansı altında gönderebileceğini onaylayan, her commit'e eklenen hafif bir tasdik belgesidir. Daha az külfetli ve daha az koruyucu: patent lisansı yok, yeniden lisanslama yok.

Çift lisanslama veya gelecekte yeniden lisanslama olasılığı varsa, bir CLA (Kredi Lisanslama Anlaşması) kullanın; proje gerçek bir ortak alan ise, genellikle bir DCO (Dijital Telif Hakkı Anlaşması) yeterlidir. Her iki durumda da, çalışanlarınızın yazdığı kod üzerindeki telif hakkının istihdam ve yüklenici sözleşmelerinizde belirtildiğinden emin olun.

Pratik bir politika kontrol listesi

• Ürün ve sürüm başına bileşen envanterini, elle değil, derleme hattında oluşturun ve yayınlayın.
• İç politikanızı yayınlayın: izin verilenler listesi, yasaklananlar listesi ve geri kalan her şey için bir onay yolu.
• Dağıtım olarak neyin sayılacağını yazılı olarak tanımlayın: şirket içi kurulumlar, cihazlar, konteynerler, SDK'lar, mobil uygulamalar, bellenim.
• Oluşturulan ilişkilendirme dosyasını her ürünle birlikte gönderin.
• Lisans tercihlerini, bir bileşen seçildiğinde, yani tasarım aşamasında onaylayın, sürüm aşamasında değil.
• İlgili patent haklarını göz önünde bulundurarak, dış projelere yapılan katkıların onay gerektirip gerektirmediğine karar verin ve ilk dış katkıdan önce bir CLA veya DCO seçin.
• Fikri mülkiyet garantilerini, tazminatları ve emanet koşullarını, üründe fiilen yer alan açık kaynak kodla uyumlu hale getirin.
• Değerlendirmeyi, bağış toplama veya satış sürecinden önce yapın, süreç sırasında değil.

Law & More Yazılım şirketlerine ve yatırımcılarına danışmanlık hizmeti vermektedir. Eindhoven hem de Amsterdam Bir işlemde açık kaynak uyumluluğu, lisans incelemesi, katkıda bulunanlarla yapılan düzenlemeler ve açık kaynak çalışma akışı konularında.