GPL'de tescilli yazılımın GPL kütüphanelerine bağlanmasına izin veren bir boşluk var mı?


15

Varsayımsal bir senaryoyu inceleyelim:

X Şirketi, özel bir kütüphaneye (B) dinamik olarak bağlanan özel bir program (A) yazar. Y Şirketi, GPL kapsamında lisanslanmış bir yedek kitaplık (C) kullanmak istiyor ve bu nedenle hem A hem de C'ye dinamik olarak bağlanan ve A tarafından kullanılan API çağrılarını C tarafından kullanılan API çağrılarına çeviren bir sarıcı kitaplığı (D) yazıyor.

D'nin C ile kullanılması amaçlandığı ve C'nin API çağrılarını kullandığı için C'nin türevsel bir çalışmasıdır ve bu nedenle GPL * koşulları altında dağıtılmalıdır. Sonuç olarak, A ve D'nin birleşik çalışması da GPL şartları altında dağıtılmalıdır; bu, Y Şirketinin A için kaynak koduna sahip olmadığı göz önüne alındığında imkansızdır. , sorun yok. Bununla birlikte, Y şirketinin eylemlerinden bağımsız olarak, X Şirketi, B olmadan bile A'yı dağıtarak GPL'yi ihlal etmez. D'nin sadece varlığı, A'nın aniden C'nin (D) aracılığıyla lisanslanması gereken bir türev işi olduğu anlamına gelmez. GPL de.

Şimdi bu boşluk: Şirket X'in kendi D sürümünü yazmasını, A'dan ayrı olarak dağıtmasını ve son kullanıcılara A'yı çalıştırırken D yerine D'yi kullanmalarını söyleyen hiçbir şey yok . özel programı GPL kitaplığından yalıtmak için bir sarmalayıcı modülü kullanıldığı ve bu modül ayrı olarak dağıtıldığı sürece, GPL'yi ihlal etmeden bir GPL kitaplığını kullanmak için özel bir program tasarlama.

Akıl yürütmemde doğru muyum? Bu GPL'de gerçek bir boşluk mu?

* D aynı zamanda A'nın türevsel bir çalışmasıdır, ancak bu senaryonun amaçları doğrultusunda X Şirketi D'nin oluşturulmasına açıkça izin vermiştir ve GPL kapsamında lisanslanmasına izin vermiştir.


1
Kısa cevap: hayır.
whatsisname

2
Ben bir avukattan başka biriyim, ama benim kütüphanemle dinamik olarak bağlantı kurmanın kodunuzu türetilmiş bir çalışma haline getirmediğini düşünüyorum. Aksi takdirde, bir GPL lisansı kapsamında olabilecek bir şeyle dinamik olarak bağlantı kuran bir BSD lisansı altında herhangi bir şeyin dağıtılması imkansızdır. Statik bağlantı farklı bir hikaye ve tabii ki dinamik olarak bağlantılı kütüphanenin kendisini GPL'den başka bir şey altında yeniden dağıtamazsınız.
tdammers

4
@tdammers: AFAIK'ın dinamik olarak bağlanması , kodu türetilmiş bir çalışma haline getirir ve haklısınız , muhtemelen GPL kütüphanelerini kullandığında BSD lisansı altında yazılım dağıtmak mümkün değildir. Bu nedenle birçok açık kaynak kütüphane yazarı, kütüphanelerini GPL yerine LGPL altında sunuyor.
Doc Brown

2
@tdammers: Bu senaryonun amaçları doğrultusunda Stallman'ın bağlantı kurma yaklaşımını kullanıyorum: hem dinamik hem de statik bağlantı GPL'yi ihlal ediyor.
Michael Kourlas

3
@mouviciel Birlikte çalışabilirlik amacıyla bir API'nın kopyalanmasının yasal olduğunu belirten mahkeme kararları alınmıştır. Bunun hem ABD hem de AB'deki üst düzey mahkemeler tarafından bağımsız olarak bulunduğuna inanıyorum , bu nedenle yasal statü oldukça sağlamdır (birisi yasayı aktif olarak değiştirmedikçe).
Donal Fellows

Yanıtlar:


10

IANAL, ancak işte GPL sınırları içinde nelere izin verildiğine dair fikrim:

  • "A - B" kombine çalışmasını kamuya dağıtmak: para cezası, herhangi bir tescilli lisans altında yapılabilir

  • Y için C için bir sarıcı lib D oluşturun: ince, bu A'nın GPL altına konması gerektiği anlamına gelmez

  • "A - D - C" kombine ürününü dahili olarak Y ile kullanın: ayrıca iyi, GPL kombinasyonu halka dağıtılmadığı sürece A kaynağını açmaya gerek duymaz

  • "A - D - C" kombine çalışmasını kamuya açıklamak: bu A'nın açık kaynaklı olmasını ve GPL altına konmasını gerektirecektir (ve X veya Y'nin bu kombinasyonu dağıtması önemli değildir; ayrıca Y yapmak istiyorsa tabii ki X'ten A için bir dağıtım lisansı gerektireceklerdir)

İlginç soru şu: D & C, GPL altında açık kaynak olarak ayrı ayrı dağıtılabilir, A&B (veya sadece B olmadan A) tescilli bir lisans altında dağıtılabilir ve son kullanıcı B tarafından D & C'nin yerini kendisi alabilir mi?

Burada A'yı Lbs D & C'ye bağımlı kılan "AB" ye son değişiklik, dağıtımdan sonra son kullanıcı tarafından yapılır. . Dolayısıyla, son değişikliğin sadece dahili olarak son kullanıcı tarafından yapıldığı söylenebilir. Ve bu gerçekten de GPL'yi ihlal etmeden mümkün görünüyor - ve elde ettiğiniz şey, A'nın tescilli lisans altında olduğu ve AC'nin GPL altında olduğu C & D'nin çalışan bir kombinasyonudur.

Elbette, bir avukat veya yargıç bununla ilgili farklı görüşlere sahip olabilir. Son bir cevap almak için, sanırım birisi denemeden ve ikincisi onu dava edene kadar beklemelisin.

Sanırım çoğu sistem için, başlangıçta bir şekilde "A" tasarlamadan böyle bir takımyıldız oluşturmak zor olacak, böylece B veya C ile sorunsuz bir şekilde çalışacak ve bu durumda, A bir şekilde C'den türetilmiştir.

EDIT: bir süre düşünerek, benzer bir durum aklıma geldi: kapalı kaynak uygulamaları için GPL lisanslı eklentileri yazma ve dağıtma. Örneğin Photoshop'u ele alalım. Üçüncü taraf satıcılardan bazı GPL eklentileri olduğu için birisinin Adobe'yi açık kaynaklı Photoshop'a zorlamaya çalışacağını düşünmüyorum. Burada, iyi tanımlanmış bir arayüz olduğundan bir "sarıcı lib" bile gerekli değildir. Bununla birlikte, Photoshop'un bazı merkezi işlevlerini bir GPL üçüncü taraf eklentisinden dahil ederse durumu değiştirir mi? Böyle bir durumda, nerede çizgi çizileceğine karar vermek gerçekten zor olabilir, bu noktada kapalı kaynaklı ürün GPL lib'ini "temel alan" bir çalışmadır.

EDIT2: Ticari olmayan kullanım için GPL lisansı ve bunun gibi ticari kullanım için tescilli lisans ile çift lisanslı kütüphaneler mevcuttur.. Yani "boşluk", böyle bir lib'e dayalı bir ürün geliştirmek anlamına gelir (ticari sürümü kullanarak, GPL ürününüz için geçerli değildir), ürününüzü herkese açık lib olmadan kapalı kaynak olarak teslim edin ve kullanıcı GPLed sürümünü kendi başına alır ve kurar. Böyle bir durumda, sanırım lib satıcısı, lisans ihlali için sizi başarılı bir şekilde dava etme şansına sahip olacaktır (eğer lib için ödeme yapmazsanız, elbette). Zorluğa değer mi? Muhtemelen değil. Özellikle bağlantılı olduğum örnekte, fiyatı da ürününüzü ne sıklıkta sattığınıza bağlı değil, yalnızca geliştirme sırasında lib'i kaç geliştirici kullandığına bağlı olduğu için lib'i de satın almanız gerekir.

Son olarak, bu yasal riskler nedeniyle, kapalı kaynaklı bir üründe açık kaynaklı kütüphaneler kullanmayı planlıyorsam, mümkünse GPL kütüphanelerinden kaçınırdım ve bu "boşluk" dan yararlanmaya çalışmam. Bağlantı istisnası olan LGPL veya GPL çok daha güvenli veya herhangi bir viral olmayan OS lisansıdır.


2
Bağırsak hissi, yapan şirketin combo Areklamını yapmaya başlaması durumunda avukatların daha sert bir şekilde dürtülmeye başlayacağını söylüyor A - C&D.
Bart van Ingen Schenau

1
@BartvanIngenSchenau: Kabul ediyorum. Ama farklı bir senaryo hayal edebiliyorum: X AB'yi dağıtıyor ve Y sadece bir "eklenti" C&D'yi AB'nin kurulum klasöründeki B'nin yerini alan bir yükleyici ile dağıtıyor (ve reklamını yapıyor)?
Doc Brown

Bunun da alternatif senaryo hayal edebilir ve avukatlar eğer bir delik koymak için çok daha zor olacak Ave C&Dfarklı tüzel kişilere gelir.
Bart van Ingen Schenau

1
@DocBrown: Eşdeğer bir tescilli B kütüphanesinin varlığı bile önemli mi? X şirketi, son kullanıcının onu kullanmak için bir çalışma kütüphanesi bulması ve sonra "uygun şekilde" onlara D sağlaması gerektiği varsayımı altında A'yı tek başına satamaz mı?
Michael Kourlas

1
@MichaelKourlas: lib B'nin varlığı, C tedarikçisinin X'i dava etmesini çok daha zorlaştıracaktır, çünkü X'in A'nın C'nin "türetilmiş bir işi" olmadığını kanıtlamasını kolaylaştırır
Doc Brown

3

Pratik bir örnek, Linux için son kullanıcının kendi kurması gereken özel grafik sürücüleri. En önemlisi, tescilli sürücünün yaratıcısı için, eğer son kullanıcı birleştirilmiş işi dağıtırsa, bu son kullanıcı için (muhtemelen yerine getiremeyecekleri) yasal bir yükümlülük yaratır, ancak sürücünün yaratıcısını yaratmaz.

Başka bir cevap, "program kütüphaneye bağlı olduğu için hala türevsel bir çalışma olduğu" iddiasındadır - ancak kütüphane orada olmadığı için program gerçekten çalışmazsa, türev değildir.

Ama sonuçta, eğer "boşluklara" güveniyorsanız, yaklaşımınızın ilk etapta doğru olmayabileceğini düşünmelisiniz.


Son kullanıcının GPL bileşenini kurması gerekip gerekmediği önemsizdir. GPL sarmalayıcıları içeren tescilli çekirdek modülleri genellikle GPL bileşenini yalnızca kaynak kodu biçiminde dağıtır ve kullanıcının bunları derlemesini gerektirir. DKMS bunu otomatik hale getirir. Bu, farklı bir GPL "boşluk deliğinden" yararlanır; bu, nesne kodu biçiminde yeniden dağıtmadığınız sürece, bir GPL programının yerel bir kopyasıyla istediğiniz her şeyi yapabilirsiniz. Son kullanıcılar tipik olarak Linux çekirdeğini özel çekirdek modülleri ve derlenmiş GPL paketleyicileri ile yeniden dağıtmadığından, genellikle güvenlidirler.
Clement Cherlin

1

Bağlama, GPL tarafından bir türevi tanımlar. Bu özel durum, LGPL'nin işlemek için tasarlandığı şeydir: kütüphaneyi GPL olarak serbest bırakmak, ancak bağlantıyı uygulanan lisansın açık sınırı olarak tanımlamak veya alternatif olarak, bazı GPL kodlarına bağlamak istediğiniz ancak kendi GPL olmayan bir lisans altında serbest bırakılabilir.

Son kullanıcı, son kullanıcı olan (GPL kütüphaneye karşı bağlayabilir GPL olmayan kaynaklardan kendi kodunu oluşturmak) bağlama yapacak durumda değil etkin bir nihai ürün ne olursa olsun bir GPL sürüm yarattı çünkü projenin GPL olmayan kısmının lisansını değiştirmesine izin verilmediği için projenin sahibi değil. Bu genellikle son kullanıcı tarafından herhangi bir biçimde dağıtılmasını engeller, ancak kullanımı yasaklamaz.

Bununla birlikte, eğer bir proje kaynaktan inşa edilmesini gerektiriyorsa ve sadece bu şekilde dağıtılırsa, bu tamamen GPL olmayan geliştiricinin elinden çıktığı için, bağlı kütüphanenin hangi lisans altında olduğu önemsizdir. Yani, kendi lisanslama şartlarınız altında belirtmedikçe, yalnızca kaynak dağıtımınızın gcc üzerinde bir IBM derleyicisine dayanan glibc VS'ye karşı libc'ye karşı oluşturulacağını nasıl bilebilirsiniz? Bu hızlı bir şekilde adil kullanım ve uygulanamaz yasal koşullara karşı yasaklar ile karşı karşıya kalmaktadır (son zamanlarda birkaç kez fantezinin yasaya yazılmadığı).


0

Ben bir avukat değilim, ama söyleyebildiğim kadarıyla doğru değil, çünkü program kütüphaneye bağlı - bu hala bir türev çalışma. Bir sekansın türev bir çalışma olduğu gibi. En azından kütüphanede tanımlanan API'lara dayanır.


API sorunu, telif hakkına sahip olduğunuz bir sarmalayıcı modülü eklenerek giderilemedi mi? ( bahsettiğim şeyin bir örneği için bkz. windyroad.com.au/2006/04/20/… )
Michael Kourlas

Sarıcı bileşen eklemek için soruyu güncelledim.
Michael Kourlas

@ user92103 Bu SSS sorunuzu ele alıyor mu? gnu.org/licenses/gpl-faq.html Veya bu P.SE sorusu: programmers.stackexchange.com/questions/50118/…
apsillers

1
@apsillers: P.SE sorusu bir ağ üzerinden istemci-sunucu iletişimi ile ilgilidir. Bu kesinlikle GPL'yi atlatmanın olası bir yolu olsa da, burada bahsettiğim şey (dinamik bağlantı). GPL SSS'ye baktım ve bir sarmalayıcı modülü ile ilgili bir soruları var, ancak bu soru dağıtıcının dağıtım noktasında tescilli uygulama ile GPL kütüphanesini paketlediğini varsayar. Bu durumda, son kullanıcı işleri önemli ölçüde değiştiren paketlemeyi yapıyor.
Michael Kourlas
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.