Lisensi MIT vs GPL [ditutup]

122

Lisensi MIT kompatibel dengan GPL. Apakah lisensi GPL kompatibel dengan MIT? yaitu, saya dapat menyertakan kode berlisensi MIT dalam produk berlisensi GPL, tetapi dapatkah saya menyertakan kode berlisensi GPL dalam produk berlisensi MIT?

Bagi saya, perbedaan utama antara lisensi MIT dan GPL adalah bahwa MIT tidak memerlukan modifikasi menjadi sumber terbuka sedangkan GPL memerlukannya. Apakah itu benar? Apakah GPL lebih ketat daripada lisensi MIT?

licensing

— fruzer
sumber

1

en.wikipedia.org/wiki/MIT_License Lisensi ini juga kompatibel dengan GPL, artinya ...

— Michael Petrotta

76

Bagi saya, perbedaan utama antara lisensi MIT dan GPL adalah bahwa MIT tidak memerlukan modifikasi menjadi sumber terbuka sedangkan GPL memerlukannya.

Benar - secara umum. Anda tidak harus membuat perubahan Anda menjadi open source jika Anda menggunakan GPL. Anda dapat memodifikasinya dan menggunakannya untuk tujuan Anda sendiri selama Anda tidak mendistribusikannya. TAPI ... jika Anda DO mendistribusikannya, maka seluruh proyek Anda yang menggunakan kode GPL juga menjadi GPL secara otomatis. Artinya, itu harus bersumber terbuka, dan penerima mendapatkan semua hak yang sama dengan Anda - artinya, mereka dapat membalikkan dan mendistribusikannya, memodifikasinya, menjualnya, dll. Dan itu akan termasuk kode kepemilikan Anda yang kemudian tidak akan ada lagi menjadi hak milik - itu menjadi open source.

Perbedaannya dengan MIT adalah bahwa meskipun Anda benar-benar mendistribusikan kode kepemilikan Anda yang menggunakan kode berlisensi MIT, Anda tidak harus membuat kode tersebut menjadi open source. Anda dapat mendistribusikannya sebagai aplikasi tertutup tempat kode dienkripsi atau dalam bentuk biner. Menyertakan kode berlisensi MIT dapat dienkripsi, selama kode tersebut membawa pemberitahuan lisensi MIT.

apakah GPL lebih ketat daripada lisensi MIT?

Ya, sangat.

— Ravi Jayagopal
sumber

16

Boleh saya catat, GPL tidak membuat software "open-source". Perangkat lunak di bawah GPL menjadi GRATIS (seperti dalam melindungi kebebasan penggunanya). Perangkat lunak bebas adalah gerakan yang lebih tua dan lebih bermakna daripada perangkat lunak terbuka. Berikut artikel tentang perbedaannya: gnu.org/philosophy/open-source-misses-the-point.html . Terima kasih

— Jorge Orpinel

11

Untuk alasan yang sama, orang dapat berargumen bahwa MIT lebih restriktif, karena MIT tidak melindungi semua kebebasan pengguna dan dapat menyebabkan privatisasi perangkat lunak (= pembatasan dan hilangnya kendali oleh pengguna). Terima kasih lagi

— Jorge Orpinel

3

@tcurdt Mengapa ini bukan "tempat yang tepat" untuk berbicara tentang kebebasan? Mengapa swasensor? Dan tidak, sayangnya bukan itu yang dimaksud dengan 'gratis'. Bahkan tidak 'terbuka' artinya. Hanya untuk memperjelas, baik lisensi MIT maupun GPL tidak membiarkan Anda melakukan "apa pun dengannya". Hanya kode tanpa lisensi yang dapat masuk dalam kategori itu. Cheers

— Jorge Orpinel

3

Salah lagi, inilah stackoverflow yang seharusnya untuk stackoverflow.com/help/on-topic . Seseorang yang berpikir ini di luar topik tidak membuatnya demikian. Terlepas dari itu, saya memiliki kebebasan berekspresi dan ini semacam ruang publik jadi ... Ya. Anda tidak bisa menangani kesalahan. Pada kenyataannya, saya mencoba membantu Anda dan pembaca lain jika saya bisa. Bagaimanapun, semoga berhasil

— Jorge Orpinel

8

@JorgeOrpinel "Hanya kode tanpa lisensi yang dapat masuk dalam kategori itu." Itu sangat salah, kode tanpa lisensi adalah KEPEMILIKAN / "semua hak dilindungi undang-undang". Jika Anda berkeliling dan mendistribusikan ulang kode yang telah dibuat orang lain tanpa lisensi, Anda berisiko mengalami banyak masalah hukum. Anda mengatakan Anda mencoba untuk "membantu Anda dan pembaca lain" tetapi membuat pembaca digugat sebenarnya tidak terlalu membantu. FYI saja.

— titik koma

45

Dapatkah saya menyertakan kode berlisensi GPL dalam produk berlisensi MIT?

Kamu bisa. GPL adalah perangkat lunak gratis seperti halnya MIT, kedua lisensi tersebut tidak membatasi Anda untuk menyatukan kode karena "menyertakan" selalu dua arah.

Dalam hak cipta untuk sebuah karya gabungan (yaitu dua atau lebih karya membentuk satu karya), tidak ada bedanya jika satu karya "lebih besar" dari yang lain atau tidak.

Jadi, jika Anda menyertakan kode berlisensi GPL dalam produk berlisensi MIT, Anda juga akan menyertakan produk berlisensi MIT dalam kode berlisensi GPL.

Sebagai opini kedua, OSI mencantumkan kriteria berikut (lebih detail) untuk kedua lisensi (MIT dan GPL):

Distribusi Ulang Gratis
Kode sumber
Karya Turunan
Integritas Kode Sumber Penulis
Tidak Ada Diskriminasi Terhadap Orang atau Kelompok
Tidak Ada Diskriminasi Terhadap Bidang Usaha
Distribusi Lisensi
Lisensi Tidak Harus Spesifik untuk Produk
Lisensi Tidak Harus Membatasi Perangkat Lunak Lain
Lisensi Harus Netral Teknologi

Keduanya memungkinkan terciptanya karya gabungan, yang selama ini Anda minta.

Jika penggabungan kedua karya tersebut dianggap turunan, maka hal ini juga tidak dibatasi oleh kedua lisensi tersebut.

Dan kedua lisensi tersebut tidak membatasi untuk mendistribusikan perangkat lunak.

Bagi saya, perbedaan utama antara lisensi MIT dan GPL adalah bahwa MIT tidak memerlukan modifikasi menjadi sumber terbuka sedangkan GPL memerlukannya.

GPL tidak mengharuskan Anda untuk melepaskan modifikasi Anda hanya karena Anda yang membuatnya. Itu tidak tepat.

Anda dapat mencampur ini dengan distribusi perangkat lunak di bawah GPL yang tidak Anda tanyakan secara langsung.

Apakah itu benar - apakah GPL lebih ketat daripada lisensi MIT?

Beginilah cara saya memahaminya:

Sejauh jumlah distribusi, Anda harus meletakkan seluruh paket di bawah GPL. Kode MIT di dalam paket akan tetap tersedia di bawah MIT sedangkan GPL berlaku untuk paket secara keseluruhan jika tidak dibatasi oleh hak yang lebih tinggi.

"Restrictive" atau "more restrictive" / "less restriktif" sangat bergantung pada sudut pandang. Untuk pengguna perangkat lunak, MIT mungkin menghasilkan perangkat lunak yang lebih terbatas daripada yang tersedia di bawah GPL bahkan beberapa menyebut GPL lebih ketat saat ini. Pengguna tersebut secara spesifik akan menyebut MIT lebih restriktif. Ini hanya subjektif untuk mengatakannya dan orang yang berbeda akan memberi Anda jawaban yang berbeda untuk itu.

Karena membicarakan pembatasan lisensi yang berbeda hanya subjektif, Anda harus memikirkan tentang apa yang ingin Anda capai:

Jika Anda ingin membatasi penggunaan modifikasi Anda, MIT dapat lebih membatasi daripada GPL untuk distribusi dan mungkin itulah yang Anda cari.
Jika Anda ingin memastikan bahwa kebebasan perangkat lunak Anda tidak dibatasi sebanyak itu oleh pengguna yang Anda distribusikan, maka Anda mungkin ingin merilis di bawah GPL, bukan MIT.

Selama Anda adalah penulisnya, Andalah yang dapat memutuskan.

Jadi orang yang paling membatasi adalah penulisnya, terlepas dari lisensi mana yang dipilih siapa pun;)

— hakre
sumber

1

"Kode MIT di dalam paket masih akan tersedia di bawah MIT" saya tidak sepenuhnya yakin tentang itu. proyek GPL + MIT harus menyerahkan proyek sumber terbuka, termasuk bagian MIT. Untuk masalah lain, LGPL kurang mengganggu untuk keseluruhan proyek.

— magallanes

13

Meskipun nanti Anda mengklarifikasi jawaban Anda, sangat menyesatkan untuk memulai dengan mengatakan bahwa "Anda dapat" memasukkan kode berlisensi GPL dalam proyek berlisensi MIT. Sebuah proyek yang awalnya berlisensi MIT tidak lagi dapat didistribusikan secara keseluruhan di bawah lisensi MIT setelah berisi kode yang hanya tersedia di bawah GPL.

— antinome

3

Juga menyesatkan untuk mengklaim bahwa pembatasan itu subjektif. Merupakan pertanyaan yang masuk akal dan non-subyektif untuk menanyakan "tindakan apa yang secara hukum dapat saya lakukan dengan file yang telah saya peroleh?" Di bawah GPL, kumpulan tindakan itu sebenarnya adalah bagian yang tepat dari tindakan tersebut di bawah MIT.

— antinome

1

@hakra: Penyertaan kode berlisensi GPL dalam proyek berlisensi MIT tidak dimungkinkan karena keseluruhan yang dihasilkan tidak lagi memiliki lisensi MIT, meskipun Anda tidak mendistribusikannya. (Jika ya, maka persyaratan lisensi MIT akan memungkinkan Anda untuk mendistribusikannya!)

— antinome

9

tl; dr: Aplikasi berlisensi MIT dapat menyertakan kode GPL, tetapi aplikasi yang dihasilkan tidak berlisensi MIT.

— antinome

16

Anda benar bahwa GPL lebih ketat daripada lisensi MIT.

Anda tidak dapat memasukkan kode GPL dalam produk berlisensi MIT. Jika Anda mendistribusikan karya gabungan yang menggabungkan kode GPL dan MIT (kecuali dalam beberapa situasi tertentu, misalnya 'agregasi belaka'), distribusi tersebut harus sesuai dengan GPL.

Anda dapat menyertakan kode berlisensi MIT dalam produk GPL. Seluruh pekerjaan gabungan harus didistribusikan dengan cara yang sesuai dengan GPL. Jika Anda telah membuat perubahan pada bagian MIT kode, Anda akan diminta untuk mempublikasikan sumber untuk perubahan tersebut jika Anda mendistribusikan aplikasi yang berisi kode GPL dan MIT.

Jika Anda adalah pemilik hak cipta kode GPL, tentu saja Anda dapat memilih untuk melepaskan kode tersebut di bawah lisensi MIT sebagai gantinya - dalam hal ini itu adalah kode Anda dan Anda dapat menerbitkannya di bawah lisensi sebanyak yang Anda inginkan.

— JosephH
sumber

3

kecuali proyek tersebut berada di bawah lisensi ganda, misalnya jquery.

— buggedcom

7

@buggedcom - Anda dapat melisensikan ganda bagian-bagian yang berada di bawah lisensi MIT, tetapi Anda tidak dapat melisensikan ganda pustaka gabungan MIT / GPL - itu harus dilisensikan hanya di bawah GPL. (Anda tidak dapat mengambil suku cadang berlisensi GPL dan melisensikannya kembali di bawah lisensi MIT, karena itu bertentangan dengan persyaratan GPL). Dalam kasus jQuery, pemilik hak cipta dari kode merilisnya di bawah lisensi ganda, jadi itu bukan masalah, tetapi jika mereka "meminjam" beberapa kode GPL dari tempat lain, mereka tidak lagi dapat memberi lisensi MIT untuk karya gabungan tersebut .

— Tandai H

AFAIK itu tidak sepenuhnya benar. Menurut FSF, GPL kompatibel dengan lisensi MIT [1] Sayangnya itu tidak mengubah fakta bahwa proyek itu sendiri tidak lagi sepenuhnya tercakup di bawah lisensi MIT ... yang biasanya diharapkan orang. Anda tidak dapat lagi menggunakan proyek secara keseluruhan dalam konteks komersial tanpa merilis kode. Untuk menghindari kebingungan ini, lebih baik tidak menyertakan kode GPL dalam proyek berlisensi MIT. Bahwa Anda tidak bisa, itu salah. [1] gnu.org/licenses/license-list.html#SoftwareLicenses

— tcurdt

... tapi saya rasa itu tergantung pada apa yang Anda definisikan sebagai "produk"

— tcurdt

2

Produk berlisensi MIT (mungkin 'aplikasi' akan menjadi kata yang lebih baik) tidak dapat menyertakan kode GPL. Anda dapat menambahkan kode GPL ke dalam produk MIT, tetapi aplikasi yang dihasilkan hanya dapat didistribusikan di bawah lisensi GPL. Saya belum pernah melihat seseorang menggambarkan aplikasi yang hanya dapat didistribusikan di bawah persyaratan GPL sebagai 'produk berlisensi MIT'. Jika lisensinya tidak "kompatibel", Anda tidak dapat membuat karya gabungan sama sekali - fakta bahwa keduanya kompatibel berarti Anda dapat membuat karya gabungan yang dapat Anda distribusikan dan berlisensi GPL.

— JosephH

5

IANAL tapi seperti yang saya lihat ....

Meskipun Anda dapat menggabungkan kode GPL dan MIT, GPL tersebut tainting. Artinya paket secara keseluruhan mendapat batasan GPL. Karena itu lebih ketat, Anda tidak dapat lagi menggunakannya dalam perangkat lunak komersial (atau lebih tepatnya sumber tertutup). Yang juga berarti jika Anda memiliki proyek MIT / BSD / ASL Anda tidak ingin menambahkan dependensi ke kode GPL.

Menambahkan dependensi GPL tidak mengubah lisensi kode Anda tetapi akan membatasi apa yang dapat dilakukan orang dengan artefak proyek Anda. Ini juga mengapa ASF tidak mengizinkan dependensi ke kode GPL untuk project mereka.

http://www.apache.org/licenses/GPL-compatibility.html

— tcurdt
sumber

1

+1 Faktanya Microsoft menunjukkan masalah ini dengan sempurna, GPL adalah viral karena mengubah setiap proyek menjadi open source.

— magallanes

10

Tidak masalah . GPL dirancang dengan viral. Ini dimaksudkan untuk digunakan oleh orang-orang yang ingin membuat kode mereka gratis untuk digunakan orang lain sesuka mereka, tetapi juga mengharuskan orang lain yang menerbitkan salinan perangkat lunak itu atau turunannya menghormati pengguna dengan cara yang sama. GPL tentang pengguna . Ini bukan tentang perusahaan yang memaksimalkan keuntungan melalui monopoli yang dipaksakan oleh negara, jadi fakta bahwa rekursif sebenarnya adalah keindahan dan kekuatannya, bukan 'masalah' yang dapat 'ditunjukkan dengan sempurna' oleh Microsoft. Tidak diperlukan wawasan khusus untuk mengetahui bahwa GPL itu viral ~ Wikipedia sudah cukup.

— Carl Smith