Bisakah saya menautkan ke perpustakaan GPL dari aplikasi sumber tertutup?

Oke, sebelum semua orang berteriak tentang pertanyaan rangkap, ya, saya sudah melihat beberapa pertanyaan seperti ini di sini. Tapi tidak ada yang menjawab pertanyaan itu.

Jika saya menautkan pustaka GPL-ed tanpa memodifikasi pustaka itu, apakah saya harus merilis kode sumber?

Menurut pertanyaan ini , jawabannya adalah ya!

Tetapi jawaban ini tidak memuaskan bagi saya. Jawabannya pada dasarnya mengatakan bahwa saya tidak dapat menggunakan kode GPL dengan cara apa pun tanpa membuat kode saya open source.

Tetapi jika sebelumnya benar maka itu akan menunjukkan bahwa tidak ada orang atau organisasi yang bisa merilis perangkat lunak berpemilik di Linux. Yang pasti salah. Hanya karena agar aplikasi apa pun dapat melakukan sesuatu yang berguna, membuka file, menulis ke konsol, membuat koneksi TCP, aplikasi tersebut harus ditautkan ke libcGPL-ed.

Jadi pertanyaan saya adalah ini: Jika GPL menyatakan, seperti semua jawaban sebelumnya di situs mengatakan, bahwa suatu program yang menautkan ke program GPL lain haruslah GPL itu sendiri, bagaimana mungkin membuat / melepaskan / menjual aplikasi kepemilikan apa pun sama sekali yang berjalan di Linux? Karena seperti yang saya jelaskan di atas aplikasi itu harus suka kode GPL hanya untuk berjalan di Linux.

Contoh yang lebih praktis katakanlah saya menautkan ke perpustakaan bersama yang GPL-ed dalam aplikasi non-GPL, akankah itu memaksa aplikasi non-GPL menjadi GPL-ed? Lebih khusus lagi jika saya menggunakan pustaka GPL tanpa mengubahnya, dan kemudian mendistribusikan pustaka itu sebagai .soatau .dll, akankah itu mengharuskan aplikasi saya menjadi open source?

gpl linking

— john-charles
sumber

Anda terus menanyakan pertanyaan yang sama dengan harapan jawaban yang berbeda. Anda tidak dapat menggunakan GPL dalam perangkat lunak yang tidak kompatibel dengan GPL. Sangat sederhana.

— Andrew T Finnell

Benarkah dia? Astaga. Jawabannya sederhana; mengapa Anda tidak menghubungi penulis program GPL dan bertanya apakah mereka keberatan? Jika mereka mengatakan itu bagus, itu hebat! Jika mereka keberatan, maka mencoba mempersenjatai mereka dengan perincian hukum akan membuat Anda sangat tidak populer, tidak peduli seberapa "benar" Anda merasa diri Anda.

— James

@James: Jika mereka memilih GPL, itu adalah pernyataan yang cukup kuat mereka lakukan pikiran. Orang yang tidak keberatan memilih MIT atau BSD atau LGPL di tempat pertama. Sangat jarang melihat perpustakaan di bawah GPL penuh. Ketika Anda melakukannya, Anda bisa yakin itu disengaja.

— Jan Hudec

@ Jan Mungkin, tergantung pada aplikasi dan penggunaan john-charles yang dimaksudkan. Tapi saya pikir aneh bagaimana JC mendekati ini. Apakah jc hanya berusaha mendapatkan jawaban yang dia inginkan? Ada banyak pertanyaan di situs ini yang bisa diselesaikan dengan "hanya berbicara dengan mereka, untuk menangis dengan keras". :-)

— James

@ JanHudec: Saya setuju. Saya berpendapat untuk merilis beberapa IP perusahaan kami dalam bentuk perpustakaan GPL, karena itu pada dasarnya tidak berguna bagi pesaing kami dan masih sangat bermanfaat bagi komunitas kami.

— MSalters

Jawaban:

Jika Anda menautkan ke GPL lib maka Anda telah membuat karya turunan dan kode Anda harus GPL - ini berbeda dengan kode L GPL yang secara khusus memungkinkan penautan dinamis dari kode berlisensi berbeda. Pustaka sistem termasuk libc, semuanya LGPL.

Ada juga pengecualian khusus untuk header kernel Linux dan libgcc (perpustakaan secara implisit dipanggil oleh kompiler).

— Martin Beckett
sumber

Tidak ada libc adalah LGPL - Anda diizinkan untuk menautkan ke program LGPL. Ada juga pengecualian umum untuk panggilan sistem / kernel sehingga tidak ada argumen tentang apa itu panggilan sistem vs pustaka

— Martin Beckett

LGPL bukan lisensi baru, ini pertama kali dirilis pada tahun 1991. libc selalu menjadi LGPL.

— FigBug

@ john-charles - itu sebabnya LGPL ditemukan kembali pada tahun 1991 dengan gplv2. AsLinux (dan yang lainnya kernel FOSS) menjadi populer - dan itulah sebabnya awalnya disebut Library-GPL - ada kekhawatiran bahwa akan ada libc libc oleh setiap vendor kompiler jika aplikasi komersial tidak dapat menggunakan gcc.

— Martin Beckett

@ MartinBeckett Ini adalah pendapat FSF (Anda tidak dapat menautkan ke kode GPLd jika Anda tidak melisensikan milik Anda di bawah GPL), namun itu tidak perlu dipersoalkan lagi. Belum ada gugatan besar (yang saya tahu, jika saya salah, mohon koreksi saya) untuk mengonfirmasi pendapat FSF tentang penautan.

— K.Steff

@ john-charles - ya semua hukum umum diuji di pengadilan, tetapi ada cukup banyak kasus hukum tentang hak cipta. Jika saya mengklaim bahwa salinan DVD Batman saya yang tidak dimodifikasi bukanlah karya turunan dan karenanya saya dapat menjual sebanyak yang saya inginkan - MPAA sepertinya tidak akan setuju! GNU copyleft menggunakan hak cipta untuk menegakkan perjanjian lisensi dengan cara yang cukup cerdik - salah satu alasan mengapa ia tidak pernah diuji di pengadilan adalah bahwa setiap orang selalu menyelesaikannya

— Martin Beckett

Dalam kasus umum, Anda benar karena Anda tidak dapat menautkan ke perpustakaan GPL, mendistribusikan kode Anda, dan kemudian tidak merilis kode Anda sebagai GPL.

Namun, ada System Library Exception yang merupakan cara orang terhubung dengan Linux libs dan masih merilis produk mereka di bawah lisensi non-GPL.

Pengecualian lain adalah ketika kedua lisensi tersebut kompatibel satu sama lain. Lihatlah halaman lisensi FSF yang kompatibel untuk bacaan lebih lanjut.

Akhirnya, penulis lib GPL dapat membuat pengecualian khusus, seperti untuk penggunaan non-komersial atau hobi.

Sayangnya, ada terlalu banyak potensi untuk memiliki aturan yang keras dan cepat. Tanpa lebih spesifik dalam pertanyaan Anda, jawaban Anda adalah "mungkin tidak bisa, tetapi mungkin Anda bisa."

SLE juga menjawab pertanyaan tentang program yang merupakan pekerjaan turunan dari kompiler karena berisi parser yang dihasilkan oleh kompiler

— Martin Beckett

Tidak, SLE memungkinkan pengembangan kode GPL menggunakan toolchain yang tidak bebas dan runtime standar, misalnya Visual Studio. Itu tidak memungkinkan menghubungkan aplikasi yang tidak bebas dengan perpustakaan GPL.

— Jan Hudec

Output dari program GPL tidak tercakup oleh GPL. Lihat gnu.org/licenses/gpl-faq.html#GPLOutput

— Maximus Minimus

-1

Jawaban singkatnya adalah tidak ada yang benar-benar tahu. (Diskusi ini tentang GPL bukan LGPL.)

GPL memiliki bahasa yang tidak jelas tentang "Karya Derivatif", yang ditafsirkan oleh orang yang berbeda dengan cara yang berbeda. Konsensus tampaknya melanggar tautan statis, tetapi panggilan melalui interupsi sistem (misalnya ke Kernel Linux) tidak. Yang terakhir ini didasarkan terutama pada kenyataan bahwa perusahaan-perusahaan seperti Oracle mengirim di Linux dan belum dituntut - tidak jelas dalam lisensi.

Tautan dinamis tidak jelas, mungkin 70/30 mengatakan itu melanggar. Memanggil program menggunakan panggilan pipa atau prosedur jarak jauh, mungkin 30/70 tidak melanggar, meskipun ini pada dasarnya hal yang sama. Memanggil melalui COM, atau menggunakan Java Jar, sama sekali tidak jelas.

Pada dasarnya, jika ada keraguan, dan Anda tidak menyukai pengacara, maka menjauhlah dari GPL.

— Tuntable
sumber

GPL tidak sepenuhnya samar-samar, dan ada hukum kasus yang dibahas dengan baik seputar pertanyaan tentang apa yang merupakan dan bukan karya turunan. Perbedaan antara antarmuka syscall Linux dan libc adalah bahwa yang pertama diperlukan untuk membuat perangkat lunak yang berfungsi (yang telah ditegaskan sebagai pengecualian terhadap hak cipta) sementara yang terakhir tidak (Anda dapat mengimplementasikan sendiri). Ini tidak ada hubungannya dengan bagaimana operasi dipanggil, yang tidak memiliki relevansi hukum. Saya ANAL, ini bukan nasihat hukum.

— Jules

"70/30 mengatakan itu melanggar" dan "30/70 tidak melanggar" - apakah disengaja bahwa rasio pelanggaran / tidak melanggar adalah sama? "Meskipun ini pada dasarnya hal yang sama" menunjukkan bahwa itu dimaksudkan untuk berbeda.

— Mateusz Konieczny