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


15

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.


1
Jawaban singkat: tidak.
whatsisname

2
Saya semua hanyalah seorang pengacara, tetapi ini adalah pemahaman saya bahwa menghubungkan secara dinamis dengan perpustakaan tidak membuat kode Anda menjadi karya turunan. Kalau tidak, tidak mungkin mendistribusikan apa pun di bawah, katakanlah, lisensi BSD yang secara dinamis terhubung dengan sesuatu yang mungkin di bawah lisensi GPL. Tautan statis adalah cerita yang berbeda, dan tentu saja Anda tidak dapat mendistribusikan kembali pustaka yang terhubung secara dinamis itu sendiri di bawah apa pun kecuali GPL.
Pelaku

4
@tdammers: AFAIK menghubungkan dinamis melakukan kode make karya turunan, dan Anda benar, itu mungkin tidak mungkin untuk mendistribusikan perangkat lunak di bawah lisensi BSD ketika menggunakan GPL libs. Itu sebabnya banyak penulis perpustakaan open source menawarkan lib mereka di bawah LGPL, bukan GPL.
Doc Brown

2
@tdammers: Untuk keperluan skenario ini, saya mengambil pendekatan Stallman untuk menautkan: baik tautan dinamis maupun statis melanggar GPL.
Michael Kourlas

3
@mouviciel Ada keputusan pengadilan yang menunjukkan bahwa mereplikasi API untuk tujuan interoperabilitas adalah sah. Saya percaya ini telah ditemukan secara independen oleh pengadilan tingkat tinggi di AS dan Uni Eropa, sehingga status hukumnya cukup solid (kecuali jika seseorang secara aktif mengubah hukum).
Donal Fellows

Jawaban:


10

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.


2
Perasaan saya mengatakan kepada saya bahwa pengacara akan mulai menyodok lebih keras jika perusahaan yang membuat Ajuga mulai mengiklankan A - C&Dcombo.
Bart van Ingen Schenau

1
@ BartvanIngenSchenau: Saya setuju. Tapi saya bisa membayangkan skenario yang berbeda: X mendistribusikan AB, dan Y hanya mendistribusikan (dan mengiklankan) C & quot add-on "dengan installer yang menggantikan B dalam folder instal AB?
Doc Brown

Saya bisa membayangkan skenario alternatif itu juga, dan akan jauh lebih sulit bagi pengacara untuk membuat lubang jika Adan C&Ddatang dari badan hukum yang berbeda.
Bart van Ingen Schenau

1
@DocBrown: Apakah keberadaan B perpustakaan yang setara bahkan penting? Tidak bisakah perusahaan X menjual A dengan sendirinya dengan asumsi bahwa pengguna akhir harus menemukan perpustakaan yang berfungsi untuk menggunakannya, lalu "dengan nyaman" memberi mereka D?
Michael Kourlas

1
@MichaelKourlas: keberadaan lib B akan membuat jauh lebih sulit bagi vendor C untuk menuntut X, karena itu membuat X lebih mudah untuk membuktikan bahwa A bukanlah "karya turunan" dari C.
Doc Brown

3

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.


Apakah pengguna akhir harus menginstal komponen GPL tidak relevan. Modul kernel eksklusif yang menyertakan pembungkus GPL biasanya mendistribusikan komponen GPL hanya dalam bentuk kode sumber, dan mengharuskan pengguna untuk mengompilasinya. DKMS mengotomatiskan ini. Itu mengambil keuntungan dari "celah" GPL yang berbeda, yaitu Anda dapat melakukan apa pun yang Anda inginkan dengan salinan lokal dari program GPL, selama Anda tidak mendistribusikannya kembali dalam bentuk kode objek. Karena pengguna akhir biasanya tidak mendistribusikan kernel Linux bersama dengan modul kernel berpemilik dan pembungkus GPL yang dikompilasi, mereka umumnya aman.
Clement Cherlin

1

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).


0

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.


Tidak bisakah masalah API diperbaiki dengan memasukkan modul pembungkus yang Anda miliki hak ciptanya? (lihat windyroad.com.au/2006/04/20/... untuk contoh dari apa yang saya bicarakan)
Michael Kourlas

Saya telah memperbarui pertanyaan untuk menambahkan komponen pembungkus.
Michael Kourlas

@ user92103 Apakah FAQ ini menjawab pertanyaan Anda? gnu.org/licenses/gpl-faq.html Atau pertanyaan P.SE ini: programmers.stackexchange.com/questions/50118/…
apsillers

1
@apsillers: Pertanyaan P.SE berkaitan dengan komunikasi client-server melalui jaringan. Sementara itu tentu saja merupakan cara yang mungkin untuk menghindari GPL, itu yang saya bicarakan di sini (tautan dinamis). Saya melihat FAQ GPL, dan mereka memang memiliki pertanyaan yang berhubungan dengan modul wrapper, tetapi pertanyaan itu mengasumsikan distributor bundel perpustakaan GPL dengan aplikasi eksklusif pada titik distribusi. Dalam hal ini, pengguna akhir melakukan bundling, yang mengubah banyak hal secara dramatis.
Michael Kourlas
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.