Rekomendasi dan pengalaman tentang lisensi mana yang harus dipilih untuk perangkat lunak?

26

Pengembang perangkat lunak memiliki pilihan untuk memilih lisensi yang sesuai sesuai dengan tujuan pekerjaan.

Adakah yang bisa memberikan rekomendasi / pengalaman tentang lisensi mana yang harus dipilih untuk perangkat lunak?

Apa pro / kontra dari "memberikan" semua pekerjaan yang dikodekan sebagai kode sumber terbuka?

Bagaimana cara berurusan dengan pemain industri yang ingin mendapat manfaat dari kode penelitian?

Allan P. Engsig-Karup
sumber
Pertanyaan bagus, saya juga bertanya-tanya tentang itu.
milancurik
Ini tidak relevan dengan situs ini. Saya akan merekomendasikan posting ke sesuatu seperti Stack Overflow.
aterrel
Saya hanya ingin memperbaiki pernyataan Matt bahwa perangkat lunak berlisensi GPL / LGPL tidak dapat digunakan secara komersial. Itu juga bisa! Perangkat lunak berlisensi GPL dapat digunakan untuk apa pun yang diinginkan entitas komersial, mereka tidak dapat membuat produk perangkat lunak turunan dan menjual (mendistribusikan) yang sebagai sumber tertutup (yang seharusnya cukup jika entitas komersial bukan perusahaan perangkat lunak). LGPL lebih permisif dan memungkinkan penjualan produk perangkat lunak tertutup yang terhubung ke perpustakaan asli. Saya setuju dengan Matt bahwa industri takut menyentuh perangkat lunak GPL tetapi didasarkan pada kesalahpahaman tentang GPL. Kami awalnya menggunakan
Anders Logg
1
Saya tidak setuju. Banyak orang menginvestasikan banyak waktu dan upaya keras dalam mengembangkan basis kode baru untuk masalah yang menantang dalam ilmu komputasi. Sebagai bagian dari upaya ini dapat bermanfaat untuk memiliki strategi untuk berbagi pekerjaan dengan orang lain.
Allan P. Engsig-Karup
2
Ya dan banyak orang komputasi menghabiskan waktu memasak, tetapi memasak di luar topik di sini. Ada pertukaran bertumpuk lain untuk masalah perangkat lunak dasar.
aterrel

Jawaban:

18

Adakah yang bisa memberikan rekomendasi / pengalaman tentang lisensi mana yang harus dipilih untuk perangkat lunak?

Lisensi mana yang Anda pilih akan bergantung pada seberapa bebas Anda menginginkan kode Anda, tetapi gratis berarti berbeda untuk orang yang berbeda.

  • Untuk pendukung lisensi permisif , gratis berarti memungkinkan orang sekarang untuk menggunakan perangkat lunak namun mereka ingin sekarang , tidak khawatir tentang derivasi bebas di masa depan.
  • Untuk para pendukung lisensi copyleft , gratis berarti memastikan bahwa perangkat lunak dan setiap derivasi itu tetap bebas , sedang dipersiapkan untuk mengorbankan beberapa kebebasan langsung untuk memastikannya.

Lisensi semakin permisif, semakin banyak orang akan dapat menggunakannya, tetapi semakin sedikit kontrol yang Anda miliki atas lisensi tersebut. Semakin ketat, semakin besar kemungkinan Anda menunda orang menggunakan perangkat lunak Anda.

Ada sejumlah lisensi sumber bebas dan terbuka di luar sana, termasuk GPL <= 2, GPL 3 , LGPL , BSD , Eclipse dan sebagainya. Ada pro dan kontra untuk masing-masing, jadi bacalah batasan apa yang mereka tempatkan pada kode dan putuskan siapa yang ingin Anda dapat menggunakannya. Peringatan , mana pun yang Anda pilih seseorang akan mengeluh - ini adalah wilayah perang suci .

Secara keseluruhan itu adalah tindakan penyeimbangan yang halus, dan itu sangat tergantung pada audiens target untuk perangkat lunak Anda.

  • Sumber yang bagus untuk menentukan lisensi mana yang merupakan lisensi yang tepat untuk Anda adalah, pembeda lisensi interaktif yang sangat komprehensif , dari Oxford University OSS Watch .

Menurut pendapat saya, baik lisensi permisif dan copyleft sesuai untuk kode ilmiah - yang penting adalah bahwa kode tersebut open source di tempat pertama. Saya percaya bahwa Sains harus Terbuka, dan kode harus digunakan untuk mendukung ilmu itu.

Apa pro / kontra dari "memberikan" semua pekerjaan yang dikodekan sebagai kode sumber terbuka?

Gagasan memberikan perangkat lunak Anda adalah bahwa jika orang lain merasa berguna maka mereka akan menggunakannya.

Jika mereka menggunakannya, mereka akan menemukan, melaporkan, dan sering memperbaiki bug, menghemat upaya Anda untuk melakukan hal yang sama.

Jika mereka menyukainya dan perangkat lunak Anda melakukan hampir apa yang mereka inginkan, mereka mungkin meningkatkan perangkat lunak Anda dan menyumbang peningkatan itu kembali.

Itu banyak jika seandainya .

Bagaimana cara berurusan dengan pemain industri yang ingin mendapat manfaat dari kode penelitian?

Pertama, jika Anda ingin melarang penggunaan komersial kode Anda, Anda dapat memilih lisensi tanpa klausa penggunaan kembali komersial.

Kedua, jika Anda berpikir seseorang mungkin menggunakan perangkat lunak Anda untuk memberi daya pada layanan, tanpa pernah benar-benar mendistribusikan kode tersebut kepada orang lain, maka Anda dapat mempertimbangkan Affero GPL yang menghubungkan celah celah copyleft tersebut.

Ketiga, Anda dapat melakukan hal di atas dan menawarkan opsi lisensi ganda. Menawarkan lisensi GPL atau AGPL untuk unduhan publik, dan lisensi komersial dengan bayaran memberi Anda yang terbaik dari kedua dunia, dan berarti Anda bahkan mungkin dapat menghasilkan pendapatan dari penjualan komersial perangkat lunak Anda yang dapat membantu mendukung kegiatan ilmiah Anda.

Catatan, jika Anda akan melakukan ini, tawarkan sejak awal - yang mungkin menyebabkan lebih sedikit gesekan dari kontributor open source Anda daripada mulai menawarkan lisensi komersial nanti. Jika komunitas Anda menjadi populer, Anda tidak ingin orang menuduh Anda menjual jika Anda tidak jujur ​​tentang kemungkinan eksploitasi komersial nanti. Idealnya Anda harus menyiapkan Perjanjian Lisensi Kontributor (CLA) yang sesuai sebelum Anda mulai menerima kontribusi pihak ketiga ke dalam basis kode Anda.

Jawaban untuk pertanyaan ini juga memberikan informasi yang bagus tentang opsi ini.

Mark Booth
sumber
12

PETSc menggunakan lisensi ini , yang merupakan bentuk BSD yang tidak terlalu ketat . Perbedaan penting dari GPL, adalah bahwa perangkat lunak dapat digunakan secara komersial. Banyak orang yang keberatan dengan perangkat lunak tertutup, tetapi menurut pengalaman saya, tidak ada bisnis yang akan mendekati kode Anda jika memiliki lisensi GPL. Selain itu, pengguna industri PETSc sangat berharga. Mereka cenderung menghadapi masalah yang cukup rumit, yang menurut kebanyakan akademisi lebih sulit daripada dijamin untuk publikasi. Mereka juga berkontribusi banyak kode kembali ke PETSc, sehingga akan memasuki rantai dukungan normal. Saya akan menyarankan terhadap lisensi apa pun tanpa potensi penggunaan komersial, dan pada kenyataannya menganjurkan lisensi seketat mungkin (Anda pasti bisa membakar PETSc ke CD dan mencoba dan menjualnya ke yang mudah tertipu).

Matt Knepley
sumber
Bagaimana perkembangan PETSc didanai? dan bagaimana hal itu didukung (melalui pendanaan) hari ini? Bagaimana cara kerjanya dengan pemeliharaan basis kode untuk PETSc?
Allan P. Engsig-Karup
2
Ini pendanaannya . Kami memiliki repositori terbuka dan banyak kontributor.
Matt Knepley
Tentang pernyataan Anda tentang kode GPL: OpenFOAM adalah GPL dan digunakan secara luas di industri. Alasannya adalah bahwa kode GPL hanya harus dibuat publik jika perangkat lunak akan didistribusikan. Hanya bisnis yang ingin menjual kode mereka ke khalayak luas yang akan terpengaruh oleh lisensi GPL.
akid
3
@ akid Saya tidak dapat menemukan informasi tentang pengguna OpenFOAM di situs web, tetapi saya ragu dengan karakterisasi "banyak digunakan". Saya dapat memberitahu Anda bahwa orang-orang dari perusahaan besar (Shell, Boeing, MS) telah menyatakan bahwa kebijakan perusahaan untuk kode penelitian adalah jangan pernah menyentuh GPL. Mungkin perusahaan kecil memiliki lebih banyak kelonggaran, tetapi perusahaan yang lebih besar hanya ingin menghindari penampilan yang tidak pantas (melihat kode GPL dan mengkode sesuatu yang lain).
Matt Knepley
2
@Tepang, GNOME dan Linux digunakan seperti peralatan kantor, yang tidak akan pernah terjadi pada kode ilmiah Anda. Maksud saya ketika kode Anda digunakan untuk tujuan yang terkait langsung dengan bisnis.
Matt Knepley
5

Saya menggunakan GPL, terutama karena sentimen terhadap gerakan open source asli (dan dengan demikian berharap bahwa itu akan membantu penyebarannya). Selain itu, ini secara paradoks merupakan cara terbaik untuk melindungi kemungkinan penghasilan Anda dari kapitalis tidak bermoral - sebagai penulis, Anda selalu dapat mendistribusikan kode pada lisensi yang berbeda secara paralel dan dengan demikian mempertahankan versi kepemilikan untuk penggunaan bisnis label-putih.
Namun, ini mungkin juga merupakan con - sumber pendanaan Anda mungkin membuat penafian bahwa semua pekerjaan Anda harus menjadi domain publik, apa yang melampaui lisensi ini.

Pokoknya, hal yang paling penting dalam topik itu adalah bahwa setiap lisensi lebih baik daripada tidak, yang sayangnya cukup sering dalam dunia pengembangan ilmu pengetahuan - dan saya hanya benci semua orang / * Dicuri dari program John Smith dia tidak pernah dipublikasikan * / atau CI pikir saya melihat ini di pos Jane Smith di beberapa grup pada 1995 ... atau mungkin 1993?

mbq
sumber
1
Ingat, jika kode tidak memiliki lisensi maka di sebagian besar negara (yang telah menandatangani konvensi Berne ) masih dilindungi oleh hak cipta, jadi tidak dapat digunakan secara hukum oleh siapa pun selain pemegang hak cipta, apalagi didistribusikan kembali.
Mark Booth
@MarkBooth Itulah maksud saya.
mbq
5

Pertama, pro / kontra dari open source:

Pro: lebih banyak orang akan menggunakan kode Anda, memberikan umpan balik, koreksi, perbaikan, dll. Anda akhirnya akan memiliki kode yang lebih baik dan lebih banyak orang yang mempercayainya.

Con: jika Anda ingin mendasarkan bisnis dalam kode Anda, Anda memiliki lebih sedikit pilihan (tetapi masih ada beberapa, seperti menjual jasa konsultasi)

Adapun untuk memilih lisensi, saya akan melanjutkan dalam urutan berikut:

  1. Apakah majikan / agen pemberi hibah Anda memaksakan sesuatu? Maka Anda tidak punya pilihan. Periksa ini untuk semua kontributor kode.
  2. Apakah Anda menggunakan kembali kode yang memiliki lisensi tertentu yang membatasi pilihan Anda? Maka pilihan Anda juga terbatas. Dalam praktiknya, mengintegrasikan potongan-potongan kode berlisensi GPL adalah sumber pembatasan yang paling sering.
  3. Putuskan apa yang Anda nilai lebih: filosofi semua-kode-harus-terbuka di belakang GPL dan lisensi serupa, atau filosofi mendorong-seluas-luasnya penggunaan di belakang lisensi BSD.
  4. Dalam masing-masing dari dua keluarga besar lisensi Sumber Terbuka, pilih sesuai dengan apa yang paling umum / diterima di komunitas Anda.
khinsen
sumber
5

Sebagian besar penelitian saya didanai oleh dana publik, jadi saya merasa berkewajiban untuk menggunakan lisensi seketat mungkin. Jika orang lain di negara saya membantu membayar untuk penelitian ini, apakah saya benar-benar memiliki hak untuk memberi tahu mereka bahwa mereka tidak dapat mengintegrasikan kode saya ke sumber tertutup dan / atau distribusi perangkat lunak komersial? Saya berharap bahwa sebagian besar orang yang menggunakan kode saya akan menjadi ilmuwan akademis, tetapi saya tidak memiliki masalah filosofis dengan bisnis meningkatkan perangkat lunak saya dengan mengintegrasikannya dengan perangkat lunak lain (mungkin komersial), meletakkan GUI di atasnya, dll, untuk memberikan produk yang membantu mereka menghasilkan keuntungan.

Karena itu, saya mencoba menggunakan lisensi yang membutuhkan atribusi yang tepat. Misalnya, jika sebuah perusahaan tidak lipat kode saya menjadi produk komersial yang lebih besar, saya ingin mereka untuk membuatnya jelas bahwa kode saya bisa didapatkan secara bebas dari saya. Tapi selain itu, saya ingin menempatkan persyaratan sesedikit mungkin pada pengguna kode saya.

Untuk pengembangan perangkat lunak yang tidak didanai oleh dolar pembayar pajak, saya mengerti bahwa lisensi lain mungkin lebih tepat.

Daniel Standage
sumber
5

Tidak ada yang mengatakan ini dengan sangat jelas, jadi saya pikir itu layak untuk dikatakan:

Beberapa lisensi open source (terutama: GPL) "viral" dalam arti bahwa setiap kali kode digunakan dalam proyek baru, proyek baru harus dilisensikan dengan cara yang sama. Selain itu, kode tidak dapat ditautkan ke (dengan cara tertentu) kode berlisensi berbeda.

Salah satu konsekuensi praktisnya adalah:

  • Jika Anda menerapkan metode numerik baru dalam C, lisensi tidak akan mengizinkan pemanggilan dari perangkat lunak umum seperti MATLAB atau Mathematica

  • Jika Anda menerapkan algoritme pemrosesan gambar baru, lisensi tidak akan mengizinkan membuat plugin Photoshop

  • dan seterusnya ...

Ini tidak hanya akan mencegah penggunaan kembali secara komersial, tetapi juga penggunaan kembali yang nyaman oleh akademisi lain (jika mereka menggunakan perangkat lunak tertutup), dan jika seseorang membangun di atas kode Anda, itu akan mencegah mereka memberikan pekerjaan mereka dalam "lakukan -apa-kamu-akan-dengan-itu "jalan.

Ini adalah sesuatu yang harus Anda pertimbangkan sebelum Anda selesai merumuskan lisensi Anda.

Saya katakan demikian karena saya telah bertemu orang-orang (tidak terlalu mengenal lisensi open source) yang tidak menyadari hal ini, atau belum mempertimbangkannya dari sudut pandang ini.


(Ini hanya pendapat pribadi, tetapi saya percaya bahwa menerapkan pembatasan seperti itu pada pekerjaan yang berasal dari akademisi (yang didanai publik) tidak tepat. Jadi saya baik menyimpan kode, atau saya memberikannya.)

Szabolcs
sumber
4

Terlepas dari lisensi apa yang Anda pilih, ingatlah untuk memeriksa dengan cermat semua perjanjian pendanaan Anda untuk memastikan tidak ada klausul di dalamnya yang menentukan atau membatasi bagaimana Anda bisa melisensi perangkat lunak Anda.

Saya tahu dalam kasus saya banyak proyek saya dibangun dari beberapa lapisan pendanaan, sedikit di sini dan sedikit di sana, dan melacak bagaimana saya diizinkan melisensikan barang-barang saya oleh orang-orang yang menyalakan lampu dan mesin yang berjalan cukup kompleks.

Fomite
sumber
4

Untuk sejumlah besar kode, saya mencari salah satu lisensi yang dijelaskan dalam jawaban lain, dan biasanya LGPL. Namun, meskipun biasanya tidak disarankan untuk perangkat lunak , untuk skrip mandiri kecil yang mungkin saya kirimkan ke kolega di industri, saya sering memilih lisensi Creative Commons . Ini karena mereka cenderung lebih jelas bagi individu yang saya kirimi kode, yang menghentikan potensi masalah kesalahpahaman. Ini bekerja dengan baik untuk saya di masa lalu.

qubyte
sumber
4

Tidak seperti kebanyakan orang yang menjawab di sini (yang bekerja di organisasi akademik dan / atau publik), saya bekerja di bidang komersial.

Untuk produk saya, kode ditutup dan terus ada keuntungan bisnis utama untuk melakukan ini. Tetapi tentu saja ada cara lain untuk melakukannya (misalnya seperti yang ditunjukkan oleh MySQL antara lain). Saya sering melihat pendekatan lisensi komersial LGPL + untuk perpustakaan. Saya belum menggunakan perpustakaan seperti itu dalam sistem komersial, tetapi saya tidak akan mengesampingkannya (sejauh ini saya hanya menggunakan perpustakaan seperti itu, misalnya. ALGLIB, pada tingkat R&D). Ini kontras dengan produk GPL - yang mungkin saya gunakan secara internal tetapi tidak akan pernah digunakan dalam suatu produk, terutama karena sifat virus.

Ketika saya merilis kode sumber (contoh cara, program gratis, dll), saya biasanya menggunakan lisensi Berkeley. Ini tampaknya jauh lebih dalam semangat kode "bebas", dengan atribusi tetapi tanpa ikatan dan politik GPL. Mungkin inilah sebabnya mengapa (atau lisensi serupa seperti lisensi MIT) sangat populer di universitas dan organisasi publik. Kode sumber diberikan dalam arti sebenarnya dari 'gratis' (inilah beberapa kode, lakukan apa yang Anda inginkan dengannya) tetapi penulis masih mendapatkan kredit / atribusi.

menang
sumber
Saya bukan orang yang memilih ini, dan saya benar-benar ingin memilih itu karena Anda lebih suka lisensi BSD dan lebih detail tentang mengapa bisa menarik. Namun, ada masalah. Bahasa yang digunakan provokatif. Informasi yang persis sama dapat dikomunikasikan tanpa empedu, dan Anda kemungkinan akan menghubungi lebih banyak orang dengan pesan Anda.
qubyte
@ MarkS.Everitt: Selain komentar tentang politik, apa sebenarnya yang provokatif di sini?
aeismail
Ya tidak ada empedu yang dimaksudkan. Komentar saya tentang politik GPL adalah pendapat pribadi tetapi juga sebuah pengamatan - saya berasumsi suara turun itu hanya jenis politik yang mematikan saya (beraninya saya mengkritik GPL dan menulis kode tertutup!)
winwaed
Ambil contoh kalimat pembuka Anda. Ini langsung saya lawan Anda , yang dilanjutkan dalam kalimat "Bertentangan dengan apa ...". Seharusnya tidak masalah, tapi sayangnya itu penting. Ini juga merupakan lereng yang licin untuk menghasilkan argumen, dan SE muda tidak membutuhkannya.
qubyte
Kalimat pertama menentukan konteks jawaban saya - SEMUA ORANG menulis dari pengalaman mereka sendiri apakah mereka mengakuinya atau tidak. Konteks itu penting - Dan saya pikir itu terutama bagi saya. Saya akan mencoba mengedit paragraf berikutnya tetapi saya mungkin menyerah dan menghapus semuanya. Saya pikir saya punya sesuatu yang berguna untuk dikatakan ...
winwaed
0

Ini adalah pertanyaan lama, tapi saya pikir Lisensi Publik Mozilla layak disebut sebagai jalan tengah antara lisensi permisif (BSD, MIT) dan lisensi copyleft yang kuat (GPL). Kode MPL dapat digunakan dan didistribusikan kembali, tetapi kode MPL dan modifikasi apa pun untuk itu harus tersedia. Sebagai contoh, sebuah perusahaan dapat mengambil beberapa kode MPL, melakukan perbaikan sendiri, dan mendistribusikannya dalam paket perangkat lunak sumber tertutup, selama mereka menyediakan versi modifikasi dari kode MPL asli mereka. Mereka tidak diwajibkan untuk melepaskan semua kode sumber mereka sendiri, seperti yang akan mereka lakukan dengan GPL.

Dengan lisensi BSD, ada ketakutan bahwa sebuah perusahaan dapat mengambil kode Anda dan memperbaikinya tanpa memberikan kontribusi ini kepada Anda atau masyarakat luas, dengan alasan bahwa perbaikan yang mereka lakukan untuk itu memberikan keunggulan kompetitif. (Jawaban Matt Knepley menunjukkan bahwa tidak setiap tindakan bertindak seperti ini). Di sisi lain, banyak orang mungkin menghindari kode GPL sama sekali. MPL menghindari kedua perangkap potensial ini, setidaknya secara prinsip.

Daniel Shapero
sumber