Sistem PatentSistem Patent
Menü
FİKRİ HAKLAR

Açık Kaynak Lisansları ve Kendi Fikri Mülkiyetiniz: MIT, GPL ve Apache Kodu Sahipliğinizi Nasıl Etkiler?

MIT, Apache ve GPL kodu yazılımınızın sahipliğini nasıl etkiler? Copyleft tuzağı, atıf ödevleri ve yatırım öncesi bağımlılık ağacını denetlemenin önemi.

Sistem Patent·6 dk okuma
Paylaş:
İçindekiler
  1. 1İzin veren lisans atıf ister; copyleft lisans kodunuzu ister
  2. 2Lisans izin verse bile atıf isteğe bağlı değildir
  3. 3Yığınınızın yasal olarak bir arada durup duramayacağına lisans uyumluluğu karar verir
  4. 4Bağımlılık ağacını para masaya gelmeden önce denetleyin, sonra değil
İzin veren MIT ve Apache dalları yeşil, GPL copyleft dalı kırmızıyla işaretlenmiş bir yazılım bağımlılık ağacı; bir açık kaynak lisansının ürün şirketinin kendi koduna nasıl uzandığını gösteriyor

Bir alıcının avukatları bir klasör açar, satın almak üzere oldukları kod tabanında bir tarama çalıştırır ve bağımlılık ağacının dört kat derininde gömülü, GPL lisanslı tek bir kütüphane bulur. Ürün onun üzerine inşa edilmiştir. Kurucu ekipten kimse onu eklediğini hatırlamaz; başka bir paketi çeken bir paketin dolaylı bağımlılığı olarak gelmiştir. Anlaşma çökmez ama duraklar, fiyat değişir ve kurucular sonraki üç haftayı bu tek bileşenin sattıkları şeyi zehirlemediğini ispatlamakla geçirir. Açık kaynak lisanslamanın bir kolaylıktan bir yükümlülüğe sessizce dönüştüğü yer tam burasıdır.

Açık kaynak kod, neredeyse her modern yazılım ürününün temelidir ve onu kullanmak bir sorun değildir. Sorun, her lisansın karşılığında sizden ne istediğini bilmeden onu kullanmaktır. Lisans bir sözleşmedir. Bir kütüphaneyi ürününüze dahil ettiğinizde onun koşullarını kabul edersiniz ve bu koşulların bir kısmı, kendi yazdığınız koda kadar uzanır. Bir ürün satmayı, onun üzerinden yatırım almayı ya da onu müşterilere lisanslamayı düşünen bir şirket için soru, açık kaynak kullanıp kullanmadığınız değildir. Ona bağlı lisansların, inşa ettiğiniz şeye sahip olup onu ticarileştirmekle bağdaşıp bağdaşmadığıdır.

İzin veren lisans atıf ister; copyleft lisans kodunuzu ister

Bir ürün şirketinin en sık karşılaştığı lisanslar iki kampa ayrılır ve aralarındaki fark, ne kadar özgürlüğü koruyacağınızı belirler. İzin veren (permissive) lisanslar, başta MIT Lisansı ve Apache Lisansı 2.0, kodu almanıza, değiştirmenize, kapalı bir ürüne katmanıza ve kendi kaynağınızı yayımlamadan o ürünü satmanıza izin verir. Karşılığında istedikleri hafiftir: telif bildirimini koruyun, lisans metnini ürünle birlikte taşıyın ve Apache söz konusu olduğunda onun patent ve atıf koşullarına uyun. İzin veren lisanslı kod üzerine mülkiyeti size ait, kapalı bir iş kurabilir ve yine de kendi eserinize sahip olup onu kapalı tutabilirsiniz. Ticari yazılımların çoğunun MIT ve Apache temeli üzerinde oturmasının nedeni budur.

Copyleft lisanslar farklı bir ilke üzerinde çalışır. GNU Genel Kamu Lisansı, yani GPL, yazılımı hukuki anlamda özgür tutmak için kurulmuştur ve bunu bir koşul ekleyerek yapar: GPL koduna dayalı bir eseri dağıtırsanız, o eserin kaynağını da GPL altında yayımlamak zorundasınız. Lisans yayılmak üzere tasarlanmıştır. Bir GPL bileşeni alıp ürününüze yerleştirin, o ürünü müşterilere gönderin ve yükümlülük kendi kaynağınıza kadar uzanabilir. İnsanlar bir lisansın "bulaşıcı" olduğundan söz ederken kastettikleri mekanizma budur. Bu bir hata ya da saldırgan bir yorum değildir. Lisansın tam da yazıldığı gibi işlemesidir ve geç keşfedilmesi en pahalıya patlayan tek şeydir.

Çoğu ekip GPL'i dağıtım tetikleyicisinde yanlış okur

GPL'in kaynak yayımlama yükümlülüğü genellikle dağıtıma, yani yazılımı bir başkasına ulaştırmaya bağlıdır. GPL kodunu yalnızca kendi sunucularında barındırılan bir hizmeti çalıştırmak için kullanan bir ekip, olağan GPL kapsamında ikili dosyayı kullanıcılara hiç dağıtmıyordur ve kaynak yayımlama ödevi aynı şekilde devreye girmez. Pek çok şirketin, hizmet olarak yazılımın kendilerini copyleft'ten tümüyle kurtardığını varsaymasının nedeni tam olarak budur. Affero GPL, yani AGPL, bu boşluğu kapatmak için yazılmıştır: yükümlülüğü bir ağ üzerinden kullanıcılara sunulan yazılıma genişletir, böylece değiştirilmiş AGPL kodunu bir web hizmetinin arkasında çalıştırmak, onu göndermekle aynı kaynak yayımlama ödevini tetikleyebilir. Pratik ders şudur: "biz onu yalnızca arka uçta kullanıyoruz" cümlesi, gerçekte hangi copyleft lisansının devrede olduğunu ve ürününüzün kullanıcılarına nasıl ulaştığını biri kontrol edene kadar güvenli bir yanıt değildir.

Lisans izin verse bile atıf isteğe bağlı değildir

İzin veren lisansları hiçbir şartı yokmuş gibi görmek caziptir ama şartları vardır ve onları görmezden gelmek başlı başına bir ihlaldir. MIT Lisansı, telif ve izin bildiriminin kodla birlikte taşınmasını ister. Apache 2.0 daha ileri gider: bildirimleri korumanızı, yaptığınız önemli değişiklikleri belirtmenizi ve NOTICE dosyasını aktarmanızı ister. Bunları söküp atan bir ürün, altta yatan lisans cömert olsa bile uyumlu değildir. Buradaki risk nadiren bir davadır. Denetimdir. Bir yatırımcı ya da alıcı lisans taraması yaptığında, eksik atıflar en iyi ihtimalle özensizlik, en kötü ihtimalle yönetilmeyen bir hukuki risk olarak okunur ve her iki okuma da bir anlaşmayı yavaşlatıp masadaki konumunuzu zayıflatır.

Yığınınızın yasal olarak bir arada durup duramayacağına lisans uyumluluğu karar verir

Asıl zor mesele tek bir lisans değil, birkaçının tek bir kod tabanı içinde nasıl etkileşime girdiğidir. Aynı dağıtılan üründe yaşamak için lisansların birbiriyle uyumlu olması gerekir. İzin veren lisanslar neredeyse her şeyle, birbirleriyle ve kapalı kaynak kodla temiz biçimde birleşir. Copyleft lisanslar daha seçicidir. GPL kodunu alıp GPL ile çelişen koşullar altında yeniden lisanslayamazsınız; bu da bazı kombinasyonların birlikte gönderilmesine basitçe izin verilmediği anlamına gelir. Güçlü bir copyleft bileşeni, GPL'in alt zincir koşullarını yasaklayan bir lisansla karıştıran bir ekip, taraflardan birini söküp atmadan hiç dağıtamayacağı bir şey kurmuş olabilir. Uyumluluk, lansman sonrası halledilecek bir ayrıntı değildir. Ürününüzün yasal olarak ne olabileceğini biçimlendirir.

Açık Kaynak Lisansları ve Kendi Fikri Mülkiyetiniz: MIT, GPL ve Apache Kodu Sahipliğinizi Nasıl Etkiler? gorseli

Bunu yanlış yapmanın maliyeti, ne kadar geç fark ettiğinizle birlikte büyür. Erken geliştirme aşamasında sorunlu bir bağımlılığı değiştirmek bir öğleden sonralık iştir. Bir ürün gönderildikten sonra, sorunlu kütüphane mimariye işlenmiş ve ona dayanan bir müşteri kitlesi varken, aynı değişiklik yapısal bir yeniden yazıma dönüşür. Ve en kötü zamanlamada, bir yatırım turu ya da bir satın alma incelemesi sırasında, beklenmedik bir GPL bağımlılığı ya da kopuk bir atıf zinciri alıcının kozu haline gelir. Çoğu durumda bunun yüzünden masadan kalkmazlar. Onu, fiyatı düşürmek ya da kendi koşullarıyla, saat işlerken sizden sorunu gidermenizi istemek için kullanırlar.

Bağımlılık ağacını para masaya gelmeden önce denetleyin, sonra değil

Savunma gösterişsiz ama tümüyle etkilidir: başkası bakmadan önce kodunuzda ne olduğunu bilin. Bağımlılık ağacı yalnızca geliştiricilerinizin bilerek seçtiği kütüphaneler değildir. O kütüphanelerin çektiği her paket ve onların çektiği her pakettir; sürprizlerin saklandığı dolaylı katmanlara kadar iner. Bir açık kaynak uyum denetimi bu ağacın tamamını dolaşır, her bileşendeki lisansı listeler ve copyleft ile uyumsuz girdileri, henüz ucuza giderilebilecekken işaretler. Çıktı bir yazılım malzeme listesidir (software bill of materials), neyi hangi koşullarla gönderdiğinizin yalın bir envanteridir ve ciddi bir yatırımcının isteyeceği belge budur.

Bu alışkanlığı erken edinmek ekonomiyi değiştirir. Lisanslarını ilk commit'ten itibaren takip eden bir şirket, sorunlu bir bağımlılığı sıradan bir değişiklik olarak ele alır. İlk kez bir niyet mektubundan bir hafta önce denetim yapan ise geriden gelerek pazarlık eder. Bir finansman turunda sizi koruyan disiplin, fikri mülkiyetinizin geri kalanını da korur: yazdığınız mülkiyeti size ait kodu, ticari sır olarak tuttuğunuz algoritmaları ve bir gün savunmanız gerekebilecek daha geniş eser bütününü. Temiz bir lisans konumu, sahip olduğunuzu iddia ettiğiniz şeye gerçekten sahip olduğunuzu güvenle söyleyebilmenin bir parçasıdır.

Açık kaynak uyumu, daha büyük bir fikri mülkiyet tablosunun içinde yer alır ve ona bu gözle bakmak işe yarar. Bu kütüphanelerin üzerine kurduğunuz kod, onu yazdığınız anda zaten telif hakkıyla korunur ve tarihli bir yazılım tescili oluşturmak, o özgün esere, içerdiği üçüncü taraf lisanslardan ayrı, kayıtlı bir sahip kazandırır. İki mesele birbirinden ayrıdır: lisans uyumu ödünç aldığınız kodu yönetir, tescil ise sizin yazdığınız kodu belgeler. Bir alıcıya ya da bir uyuşmazlıkta ürününüzün gerçekten satmaya yetkili olduğunuz bir şey olduğunu kanıtlamanız gerektiğinde her ikisi de önemlidir.

Lisanslama mülkiyetle kesiştiğinde analiz bir geliştirici işi olmaktan çıkıp hukuki bir işe dönüşür. Belirli bir copyleft koşulunun kodunuza uzanıp uzanmadığını, yığınınızdaki iki lisansın bir arada durup duramayacağını ya da bir yüklenicinin katkısının gizli bir açık kaynak yükümlülüğüyle gelip gelmediğini okumak, bir mühendislik tercihi değil, bir fikri haklar hukuku sorusudur. Bir uyuşmazlık geldiğinde de durum aynıdır: bir gün bir fikri haklara tecavüz davası ile karşılaşırsanız, bağımlılık ağacınızdaki lisanslar karşı tarafın ilk yoklayacağı şeyler arasında olur. Ödünç alınan kodun yanında kurduğunuz, mülkiyeti size ait varlıklar da, savunmaya değer özgün modüller ve yaratıcı malzemeler de, kendi tarihli eser kayıt tescilini hak eder; böylece eser sahipliğiniz, biri sizden kanıt istemeden önce belgelenmiş olur.

MIT, Apache ya da GPL kodu kullanmak başlı başına bir risk değildir. Onu görmeden kullanmak risktir. Zarar görenler açık kaynağı seçenler değildir; karşılığında neyi kabul ettiklerini hiç kontrol etmeyenlerdir. Bir finansman turuna, bir satın almaya ya da bir müşteri lisans anlaşmasına doğru gidiyorsanız, atılacak pratik adım, bağımlılık ağacınızı şimdi, bir sorun hâlâ hızlı bir düzeltmeyken denetlemektir; bir fiyat indirimine dönüşmeden. Sistem Patent, açık kaynak yükümlülüklerinin kendi fikri mülkiyetinizle nerede buluştuğunu haritalandırmanıza yardımcı olabilir; böylece satmayı düşündüğünüz şey gerçekten, kanıtlanabilir biçimde sizin olur.