B&KBakırcı & KeskinHUKUK BÜROSU
TR
TürkçeEnglishDeutschРусскийالعربية中文
Menü

MPL 2.0 Lisanslı Dosyaları Kapalı Kaynak Ürüne Eklemek: Dosya Bazında Yükümlülük

MPL 2.0 lisanslı kod, kapalı kaynak bir ticari ürünle birlikte kullanılabilir; ancak lisans kapsamındaki kaynak dosyaları ve bu dosyalardaki değişiklikler için MPL koşulları korunmalıdır. Lisansın 1.10, 3.1, 3.2 ve 3.3 hükümleri birlikte okunduğunda incelemenin dosya kapsamı üzerinden yapılması gerektiği görülür. Ürünün bütünü için tek bir “açık” veya “kapalı” etiketi kullanmak, hangi dosyanın hangi izinle dağıtıldığını açıklamaz.

MPL 2.0 dosyalarının belirlenmesi, değişikliklerle bağımsız dosyaların ayrılması ve kaynak erişiminin sağlanması şeması
MPL koşulları, kapalı ürünün etiketi üzerinden değil kapsam içindeki kaynak dosyaları üzerinden değerlendirilir.

Ticari ürün geliştiren şirket için temel soru şudur: MPL kapsamındaki dosyada mı değişiklik yapıldı, bu kod yeni bir kaynak dosyasına mı alındı, yoksa MPL kodu içermeyen ayrı dosyalarla daha büyük bir ürün mü oluşturuldu? Bu ayrım, müşteriye hangi kaynağın sunulacağını belirler. Çalıştırılabilir paketin tek dosya olması, kaynak dosyaları bakımından yapılan lisans incelemesini tek başına ortadan kaldırmaz.

MPL lisansının koruduğu hak ve verdiği izin

FSEK m.2 bilgisayar programlarını eser niteliğinin koşulları içinde korur. Programı uyarlama, çoğaltma ve dağıtma işlemleri m.21, m.22 ve m.23 bakımından değerlendirilir. MPL 2.0, hak sahiplerinin bu işlemlere belirli koşullarla izin vermesidir. Lisansın ücretsiz olması, kodun kamuya terk edildiğini veya üzerindeki hakların şirkete geçtiğini göstermez.

Mozilla Public License 2.0 metninin 2.7 hükmü, 3.1–3.4 hükümlerini verilen izinlerin koşulları olarak belirtir. Kaynak sunma, dağıtım ve bildirim düzenini yalnız gönüllü proje davranışı saymak bu yapıyla uyuşmaz. Şirketin dosyayı kopyalaması, değiştirmesi veya ürününe katması sırasında hangi izne dayandığı belirlenmelidir. Lisans yükümlülüğü, dosyanın ücretsiz indirilmiş olmasından bağımsız incelenir.

Genel hak sahipliği ve eser koruması için yazılımın telif hakkıyla korunması rehberi başlangıç çerçevesini sunar. Buradaki özel inceleme, programın MPL kapsamındaki kaynak dosyalarının daha büyük üründe hangi statüyü koruduğudur. Şirketin yeni yazdığı ayrı kodun hak sahibi olması, başka kişinin dosyasına getirdiği değişiklikleri lisansın kapsamından kendiliğinden çıkarmaz.

Dosya bazında kapsam nasıl belirlenir?

MPL 2.0 m.1.10, kapsam içindeki kaynak dosyasına ekleme, çıkarma veya içerik değişikliği yapılmasıyla ortaya çıkan dosyayı değişiklik kapsamında tanımlar. Kapsam içindeki kodu barındıran yeni kaynak dosyası da bu tanıma dâhildir. Bu nedenle yalnız yeni dosya adı vermek, alınan kodun lisans bağını kesmez. İncelemenin konusu dosyanın adı değil, içerdiği kaynak ve bu kaynağın geçmişidir.

Kaynak incelemesi, ilk alınan dosyayı değişiklik geçmişiyle karşılaştırarak yürütülür. Dosyada şirketin sonradan eklediği bölümler, önceki koddan fiziksel olarak ayrılmamışsa “bu satırları biz yazdık” açıklaması tek başına dosyanın MPL yükümlülüğünü kaldırmaz. Lisansın değişiklik tanımı, dağıtılan kaynak dosyası düzeyinde uygulanır. Kod inceleme raporu, hangi dosyanın neden kapsam içinde olduğunu açıkça göstermelidir.

MPL kodu içermeyen yeni ve ayrı kaynak dosyaları için ise aynı sonuç otomatik kurulmaz. Mozilla’nın MPL 2.0 resmî açıklaması bu ayrı dosyaların daha büyük bir ürün içinde farklı lisansla kullanılabilmesini açıklar. Ayrı dosyanın gerçekten kapsam içi kod içermemesi önemlidir. Dosya taşıma, kod kopyalama ve bağımsız geliştirme işlemleri depo geçmişinde birbirinden ayrılmalıdır.

Kapalı kaynak ürünün tamamını açmak gerekir mi?

MPL m.1.7 ve m.3.3, kapsam içi yazılımın ayrı dosyalardaki diğer materyalle daha büyük bir eser içinde birleştirilmesini düzenler. Bu yapı, kapsam içi dosyaların koşullarına uyulmak üzere daha büyük ürünün farklı şartlarla dağıtılmasına izin verir. Dolayısıyla sırf ürün bir MPL bileşen içeriyor diye şirketin bütün kaynak deposunun müşteriye açılacağı sonucuna varılmaz.

Bunun tersi de yanlıştır: Ürünün büyük çoğunluğu şirkete ait diye küçük MPL bölümünün kaynak şartı yok olmaz. Ticari değer veya dosya sayısı üzerinden lisans kapsamına yüzdesel istisna eklenemez. Üründe hangi kapsam içi dosyanın bulunduğu ve o dosyanın nasıl dağıtıldığı gösterilmelidir. Yazılım malzeme listesi bu işte yardımcıdır; fakat listedeki etiketin gerçek dosya içeriğiyle doğrulanması gerekir.

Ürünün kapalı kısmı ile MPL kısmı için hazırlanan sözleşme ve teslim belgeleri birbirine uygun olmalıdır. Müşteriye bütün paket için sınırsız kaynak yasağı veya bütün kaynakların tek şirkete ait olduğu taahhüdü verildiğinde, üçüncü taraf izinleri yanlış anlatılmış olur. Hakların ve ruhsatın yazılı kapsamı bakımından FSEK m.52 kapsamında telif sözleşmesinin şekli ayrıca değerlendirilmelidir.

Statik bağlama veya tek çalıştırılabilir dosya sonucu değiştirir mi?

Mozilla’nın resmî SSS metni, MPL dosyalarının daha büyük kapalı bir yazılıma statik bağlanmasını mümkün kullanım biçimleri arasında açıklar. Çalıştırılabilir çıktının tek dosya olması, bütün bağımsız kaynak dosyalarını aynı lisansa dönüştüren bir ölçüt değildir. İncelemede kaynak dosyalarının niteliği ile derleme çıktısının paketlenme şekli ayrı tutulmalıdır. Dosya bazında kapsam, doğrudan ikili paket sayısından hesaplanmaz.

Ancak tek ikili dosya içinde kapsam içi kod dağıtılıyorsa kaynak erişimi yükümlülüğü gündemden çıkmaz. Ürün yöneticisi “müşteriye yalnız uygulama veriyoruz” dediğinde, hukuk dosyasında o uygulamanın hangi kaynak dosyalarından üretildiği gösterilmelidir. Derleme kaydı ve bileşen sürümü, kaynak sağlama işinin doğru materyale yönelmesini sağlar. Kaynak yalnız teknik depoda durduğu için müşteriye sunulmuş sayılmaz.

Bu ayrım özellikle dışarıdan alınan kütüphanelerin ürün içine gömüldüğü dağıtımlarda önemlidir. Tedarikçinin teslim ettiği ikili dosya içinde MPL bileşen bulunduğu biliniyorsa, gerekli kaynak ve bildirim akışı sözleşmede açıklanmalıdır. Son müşteriye dağıtım yapan şirket, tedarikçiye gönderdiği genel bir e-postayı tek başına kendi teslim yükümlülüğünün yerine getirilmesi olarak değerlendirmemelidir. Gerçek pakette ne sunulduğu kontrol edilir.

Çalıştırılabilir biçimde dağıtımda kaynak nasıl sağlanır?

MPL m.3.2(a), çalıştırılabilir biçimde dağıtılan kapsam içi yazılımın kaynak biçiminin de sunulmasını ve alıcılara kaynağın nasıl edinileceğinin bildirilmesini ister. Kaynağın makul yöntemle, zamanında ve alıcıya dağıtım maliyetini aşmayan bedelle elde edilebilmesi düzenlenmiştir. Bu hükme başka bir lisansın üç yıllık yazılı teklif sistemi otomatik eklenemez. Kullanılan yükümlülük doğrudan MPL metninden okunmalıdır.

İndirme bağlantısının ilgili sürüme gitmesi gerekir. Ürünün yeni sürümündeki kaynak, daha önce dağıtılan sürümde şirketin yaptığı farklı değişiklikleri açıklamayabilir. Şirket her teslim paketini uygun kaynak kaydıyla eşleştirmelidir. Genel proje ana sayfası, kaynak deposunun ana dalı ve ürünün sürüme bağlı arşivi aynı belge değildir. Kaynağa ulaşan kullanıcı, aldığı ürünle bağlantıyı kurabilmelidir.

Kaynak edinme süreci gereksiz biçimde zorlaştırılmamalıdır. Mozilla’nın SSS açıklaması, özel bir zorunluluk olmadan fiziksel kurye gibi maliyet ve karmaşıklık ekleyen yöntemleri makullük şartıyla bağdaşır saymaz. Bu nedenle çevrim içi dağıtılan ürün için kaynağı yalnız pahalı fiziksel teslimle vermek ayrı değerlendirilir. Teknik erişim kolaylığı, hukuki metindeki makul ve zamanında edinme koşullarının uygulamasına hizmet eder.

Son kullanıcı sözleşmesi kaynak haklarını daraltabilir mi?

MPL m.3.2(b), çalıştırılabilir biçimin farklı koşullarla lisanslanmasına izin verir; ancak bu koşullar kaynak biçimi üzerindeki MPL haklarını sınırlandıramaz veya değiştiremez. Bir ürünün ticari son kullanıcı sözleşmesiyle sunulması, müşterinin MPL dosyaları üzerindeki lisans haklarının kaybolduğu anlamına gelmez. Ticari sözleşmenin kapsam dışı şirket koduyla kapsam içi kaynak arasındaki ayrımı koruması gerekir.

Müşterinin MPL kapsamındaki kaynağı değiştirmesini veya lisansın izin verdiği biçimde dağıtmasını yasaklayan genel hüküm, bu sınır açısından incelenir. Sözleşmenin sonunda üçüncü taraf lisanslarına ilişkin belirsiz bir atıf yapılması, bütün çelişkileri kendiliğinden çözmez. Hangi bileşende hangi şartın uygulanacağı okunabilir biçimde açıklanmalıdır. Ürün destek taahhüdü ile müşterinin kaynak üzerindeki izinleri de aynı kavram altında karıştırılmamalıdır.

Kaynak tesliminin şirketin ticari markasını kullanma veya resmî ortakmış gibi tanıtım yapma izni verdiği de söylenemez. MPL m.2.3 marka haklarını ayrı tutar. Programın kodunu kullanma izni, marka veya logonun reklamlarda serbestçe kullanılacağı anlamına gelmez. Ticari ürünün sunumunda izin verilen kod kullanımı ile menşe veya ortaklık iddiası birbirinden ayrılarak kontrol edilmelidir.

Küçültülmüş JavaScript kaynak kod sayılır mı?

MPL’de kaynak biçimi, değişiklik yapılması için tercih edilen biçimdir. Mozilla’nın resmî SSS açıklaması, küçültülmüş JavaScript dosyasını bu nedenle kaynak biçimi saymaz; çalıştırılabilir biçimde dağıtım koşullarını uygular. Dosya hâlâ metin olarak okunabiliyor diye otomatik olarak gerekli kaynak sunulmuş olmaz. Kodun geliştirme sırasında kullanılan değiştirilebilir biçimi ile dağıtım için sıkıştırılmış çıktısı ayrı değerlendirilir.

Tarayıcıya gönderilen paketler için bu ayrım doğrudan önemlidir. Sunucudaki uygulama işlevinin uzaktan kullanılması ile JavaScript kopyasının kullanıcının cihazına gönderilmesi aynı dağıtım olayı değildir. Şirket “ürünümüz yalnız web hizmeti” diyerek tarayıcıya ilettiği kapsam içi dosyaları inceleme dışı bırakamaz. İstemciye giden dosya listesi, lisans kontrolünün teknik dayanağına eklenmelidir.

Küçültme işlemiyle farklı kaynak dosyalarının tek dağıtım dosyasında birleşmesi de bütün özgün kaynakların MPL’ye dönüşmesi anlamına gelmez. Mozilla bu çıktıyı çalıştırılabilir biçim kapsamında ele alarak kaynak dosyalarının statüsünü ayrı değerlendirir. Buna karşılık küçültülmüş çıktı için gerekli kaynağın edinme yolu alıcıya bildirilmelidir. Hangi kaynakların birleşerek çıktıyı ürettiğini gösteren kayıt, lisans kapsamı tartışmasını somutlaştırır.

Kaynak bildirimlerinin korunması ve gerçek hata düzeltmesi

MPL m.3.4, kaynak içindeki lisans, telif, patent, garanti ve sorumluluk bildirimlerinin özünün kaldırılmasını veya değiştirilmesini yasaklar; bilinen maddi yanlışların giderilmesi için gerekli düzeltmeyi ayırır. Bu hüküm, şirketin kendi adını ekleyebilmesi için önceki hak sahiplerini silebileceği biçiminde okunamaz. Bir bildirimin düzeltilmesi gerekiyorsa gerçek yanlış ve düzeltmenin gerekçesi dosyada gösterilmelidir.

FSEK Ek m.4 de hak yönetimi bilgilerinin yetkisiz kaldırılması veya değiştirilmesini ayrı düzenler. Lisans bildiriminin ürün paketinde kaybolması, yalnız tasarım temizliği olarak ele alınmamalıdır. Kaynak dosyalarının başlıkları, lisans dosyası ve dağıtım belgeleri otomatik paketleme sürecinden sonra kontrol edilir. Geliştiricinin deposunda bildirim bulunması, müşteriye giden arşivde de korunduğunu tek başına kanıtlamaz.

MPL kapsamındaki kaynak dosyaları için bildirim yeri ve içeriği, dağıtım sırasında dosyanın tek başına el değiştirme ihtimali de gözetilerek seçilmelidir. Mozilla, bildirimin dosyaya bağlı olmasını ve uygun durumlarda beklenen başka bir konumda bulunmasını açıklar. Şirketin standart lisans dosyasını yanlış klasöre koyması, alıcının hangi dosyaya hangi lisansın uygulandığını anlamasını güçleştirir. Dosya listesinin bu belgeyle eşleştirilmesi gerekir.

Ücretli destek taahhüdü kimin borcudur?

MPL m.3.5, dağıtıcının ücret karşılığında garanti, destek veya belirli sorumluluk taahhütleri sunmasını ayrıca düzenler. Bu taahhütler dağıtıcının kendi adına verilmelidir; önceki katkı sağlayıcılar adına verilmiş gibi gösterilemez. Müşteri sözleşmesinde destek sunan şirket açık tanımlanmalı, açık kaynak projesinin bütün geliştiricilerinin aynı hizmeti üstlendiği izlenimi oluşturulmamalıdır. Kod kullanım izni ile belirli saatte müdahale veya hata giderme borcu ayrı ilişkilerdir.

Bu ayrım kaynak teslimi tartışmasına da yansır. Üründeki bir MPL dosyasını müşteriye sunmak, şirketin ücretli bakım taahhüdünü kendiliğinden sona erdirmez; hangi hizmetin üstlenildiği sözleşmeden belirlenir. Aynı şekilde müşteriyle geniş bir destek anlaşması yapılması da kaynak dosyalarının lisansını kapalı hâle getirmez. Teslim ve destek ekipleri, kaynağa erişim yükümlülüğü ile bakım işleminin kapsamını aynı belgede karıştırmadan açıklamalıdır. Ücretsiz lisans bildirimi, ticari sağlayıcının ayrıca üstlendiği borçları görünmez kılan bir genel muafiyet değildir.

MPL 1.1, MPL 2.0 ve başka lisansa geçiş ayrımı

Lisans incelemesi, sadece “MPL” sözcüğünü kaydetmekle tamamlanmaz. Üründe alınmış sürümün MPL 1.1, MPL 2.0 veya başka izinlerle birlikte sunulmuş olması farklı sonuçlar doğurur. MPL 2.0 m.3.3’te ikincil lisanslarla birleşim için özel koşullar vardır. Bu düzen, herhangi bir dosyanın istenildiği anda başka lisans adı yazılarak yeniden lisanslanması anlamına gelmez.

Dosyanın ikincil lisanslarla uyumsuz olduğuna ilişkin bildirimi ve önceki lisans geçmişi bu nedenle korunur. Satın alma veya birleşme sırasında yalnız güncel depo başlığına bakılması, daha önce alınan kodun gerçek şartlarını gözden kaçırır. Yeni ürün planında hangi dosyanın hangi sürümden geldiği belgelenmelidir. Ticari amaçla yeniden paketlemek, üçüncü kişinin dosyası üzerinde sınırsız yeniden lisanslama yetkisi vermez.

MPL uyuşmazlığında dosya, delil ve talep

  • Kaynak geçmişi: İlk alınan dosyalar, lisans bildirimleri, değişiklik kaydı ve yeni dosyalara taşınan kod birlikte saklanır. Yalnız son sürüm, değişikliğin hangi materyale dayandığını açıklamayabilir.
  • Ürün eşleştirmesi: Dağıtılan uygulama sürümü, derleme kaydı, kapsam içi dosya listesi ve sunulan kaynak arşivi aynı teslim kaydına bağlanır. Farklı sürümlerin belgeleri birbirine karıştırılmaz.
  • Alıcıya bilgi: Kaynak edinme açıklaması, bağlantı, lisans metni ve son kullanıcı koşulları dağıtıldığı biçimde korunur. Sonradan düzeltilmiş internet sayfası önceki dağıtımın durumunu tek başına göstermez.
  • İnceleme sonucu: Hangi dosyanın MPL kapsamında olduğu, hangi bildirimin eksik bulunduğu ve hangi erişim koşulunun sağlanmadığı ayrı ayrı yazılır. Genel “açık kaynak ihlali” ifadesi somutlaştırılır.

Hak sahibinin önleme talebi ile tazminat veya sözleşme talebi farklı hukuki koşullara dayanır. FSEK m.69 bakımından telif hakkı ihlalinin önlenmesi rehberi genel yolu açıklar. Somut MPL dosyasında ise önce korunan kod, hak sahipliği ve lisans dışına çıkan fiil gösterilmelidir. Her kaynak eksikliğinin otomatik aynı parasal sonuca bağlandığı söylenemez.

Kaynağın sonradan erişilebilir yapılması gerekiyorsa düzeltme yalnız en güncel pakete ekleme yapılarak tamamlanmış sayılmamalıdır. Etkilenen sürümler, alıcıya verilen bilgi ve devam eden dağıtım birlikte kontrol edilir. MPL’nin sona erme ve yeniden yürürlük düzeni m.5.1’de ayrıca yer alır. Kaynak linkini düzeltmek, geçmiş uyuşmazlıkların bütününü kendiliğinden sona erdiren bir sulh işlemi değildir; yapılan düzeltmenin kapsamı açık kaydedilir.

MPL 2.0 ve kapalı kaynak ürünler hakkında sık sorulan sorular

MPL 2.0 kod ticari kapalı kaynak üründe kullanılabilir mi?

Evet. MPL m.3.3 daha büyük ürünün farklı şartlarla dağıtılmasına izin verir. Kapsam içindeki kaynak dosyaları ve değişiklikleri için MPL koşulları korunmalıdır. Ürünün kapalı kaynak olması bu dosyaların yükümlülüğünü ortadan kaldırmaz.

MPL dosyasına eklediğim kendi kodum kapsam dışında mı kalır?

MPL m.1.10, kapsam içi kaynak dosyasına ekleme, çıkarma veya değişiklik yapılmasıyla oluşan dosyayı değişiklik olarak tanımlar. Şirketin eklemeyi kendisinin yazması, dosyanın MPL koşulunu tek başına kaldırmaz.

Kodu yeni dosyaya taşımak MPL yükümlülüğünü kaldırır mı?

Hayır. Kapsam içindeki kodu barındıran yeni kaynak dosyası da değişiklik tanımına girer. Sadece dosya adının veya klasörün değiştirilmesi lisans bağını kesmez. Yeni dosyanın gerçek içeriği ve kod geçmişi incelenir.

MPL içermeyen bağımsız dosyaları açmak zorunda mıyım?

MPL kodu içermeyen yeni ve ayrı kaynak dosyaları, daha büyük ürüne katıldıkları için otomatik olarak MPL kapsamında olmaz. Kapsam içi dosyalarla bağımsız dosyaların içerik ve lisans bakımından doğru ayrılması gerekir.

Tek çalıştırılabilir dosya bütün kaynakları MPL yapar mı?

Hayır. Mozilla’nın açıklaması statik bağlamayla daha büyük kapalı ürün oluşturulmasını da kabul eder. Çalıştırılabilir çıktı sayısı kaynak kapsamını tek başına belirlemez. Kapsam içi dosyalar için kaynak erişimi ve diğer koşullar sürer.

MPL kaynak sunumu için sabit üç yıllık teklif yeterli mi?

MPL m.3.2(a), makul yöntemle ve zamanında kaynak edinilmesini düzenler. Başka lisansın üç yıllık yazılı teklif mekanizması MPL’ye otomatik uygulanmaz. Dağıtım koşulu kendi lisans metnine göre kurulmalıdır.

Kaynak kod için istediğim bedeli belirleyebilir miyim?

MPL m.3.2(a), kaynak ediniminde alıcıya dağıtım maliyetini aşmayan bedel sınırını düzenler. Kaynağı edinmeyi bağımsız yüksek lisans ücreti veya gereksiz masraf şartına bağlamak bu hükümle birlikte incelenir.

Küçültülmüş JavaScript kaynak kod olarak yeterli mi?

Mozilla’nın resmî açıklamasına göre küçültülmüş JavaScript değişiklik için tercih edilen biçim olmadığından çalıştırılabilir biçim kapsamında değerlendirilir. İlgili MPL kaynaklarına nasıl ulaşılacağı alıcıya ayrıca bildirilmelidir.

Ticari EULA müşterinin MPL kaynak haklarını kaldırabilir mi?

MPL m.3.2(b), çalıştırılabilir biçimin farklı koşullarla sunulmasına izin verirken kaynak üzerindeki MPL haklarının sınırlandırılmasını veya değiştirilmesini kabul etmez. Ticari sözleşme bu kaynak haklarını koruyan ayrımı içermelidir.

MPL lisanslı dosyadaki önceki telif bildirimi silinebilir mi?

MPL m.3.4 kaynak içindeki bildirimlerin özünü korur; bilinen maddi yanlışların gerekli ölçüde düzeltilmesini ayrı tutar. Şirketin kendi adını eklemek istemesi, önceki hak sahibi bildirimini silmek için genel izin değildir.

Birincil MPL metni ve kanun kaynakları

İstanbul ve Mersin ofisleri

İstanbul · Polaris Plaza

Maslak Ahi Evran Caddesi, Polaris Plaza No:21, Kat:9, 34475 Sarıyer/İstanbul

İstanbul ofisi ve randevu

Mersin · Profit İş Merkezi

İhsaniye Mahallesi, 4903. Sokak, Profit İş Merkezi No:23, Kat:3, Daire:14, 33070 Akdeniz/Mersin

Mersin ofisi ve randevu

Hukuki konu hakkında iletişim

İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.

Telefonla Araİletişim Bilgileri

tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Telefon WhatsApp