GPL hedeflerine ulaşmada ne kadar başarılı? [kapalı]


16

Kodun ticari kullanımı ile ilgili olarak genel olarak iki tür FOSS lisansı vardır - diyelim ki GPL türü ve BSD türü. Birincisi, lisans altında kodun ticari kullanımı (kullanımla da modifikasyon ve yeniden dağıtım, ayrıca türetilmiş eserler oluşturma, vb.) Hakkında kısıtlayıcıdır ve ikincisi çok daha izin vericidir.

Anladığım kadarıyla, GPL tipi lisansların arkasındaki fikir insanları tescilli yazılım modelinden vazgeçmeye teşvik etmek ve bunun yerine FOSS koduna dönüştürmektir ve lisans onları buna ikna etmek için bir araçtır - yani "bu güzel yazılımı kullanabilirsiniz , ancak yalnızca kampımıza gelip kurallarımızla oynamayı kabul ederseniz ".

Sormak istediğim şu - bu strateji şimdiye kadar başarılı mıydı? Yani, GPL nedeniyle kapalıdan açığa giden büyük bir proje ya da sadece GPL bunu yaptığı için açıkta geliştirilen bazı yazılımlar şeklinde büyük başarılar var mı? Bu stratejinin etkisi, örneğin herkesin BSD tipi lisanslara sahip olacağı veya herkese açık alan altındaki tüm açık kaynak kodlarını yayınlayacağı dünyayla karşılaştırıldığında ne kadar büyük?

FOSS modelinin başarılı olup olmadığını sormadığımı unutmayın - bu soruların ötesinde. Sorduğum şey, insanları GPL-tipi tarafından kullanılan ve BSD-tipi lisanslar tarafından kullanılmayan FOSS'a özel olarak dönüştürmenin cazip bir yolunun başarılı olup olmadığıdır. Aynı zamanda lisans olarak GPL'nin kendisinin yararlarını da sormuyorum - sadece etkinliği hakkında.


4
GPL kullanım konusunda herhangi bir kısıtlama getirmez. Sadece kısıtlamalar yaptığı dağıtımdır .
whatsisname

1
Kontrast ticari değil, özel yazılımla olmalıdır. Çok sayıda ticaret özgür yazılımla devam ediyor.
Lars Wirzenius

2
Timsı ʇ u ɹǝƃ uo ɹǝƃuıɟ ʎɯ ʇ ve ǝʇınb ʇ, uɐɔ ı ʇnq 'uǝʇʇıɹʍ sɐʍ ן dƃ ǝɥʇ uǝɥʍ ɯoɹɟ ʇuǝɹǝɟɟıp sɯǝǝs p ןɹ oʍ ǝɥʇ ʇnoqɐ ƃuıɥʇǝɯos
Tim Post

Yanıtlar:


10

İlk olarak, sorunun özünde bir öznellik vardır - kesin olarak bilmenin bir yolu yoktur ve tarih her iki şekilde de yorumlanabilir. Bu eski bir tartışma ve açık kaynak kodlu yazılımın özgür yazılımla karşılaştırılmasındaki temel sorunlardan biri. Hedeflerine ulaşarak ne demek istediğinizi de tanımlamanız gerekir. GPL ve FSF'nin açık kaynağı son 2-3 yılda önemli bir hareket haline getirmeye katkıda bulunmadığını iddia etmek zor. Yine de, tüm kodların özgür yazılım olma hedeflerine ulaşmamıştır.

GPL yazılımlarının paragonu elbette linux ve FSF'den gelen her şeydir (gcc, vb ...). İlginç bir şekilde, linux için, GPL siyasi duruşu için değil, Linus Torvald tarafından birkaç kez belirtildiği gibi karşılıklılık fikri nedeniyle seçildi. Sana kodumu veriyorum, ama benimkini kullanırsan bana seninkini vermelisin.

Linux'un kendisi kadarıyla, GPL'nin çok değerli olduğunu düşünüyorum - son bir örnek, Oracle içinde geliştirilen yeni fs olan BTRFS. BTRFS'nin ana yazarı, Oracle'ın GPL'yi kullanmak için ilk etapta kabul etmesinin tek sebebinin bir seçeneğinin olmamasıydı. Daha büyük soru linux'un kendisinin başarılı olup olmadığıdır çünkü GPL'ye rağmen veya buna rağmen. Linus inanılmaz liderliği, * BSD projesi için telif hakkı sorunları vb. Gibi çeşitli faktörler, hipotezin kanıtlanmasını / çürümesini imkansız hale getirir.

Gcc için Stallman , GPL'nin projeyi neden "propietarizasyon" a karşı kurtardığını birkaç kez yazdı.


3
Stallman parlak olan birkaç şey yazdı. Ayrıca gerçeklikle şüpheli bir bağlantısı olan birkaç şey yazdı. GPL'nin "mülkleştirmeye" karşı gcc kaydettiğini iddia etmesi, bunu mutlaka yapmaz.
SADECE benim doğru GÖRÜŞÜM

elbette, ancak bu konu hakkında ne iddiada bulunursanız olun bu geçerlidir - nihayetinde konu hakkındaki kendi görüşünüze bağlı olacaktır. Kesinlikle kesin bir cevap olabileceğini düşünmüyorum, özellikle de soru sonuçları doğada ideolojik olduğu için (hem GPL hem de BSD / MIT benzeri lisanslar için).
David Cournapeau

Oracle örneği geçerli bir örnek, teşekkürler. Linux başarısına gelince, BSD lisanslı işletim sistemlerinin açık örnekleri olduğu için GPL'nin çok önemli olduğu konusunda şüphelerim var. Biraz daha az popülerler, ancak nedeninin GPL olduğundan şüpheliyim. Gcc'ye gelince, burada 'proprietizasyon'un tam olarak ne anlama geldiğinden emin değilim, ancak Intel'in kendi özel derleyicileri (gcc'den daha iyi) var, bu yüzden Stallman bu senaryoyu önlemek istiyorsa başarısız oldu.
StasM

Eğer gcc örneğin BSD olsaydı, insanlar kodu topluma geri vermeden iyileştirmelerini ekleyebilirlerdi. GCC, özel API ile entegre edilmeden genişletilmesi gibi bir şekilde yazılmıştır ( gcc.gnu.org/wiki/GCC_Plugins ).
David Cournapeau

18

BSD, MIT ve Apache lisansları gibi sınırsız lisansların FOSS'u tanıtmak için GPL'den çok daha fazlasını yaptığını söyleyebilirim.

Örnekler:

  • Kale Projesi,
  • jQuery,
  • SQLite,
  • Apache,
  • Hazırda Beklet ve nHibernate,
  • ASP.NET MVC,
  • JSON.ORG,

Ve bircok digerleri.

İşletmenin kendisi aslında GPL / katma değerli hizmetler modeli altında çalışmadığı sürece, çoğu işletme, GPL kodunu geliştirme çabalarının yakınındaki herhangi bir yere izin veremeyecek kadar dikkatli.


5
Daha fazla anlaşamadım.
yapılandırıcı

1
Ayrıca standart GPL ile ilgili bazı sorunları ele alan LGPL lisansından da bahsedeceğim: en.wikipedia.org/wiki/LGPL
andre

Yukarıdakilerden herhangi biri FOSS lisansının benimsenmesini nasıl teşvik eder?
Mark H

13
Bu cevabı anlamıyorum: BSD / MIT'in açık kaynak için GPL'den daha fazlasını yaptığını birkaç projeyi listelemek nasıl olur? GPL projeleri için benzer bir liste (linux, gcc, gnome, kde, qt, mysql, emacs, vb ...) alabilirsiniz ve GPL wrt hiçbir şey kanıtlamaz.
David Cournapeau

1
@George: evet, QT LGPL, GPL değil, karışıklık için üzgünüm. Yine de benim fikrimi değiştirdiğini sanmıyorum.
David Cournapeau

8

GNU GPL, FLOSS uygulamasına rağmen değil başarılı oldu. Şirketler çoğunlukla GPL kapsamında gönüllü olarak katkıda bulunmakta ve kod yayınlamaktadır. Ticari geliştiricileri kamulaştırmaya zorlayacak önemli algoritmalar ve kütüphaneler yoktur.

Apple iyi bir örnek veriyor. KHTML'yi kabul ettiler ve WebKit'e ilerlettiler. Ve kodu açık kaynak topluluğuna geri yayınladılar. Bunun LGPL tarafından zorlandıkları için varsayılabilir, ancak olası görünmüyor. Darwin ve BSD kullanıcıları için çok gönüllü olarak kodu yayınlıyorlar. Ve LLVM ile yepyeni bir FLOSS projesi bile başlattılar. Yine de Apple, büyük ölçüde tescilli bir yazılım satıcısı olmaya devam ediyor.

Android benzer. Tabii ki donanım desteği burada önemli bir rol oynar, ancak Google bir BSD kod tabanını benimseyebilir ve onu özel olarak alabilir. Ama Linux'u seçtiler. Dolayısıyla, GPL olmayan bir alternatif olmadığı için değil, isteyerek katkıda bulunurlar.

Openoffice daha ilginç bir hikaye, çünkü gerçekten bir noktada tescilliydi. Ancak yine, LGPL dönüşümü isteğe bağlıydı, gerekli değildi. * GPL türü lisans bu durumda bunu mümkün kıldı. Akademik BSD tipi bir lisans Sun'ın Openoffice'i serbest bırakması için yeterli olmazdı, çünkü o zaman başka biri kodu sahiplesmiş olabilir. Bu bakımdan GNU * GPL başarılı oldu.

Karşılıklı / viral yan tümce doğrudan daha açık kaynak koduna yol açmaz. Ancak yazılım satıcıları istedikleri zaman bunu kendi yararlarına kullanırlar ve bu nedenle FLOSS havuzuna katkıda bulunurlar. Yine de çoğu satıcı bunu isteksiz yapıyor. Daha fazla kod katkısını teşvik etmek açısından BSD tarzı ve GPL tarzı lisanslar arasında çok az fark görüyorum.
Sonuç olarak GNU GPL başarılı olmuştur, fakat aynı zamanda daha uygun olan yerlerde BSD / MIT tarzı lisansları da desteklemektedir. Ama aynı zamanda sadece gerçek FSF metriği olduğuna inandığım "kod miktarı" başarısını ölçebilirsiniz.


5
Komik, Android'den bahsetmelisiniz, çünkü GPL'de değiştirilemez bir platform yayınlamalarına izin veren bir boşluk bulmak için yola çıktı. (GPL'nin sonraki sürümlerinin kısıtladığı bir şey). Google, FSF ile aynı idealleri paylaşmaz ve android'in FOSS yazılımı olması büyük ölçüde ilgisizdir, çünkü hiç kimse kendi platformunda Google ile rekabet edecek kaynaklara sahip değildir (Endişelenecek rekabet varsa, ' alternatif bir çözüm seçtik). Ayrıca, Apple LLVM'yi başlatmadı.
Mark H

@sparkie: Bu ilginç. Daha dün bir Google geliştiricisinin cep telefonu satıcılarını üçüncü taraf Android yazılımlarına karşı cep kilitlemek için çarptığı bir makaleyi okudum. (Rağmen Googles açık kaynak çabaları çoğunlukla sunumu şüphem yok.)
mario

En büyük GPL projelerinden birini unutmayalım, Linux. Kodlarını ona ekleyen büyük satıcıların hiçbirinin (IBM, Oracle, vb.) Çatallanma ve 'gelişmiş kurumsal düzeyde çekirdek' uygun bir seçeneği yoktu, bunu herkese açık hale getirmek zorunda kaldılar. Ancak muhtemelen bu tür evrensel altyapı parçaları, GPL'nin BSD tarzı lisanslardan daha yararlı olduğu tüm alanla ilgilidir.
9000

3

GNU Manifestosu'na bakıldığında, şirketleri FOSS yazılımını piyasaya sürmeye ikna etmenin hedeflerden biri olduğu açık değildir. İşte bir teklif:

Dürüst olmadan bilgisayarları kullanmaya devam edebilmem için, özgür olmayan herhangi bir yazılım olmadan geçinebilmem için yeterli bir özgür yazılım gövdesi oluşturmaya karar verdim.

Sadece bu hedefe bakarsak, GNU projesi büyük ölçüde başarılı oldu. Bir GPL işletim sistemi, bir ofis paketi, veritabanları ve serbestçe değiştirilebilen ve yeniden dağıtılabilen diğer birçok uygulamamız var.


Anladığım kadarıyla, nihai amaç özgür olmak için olabildiğince çok yazılım yapmaktır ve birçok yazılım ticari varlıklar tarafından yazıldığından, bunu da ücretsiz yapmak önemli bir alt hedeftir. Amaç, özgür olmayan yazılıma ihtiyaç duymadan kullanılacak bir yazılım gövdesi yazmak olsaydı, neden sadece kamu malı haline getirmiyoruz? Açıkçası, GPL'nin viral doğasının PD veya hatta BSD lisansı ile ulaşılamayan bazı hedefleri vardır. Sizce bu hedefler neler?
StasM

GPL "kucaklama ve genişletme" stratejisini önler, böylece birisi Emacs'ı alamaz, böylece o kadar popüler hale gelen uzantıları ekleyemez ve mülk lisansı altında her şeyi serbest bırakır. Bununla birlikte, GNU manifestosu, en azından başlangıçta, GPL'nin amacının ne olduğunu açıkça ortaya koyuyor.
Larry Coleman

1

Bence her ikisi de (GPL ve BSD tipi lisanslar) FOSS dünyası için önemli. GPL kullanımını iki grupta görüyorum. Bunlardan biri çok meşgul Açık Kaynak destekçileri grubudur. Açık Kaynak'ı tekrar tescilli çalışmaya dönüştürme olasılığının OSS dünyasına zarar vereceğine inanıyorlar. Şahsen bence bu büyük bir sorun değil. PC-BSD (tescilli BSD varyantı) BSD topluluğuna zarar vermez. GPL'yi benimseyen ikinci grup büyük şirketler. Lisansı, ürün üzerinde daha fazla kontrol sahibi olmak için kullanırlar (örneğin iş modellerini desteklemek için). Yarışmada GPL lisanslı bir yazılım ürünü olan biriyle para kazanmak için sorunlar yaşanacaktır. Böylece şirket rekabette bir adım önde yer alırken, açık kaynaklı ürün için iyi bir karma elde edebilir.


2
oldukça önemli olduğunu düşündüğüm üçüncü kampı unutuyorsunuz: karşılıklılık. Yani, tescilli yazılımlarla ilgilenmezsiniz, ancak kodunuzun açık kaynak olarak yayınlanmasını tescilli olarak kullanmak istemezsiniz. GPL size bunu verir, BSD vermez. En azından içinde bulunduğum kamp bu.
David Cournapeau

0

Kişisel bakış açım, engellilik nedeniyle bir süredir kullanılmayan ve sahip olduğum tek değerli beceriden tekrar geçebilme umuduyla (veya hayal ederek) bireysel bir geliştiriciden biridir.

GPL her zaman ticari projeler için kullanılır. Sorun bazen "viral" doğası olarak adlandırılan şeydir, yani bir projede bazı GPL kodu kullanırsanız, muhtemelen o proje için tüm kodu GPL yapmanız gerekir . Bazıları dinamik bağlantı için bir dışlama olduğunu iddia ediyor. GPL SSS, paylaşılan veri yapıları nedeniyle eklentilere dinamik bağlantı yapılmasının yasaklandığını iddia ediyor - http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins. Bu, her Windows uygulaması Windows bileşenlerine dinamik bağlantı veren ve Windows ile veri yapılarını paylaşan (bir uygulama birçok yönden bir işletim sistemi eklentisidir) gibi garip görünüyor, ancak GNU tarafından bolca yayınlanan GPL Windows uygulamaları var. Belki de bu, işaretçileri tutamaç olarak gizlemek ve işlevler aracılığıyla en fazla erişim yapmak, veri yapılarını paylaşma olarak sayılmaz, bu da özel olarak tasarlanmış herhangi bir eklenti API'sının veya dinamik olarak bağlantılı kitaplığın muhtemelen istismar edebileceği bir boşluk olabilir, ancak açıkçası bireysel bir geliştiricinin güvenli oynaması gerekir. bu tür sorunlar üzerinde.

Her neyse, GPL'nin "viral" doğası için iyi nedenler var, ancak geçim kazanmak için umutsuz bir ihtiyacı olan küçük bir geliştirici için, bu şüphesiz işinizi hiçbir şey için vermek gibi görünüyor. Diğer konuların yanı sıra, ilgili becerilere sahip olmadığımız için, destek için ücret talep ederek veya etkili kitap satışları yaparak para kazanamayız. Ayrıca, ürününüzün ücretsiz bir el kitabı varsa, gerçek dünya el kitabı büyük olasılıkla Yığın Taşması veya Süper Kullanıcı ya da her neyse - ücretli kılavuzunuz değil. Ve bu, herkesin bunu anlamaya rahatsız olduğunu varsayar.

Bu açıdan bakıldığında, BSD tarzı lisanslar çok caziptir. Diğer açık kaynaklı çalışmalardan faydalanmanın, ancak ortaya çıkan ürünleri kapalı tutmanın ikiyüzlü olduğunu itiraf ediyorum, ancak bunun diğer konularla dengelenmesi gerekiyor.

OTOH, aslında hiçbir zaman açık veya kapalı bir şey yayınlamadım - en azından yaklaşık on yıl önce kamu malı yaptığım bir sürü eklenti (ve ekstra yılların deneyimi bana öğrettiği gibi, çok iyi yazılmadı) ). Yani her şey benim için akademik, en azından şimdilik.

Yine de, GPL tarzı lisansa sahip bir kütüphaneye her baktığımda, ilk düşüncem "buna bağımlı olursam seçeneklerimi sınırlandırırım" dır.


Windows çekirdek kitaplıkları GPL altında değildir, bu nedenle onlara bağlanırsanız uygulamanızı GPL yapmanız gerekmez. Hangi lisansın altında olduklarından emin değilim, ancak "Buna bağlanırsanız uygulamanızın kaynağı kapalı olmalıdır." Sorun yalnızca bir GPL kitaplığına bağlanırken ortaya çıkar. Windows kütüphaneleri GPL değildir.
jsternberg

Demek istediğim, uygulamanın (etkin bir işletim sistemi eklentisi) GPL altında olması. GPL olmayan Photoshop için bir GPL eklentisi yazmak yasaklanmışsa (Photoshop kaynağını serbest bırakamayacağınız için), neden GPL olmayan Windows için bir GPL "eklentisi" yazmak yasaklanmıyor? Örneğin, user32.dll gibi DLL'lerin Windows dinamik bağlantılarında çalışan herhangi bir komut satırı uygulaması, konsolun G / Ç API'leriyle veri yapılarını (en azından dizelerle) paylaşır. Bu erişim, standart kitaplık API'leri aracılığıyla dolaylı olarak yapılabilir, ancak GNU lisansları altında dağıtılan standart kitaplık uygulamaları da vardır.
Steve314

Aslında - GNU lisansları altında standart kütüphaneler olduğunu düşünüyorum , ama bunun GPL anlamına geldiğinden emin değilim.
Steve314

1
@ Steve314: GPL'yi daha dikkatli okuyun. Tam dili hatırlamasam da standart sistem bileşenlerine bağlanma izniniz var. GPL dikkatle pratiklik için tasarlandı - belirli bir ideolojik görüşü geliştirmede pratiklik, ancak yine de pratiklik.
David Thornley

1
@steve: bağlamayı unutun, vb ... GPL asla buna değinmez (LGPL bunu yapar). GPL, türetilmiş bir yazılımın, türetilmiş bir amaca yönelik olarak tanımsız bırakıldığı GPL altında yayınlanması gerektiğini, ancak bir yazılımın orijinali olmadan önemli ölçüde değiştirilmeden çalışamaması durumunda türev olduğunu söyler. Bir işletim sisteminin üzerine bir uygulama oluşturursanız, işletim sistemi uygulamanın bir türevi değildir (ilişki yansıtıcı değildir)
David Cournapeau

-2

İnsanlar GPL'yi düşündüklerinde, yazılımların özgürce düşünülmesi gereken gnu ideallerinde düşündüklerini, böylece fikirlerin yayılacağını ve büyük şirketlerin buna izin vermedikleri için kötü adamlar olduğunu düşünüyorum. Sorun şu ki, düşünce tarzı birçok programcı almıyor çünkü sadece kodlamak istiyorlar, programlıyorlar ve ayrıca yaşamları var, mutlaka yazılım içermiyorlar, bu görüşe göre BSD ve diğer lisanslar çok daha çekici, aynı anlamda Linus'un geliştiriciler için Richard Stallman'dan daha popüler olduğu için, çünkü ilki sadece çoğumuz gibi bir şey yapmak istiyor, diğeri ise tüm dünyayı değiştirmek istiyor. Sonuçta GPL, evrimi başlatan ancak başarılı olduğunu görmeye mahkum olmayan Mikhail Gorbaçov'a benziyor.

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.