Apa pro dan kontra dari GPL? [Tutup]


31

Saya melihat melisensikan beberapa perangkat lunak open source dan saya melihat GPL. Apa pro dan kontra dari penggunaan lisensi ini?



6
bukan duplikat. Pertanyaan ini difokuskan secara sempit pada GPL dan tidak mengambil perspektif "pandangan tinggi".
goodguys_activate

1
Saya cenderung memilih satu ekstrim atau yang lain: AGPL atau WTFPL.
TRiG

Mari kita letakkan ini dalam perspektif. Jika Microsoft akan membuat lisensi ini terlebih dahulu dan menjaga semua ketentuan persis sama, lisensi tidak akan memiliki yang sama. FOSS dan GLP tidak seperti yang terlihat. Baca Manifesto mereka. Mereka bukan tentang Anarki, mereka tentang kontrol.
Andrew T Finnell

Jawaban:


45

Oke, daftar pro dan kontra GPL saya:

Pro

  • Itu membuat orang berpikir keras apakah mereka benar-benar membeli Open Source; apakah Anda siap untuk hidup dengannya, dan membiarkan orang lain menggunakan apa yang Anda tulis, daripada hanya menyukainya karena apa yang bisa Anda dapatkan darinya?
  • Itu memastikan bahwa ketika sesuatu telah dikembangkan oleh komunitas Open Source, ia tetap Open Source; tidak ada peluang seseorang mengambil semua pekerjaan yang telah dilakukan orang lain, mengemasnya kembali dan menjualnya.

Cons

  • Ini benar-benar tidak boleh untuk sebagian besar organisasi perusahaan; mereka tidak dapat menanggung risiko kode berlisensi GPL masuk ke produk mereka, sehingga hampir semua perusahaan menengah besar memiliki klausul yang secara eksplisit melarang kode berlisensi GPL.
  • Ini membuat orang tidak menggunakan Open Source.
  • Apakah ini benar-benar adil, bahwa karena saya menggunakan kontrol pemilih gambar Sumber Terbuka di aplikasi saya, seluruh aplikasi saya sekarang harus menjadi Sumber Terbuka juga? Bahkan jika saya meningkatkan pemilih gambar dan menyumbangkan kode itu kembali ke komunitas? Persyaratan terlalu berat bagi banyak pengembang.
  • Banyak orang yang tidak mengetahui persyaratan ketat GPL, jadi gunakan itu sebagai lisensi yang mereka dengar tanpa menyadari batasan apa yang mereka berikan pada orang lain yang ingin menggunakannya.
  • Ini sangat viral. Jika proyek Anda mengandung komponen yang berisi komponen yang berisi komponen yang berada di bawah GPL (phew!), Seluruh proyek Anda juga tunduk pada GPL.

Pada akhirnya bagi saya kontra lebih besar daripada pro. Bagi saya itu menampar penginjil Open Source mencoba menipu dunia untuk menjadi Open Source daripada meyakinkan dunia tentang manfaatnya.


9
+1 untuk sebagian kontra, yang ya, saya setuju, terlalu "ketat". Lisensi MIT adalah alternatif yang bagus.
Benteng

16
Ini adalah FUD yang transparan: "Ini benar-benar tidak boleh untuk sebagian besar organisasi perusahaan; mereka tidak mampu menanggung risiko kode berlisensi GPL masuk ke dalam produk mereka, sehingga hampir semua perusahaan menengah-besar memiliki klausul yang secara eksplisit melarang kode berlisensi GPL . " Kode dan proyek berlisensi GPL tidak kontroversial di Fortune 500 sejak setidaknya tahun 2004, dan memang banyak perusahaan besar (Google, IBM, Oracle, dan lain-lain) telah mendasarkan sebagian besar bisnis mereka darinya.

13
Ada perbedaan di sini antara perusahaan produk perangkat lunak, yang seringkali tidak dapat menyentuh kode GPL, dan perusahaan yang menggunakan perangkat lunak untuk penggunaan internal, di mana GPL pada dasarnya tidak berpengaruh. Ada lebih banyak yang terakhir daripada yang pertama.
David Thornley

9
BTW, GPL dirancang sebagai pendorong gerakan sosial, tetapi tujuannya adalah untuk membuat repositori Perangkat Lunak Bebas yang akan selalu tetap Gratis, dan yang semakin menggoda untuk digunakan. Sejauh yang saya tahu, itu bukan upaya untuk menjebak pengembang menjadi apa pun. Selanjutnya, orang di belakang GPL, Richard Stallman, menolak semua koneksi dengan Open Source sebagai lawan dari Perangkat Lunak Bebas.
David Thornley

4
Pengalaman David Thornley pada dasarnya cocok dengan pengalaman saya. Saya belum pernah mendengar perusahaan yang tidak akan menggunakan kode GPL untuk penggunaan internal. Heck, semua orang punya Linux di banyak tempat. Namun, banyak perusahaan yang mengembangkan perangkat lunak untuk distribusi tidak akan mengizinkan kode GPL di dekat basis kode pengembangan mereka. LGPL biasanya baik-baik saja, tetapi tidak selalu.
David Schwartz

2

Meskipun h4xxr pasti memberikan jawaban FTW, berikut adalah beberapa tautan lagi yang bisa berguna, jika Anda tidak yakin tentang apa yang dilambangkan berbagai jenis lisensi.

Perbandingan lisensi perangkat lunak gratis (perbandingan tabel)
Open Source Initiative - Lisensi berdasarkan Nama (apa yang dikatakannya - lisensi yang umum digunakan dalam dunia perangkat lunak saat ini) Daftar lisensi perangkat lunak, termasuk yang kompatibel dengan GPL

F --- GPL <- kritik cerdas (harus menyukai ini "mutiara kebijaksanaan" :-)


2

FWIW Saya pribadi memiliki proyek open source besar yang saya pimpin pengembang dan saya telah mengadopsi beberapa model lisensi justru karena GPL menahan beberapa orang dari menggunakan kode saya. Kode saya dilisensikan di bawah pilih model lisensi Anda sendiri dan memungkinkan salah satu dari lisensi berikut - GPL, LGPL, MIT

LGPL memungkinkan orang untuk memasukkan kode / pustaka / dieksekusi Anda apa adanya dalam produk mereka asalkan tidak diubah. Ini sangat berguna untuk perusahaan yang membangun produk komersial / sumber tertutup yang mungkin membutuhkan produk Anda berfungsi tetapi tidak perlu mengubah cara produk Anda berfungsi.

Lisensi MIT pada dasarnya adalah lisensi permisif yang memungkinkan orang memodifikasi pekerjaan Anda sesuai keinginan mereka dan menggunakannya kembali untuk pekerjaan mereka sendiri. Gunakan ini jika Anda mencurigai pengguna mungkin ingin melakukan ini dan Anda tidak keberatan tidak memiliki akses ke sumber modifikasi apa pun yang dilakukan orang.


2

Memilih GPL adalah langkah ideologis:

Anda memberikan keuntungan kepada pengembang perangkat lunak gratis, karena mereka dapat menggunakan perpustakaan Anda, dan para pemain komersial tidak dapat (setidaknya selama mereka tidak ingin merilis produk mereka sebagai GPL). Perusahaan harus membayar pekerja mereka untuk menulis perpustakaan yang memiliki fungsi yang sama. Anda mempromosikan perangkat lunak gratis dengan cara itu.

Memilih lisensi yang tidak terlalu terbatas, seperti MIT lebih praktis:

Anda dapat menggunakan perpustakaan Anda sendiri, ketika mengkodekan untuk uang (sebagai freelancer, sebagai karyawan). Namun, semua orang bisa, jadi Anda membantu perusahaan untuk menghemat uang, meskipun mereka sudah kaya tanpa itu.


+1 GPL adalah keputusan ideologis / filosofis, bukan teknis. Apakah ini hal yang baik atau buruk tergantung pada masalah filosofis, dan tergantung pada setiap proyek atau tim untuk memutuskan.
Andres F.

1

Ketika datang ke proyek open source berlisensi secara bebas (misalnya X11, PostgreSQL, Haskell), GPL dan LGPL menjadi bumerang. Kode GPL tidak dapat digunakan dalam proyek tersebut, bukan karena GPL melarangnya atau lisensi X11 melarangnya, tetapi karena proyek tersebut tidak ingin "meningkatkan" seluruh lisensi efektif produk mereka ke GPL.


0
  • Manfaat: Anda dijamin secara hukum bahwa orang-orang membuat perubahan / kontribusi mereka tersedia untuk Anda.
  • Biaya: banyak pengguna komersial tidak dapat menggunakan kode Anda. Mereka tidak akan menggunakan kode Anda dan karenanya tidak akan pernah berkontribusi. Lihat utas ini menjelaskan mengapa orang libcinder tidak dapat menggunakan (L) kode GPL. Bahkan LGPL dapat menjadi masalah ketika mereka perlu menghubungkan perpustakaan secara statis.

Saya pikir itu hanya benar jika dalam skenario non SaaS ... dan juga saya mungkin perlu menemukan garpu saya dan meminta mereka untuk membagikan salinannya kepada saya.
goodguys_activate

Itu benar, untuk SaaS ada AGPL. Mengidentifikasi pelanggaran tidak mudah, tetapi ketika ditemukan, ada orang yang membantu Anda: gpl-violations.org
LennyProgrammers

Manfaat Anda salah: jika saya mengedit perangkat lunak dan menggunakannya sendiri, Anda tidak berhak melihat hasil edit saya. Hal yang sama berlaku jika saya membagikannya ke grup tanpa minat membagikannya. The pengguna memiliki hak untuk melihat sumber, tidak semua orang.
K.Steff
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.