Apakah ada celah dalam GPL yang memungkinkan perangkat lunak berpemilik untuk dihubungkan dengan perpustakaan GPL?

Mari kita periksa skenario hipotetis:

Perusahaan X menulis program berpemilik (A) yang secara dinamis terhubung dengan perpustakaan berpemilik (B). Perusahaan Y ingin menggunakan perpustakaan pengganti (C) yang dilisensikan di bawah GPL, dan menulis perpustakaan pembungkus (D) yang secara dinamis menghubungkan ke A dan C dan menerjemahkan panggilan API yang digunakan oleh A ke panggilan API yang digunakan oleh C.

Karena D dimaksudkan untuk digunakan dengan C, dan menggunakan panggilan API C, itu adalah karya turunan dari C dan karenanya harus didistribusikan berdasarkan ketentuan GPL *. Akibatnya, kerja gabungan A dan D juga harus didistribusikan berdasarkan ketentuan GPL, yang tidak mungkin diberikan bahwa Perusahaan Y tidak memiliki kode sumber untuk A. Yang mengatakan, selama Perusahaan Y mendistribusikan D dengan sendirinya , tidak ada masalah. Namun, terlepas dari tindakan Perusahaan Y, Perusahaan X tidak melanggar GPL dengan mendistribusikan A, bahkan tanpa B. Keberadaan D tidak berarti bahwa A tiba-tiba merupakan karya turunan dari C (melalui D) yang harus dilisensikan di bawah GPL juga.

Sekarang inilah celahnya: tidak ada yang menghentikan Perusahaan X untuk menulis versi D-nya sendiri, mendistribusikannya secara terpisah dari A, dan memberi tahu pengguna akhir untuk menggunakan D alih-alih B saat menjalankan A. Tampaknya perusahaan mampu merancang program berpemilik untuk menggunakan pustaka GPL tanpa melanggar GPL, selama modul pembungkus digunakan untuk mengisolasi program berpemilik dari pustaka GPL dan modul itu didistribusikan secara terpisah.

Apakah saya benar dalam alasan saya? Apakah ini celah nyata di GPL?

* D juga merupakan karya turunan dari A, tetapi untuk tujuan skenario ini, Perusahaan X telah secara eksplisit mengizinkan pembuatan D dan mengizinkannya untuk dilisensikan di bawah GPL.

IANAL, tapi ini pendapat saya tentang apa yang diperbolehkan dalam batas-batas GPL:

• mendistribusikan karya gabungan "A - B" di depan umum: baik, dapat dilakukan di bawah lisensi kepemilikan apa pun

• buat pembungkus lib D untuk C oleh Y: baik, ini tidak berarti bahwa A harus diletakkan di bawah GPL

• gunakan produk gabungan "A - D - C" secara internal oleh Y: juga baik, GPL tidak perlu membuka sumber A selama kombinasi tersebut tidak didistribusikan ke publik

• mendistribusikan karya gabungan "A - D - C" di depan umum: ini membutuhkan A untuk bersumber terbuka dan diletakkan di bawah GPL (dan tidak masalah jika X atau Y mendistribusikan kombinasi ini; selain itu, jika Y ingin melakukan ini, mereka akan memerlukan lisensi distribusi untuk A dari X, tentu saja)

Pertanyaan yang menarik sekarang adalah: dapatkah D&C didistribusikan secara terpisah sebagai sumber terbuka di bawah GPL, A&B (atau hanya A tanpa B) didistribusikan di bawah lisensi kepemilikan, dan pengguna akhir menggantikan B oleh D&C sendiri?

Di sini modifikasi terakhir menjadi "AB" yang membuat A bergantung pada libs D & C dilakukan oleh pengguna akhir - setelah distribusi . Jadi orang dapat berargumen bahwa modifikasi akhir hanya dilakukan secara internal oleh pengguna akhir. Dan tampaknya ini memang mungkin dilakukan tanpa melanggar GPL - dan yang Anda dapatkan adalah kombinasi kerja "AC&D" di mana A berada di bawah lisensi hak milik dan C&D di bawah GPL.

Tentu saja, seorang pengacara atau hakim mungkin memiliki pendapat berbeda tentang hal itu. Untuk mendapatkan jawaban terakhir, saya pikir Anda harus menunggu sampai seseorang mencobanya dan yang kedua menggugatnya.

Saya kira untuk sebagian besar sistem, akan sulit untuk membuat rasi bintang seperti itu tanpa merancang "A" dari awal dengan cara sehingga akan bekerja dengan baik dengan B atau C. Dan dalam kasus ini, orang dapat curiga bahwa A entah bagaimana berasal dari C.

EDIT: berpikir sebentar tentang ini, situasi yang sama muncul dalam pikiran saya: menulis dan mendistribusikan plugin berlisensi GPL untuk aplikasi sumber tertutup. Mari kita ambil contoh, Photoshop. Saya tidak berpikir seseorang akan secara serius mencoba untuk menegakkan Adobe ke open-source Photoshop hanya karena ada beberapa plugin GPL dari vendor pihak ketiga. Di sini, bahkan "lib wrapper" tidak diperlukan karena ada antarmuka yang jelas. Namun, apakah itu akan mengubah situasi jika Photoshop akan menggabungkan beberapa fungsi utamanya dari plug-in pihak ketiga GPL? Saya pikir untuk kasus seperti itu mungkin menjadi sangat sulit untuk memutuskan di mana menarik garis, pada titik mana produk sumber tertutup adalah pekerjaan "berdasarkan" lib GPL.

EDIT2: Ada lib lisensi ganda yang tersedia, dengan lisensi GPL untuk penggunaan non-komersial dan lisensi eksklusif untuk penggunaan komersial seperti ini, misalnya. Jadi "celah" Anda berarti mengembangkan produk berdasarkan lib tersebut (menggunakan versi komersial, sehingga GPL tidak berlaku untuk produk Anda), kirimkan produk Anda sebagai sumber tertutup tanpa lib ke publik dan biarkan akhir- pengguna mendapatkan dan menginstal versi GPL sendiri. Untuk kasus seperti itu, saya kira penjual lib akan memiliki peluang bagus untuk berhasil menuntut Anda atas pelanggaran lisensi (jika Anda tidak membayar libnya, tentu saja). Apakah ini sepadan dengan kerumitan? Mungkin tidak. Terutama dalam contoh yang saya tautkan, Anda harus membeli lib juga, karena harga tidak bergantung pada seberapa sering Anda menjual produk Anda, tetapi hanya berapa banyak pengembang yang menggunakan lib selama pengembangan.

Akhirnya, karena risiko hukum itu, jika saya berniat untuk menggunakan lib sumber terbuka dalam produk sumber tertutup, saya akan menghindari lib GPL jika memungkinkan, dan tidak mencoba memanfaatkan "celah" ini. LGPL atau GPL dengan menghubungkan pengecualian jauh lebih aman, atau segala jenis lisensi OS non-viral.

Contoh praktis adalah driver grafis berpemilik untuk Linux yang harus diinstal sendiri oleh pengguna akhir. Yang penting bagi pencipta driver berpemilik, jika pengguna akhir mendistribusikan karya gabungan, yang menciptakan kewajiban hukum bagi pengguna akhir (yang tidak mungkin mereka penuhi) tetapi bukan pencipta driver.

Jawaban lain mengklaim "karena program tergantung pada perpustakaan itu masih merupakan karya turunan" - tetapi jika program tidak benar-benar berfungsi karena perpustakaan tidak ada, maka itu bukan turunan.

Tetapi pada akhirnya, jika Anda mengandalkan "celah" maka Anda harus mempertimbangkan bahwa pendekatan Anda mungkin bukan yang benar.

Menautkan mendefinisikan turunan oleh GPL. Situasi khusus ini adalah apa yang LGPL dirancang untuk menangani: di mana Anda ingin melepaskan perpustakaan sebagai GPL tetapi mendefinisikan tautan sebagai batas eksplisit dari lisensi yang diterapkan, atau secara bergantian, di mana Anda ingin menautkan terhadap beberapa kode GPL tetapi mengharuskan Anda sendiri pekerjaan dirilis di bawah lisensi non-GPL itu sendiri.

Dalam kasus di mana pengguna akhir akan melakukan penautan (membangun kode sendiri dari sumber non-GPL yang dapat menautkan ke perpustakaan GPL) pengguna akhir tidak secara efektif membuat versi GPL dari apa pun produk akhirnya, karena dia tidak diizinkan untuk mengubah lisensi bagian non-GPL dari proyek karena dia bukan pemiliknya. Ini umumnya menghalangi distribusi oleh pengguna akhir dalam bentuk apa pun, tetapi tidak akan melarang penggunaan.

Yang mengatakan, jika sebuah proyek mengharuskan itu dibangun dari sumber dan hanya didistribusikan dengan cara itu tidak relevan apa lisensi perpustakaan terkait berada di bawah, karena ini sepenuhnya di luar tangan pengembang non-GPL. Yaitu, bagaimana Anda bisa tahu distribusi hanya sumber Anda akan dibangun di atas gcc terhadap glibc VS yang dibangun di atas kompiler IBM melawan libc mereka kecuali jika Anda menentukan ini berdasarkan syarat lisensi Anda sendiri? Hal ini dengan cepat menimbulkan penggunaan yang adil dan larangan terhadap kondisi hukum yang tidak dapat diberlakukan (bukan fantasi yang telah ditulis menjadi undang-undang pada beberapa kesempatan baru-baru ini).

Saya bukan seorang pengacara, tetapi sejauh yang saya tahu Anda tidak benar, karena program ini tergantung pada perpustakaan - itu masih merupakan pekerjaan yang deriviatif. Cara yang sama bahwa sequal adalah karya deriviatif. Minimal itu didasarkan pada API yang ditentukan di perpustakaan.