Lisensi LGPL di Produk Tertutup: Kasus FFmpeg

LGPL adalah lisensi sumber terbuka yang memungkinkan pustaka dipakai dalam produk tertutup dengan kewajiban tertentu. Salah satunya adalah menyediakan cara bagi pengguna untuk mengganti komponen LGPL. Penautan dinamis (dynamic linking) dapat membantu memenuhi kewajiban itu, tetapi tidak menggantikan kewajiban teks lisensi dan kode sumber.

FFmpeg sering disertakan dalam produk komersial, sehingga berguna sebagai contoh pemeriksaan kepatuhan LGPL. Artikel ini membahas pemeriksaan teknis; keputusan hukum tetap perlu disesuaikan dengan lisensi dan cara distribusi produk.

Tiga kewajiban itu, secara konkret

Saat menyertakan pustaka LGPL dalam produk tertutup, periksa tiga kewajiban berikut sesuai versi lisensi yang berlaku:

1. Sertakan teks lisensinya. Teks LGPL plus pemberitahuan hak cipta ikut bersama produk — folder installer, layar about, direktori licenses/. Sepele, dan tetap jadi langkah yang paling sering dilewati.
2. Jaga komponennya tetap bisa diganti. Pengguna harus bisa menukar pustaka LGPL dengan build mereka sendiri. Dynamic linking adalah mekanisme klasiknya: pustaka dikirim sebagai DLL — berkas pustaka terpisah yang dimuat program saat dijalankan. Kalau avcodec-61.dll ada di sebelah executable-nya, pengguna dapat membangun ulang FFmpeg dan menaruh DLL-nya sendiri. Static linking juga dapat patuh, tetapi membutuhkan jalur relinking—misalnya berkas object dan bahan yang memungkinkan pengguna membangun ulang aplikasi dengan pustaka yang diubah—sesuai versi LGPL yang berlaku.
3. Sediakan kode sumber untuk bagian LGPL-nya. Bukan aplikasinya sendiri — pustaka LGPL-nya sendiri, termasuk kalau ada modifikasi di dalamnya. Cara penyediaannya harus sesuai versi lisensi dan cara distribusi. Daftar pemeriksaan resmi FFmpeg meminta kode sumber yang persis cocok dengan berkas biner, perubahan, serta petunjuk kompilasi. Tautan ke halaman umum proyek asal saja tidak membuktikan kewajiban ini terpenuhi.

Periksa juga ketentuan pengguna akhir. Daftar resmi FFmpeg meminta penghapusan larangan rekayasa balik. Versi LGPL yang berlaku menentukan hak untuk modifikasi dan penelusuran kesalahan.

LGPL dapat mengizinkan aplikasi Anda tetap tertutup selama ketentuannya dipenuhi. Itu inti lisensinya — dan justru karena itu batas-batas di atas layak dipahami persis.

DLL yang bersanding dengan berkas biner tertutup

Pasang paket kendali akses tertutup, sistem manajemen video CCTV, atau platform kios, lalu lihat isi folder programnya. Sering sekali isinya avcodec.dll, avformat.dll, avutil.dll, swscale.dll (FFmpeg) berjajar di sebelah executable yang sepenuhnya tertutup. Susunan itu dapat memenuhi lisensi jika semua ketentuan yang berlaku dipenuhi; tiga pemeriksaan tadi adalah titik awal. Praktiknya, teks lisensi sering tidak ada, dan permintaan kode sumber FFmpeg yang sesuai ke vendor biasanya tidak pernah dibalas.

Ada satu detail yang sering kelewat dan membuat risikonya berlipat: lisensi FFmpeg tergantung cara hasil kompilasinya. Hasil kompilasi bawaan itu LGPL; begitu dikonfigurasi dengan --enable-gpl (untuk x264 dan komponen terkait), seluruh hasil kompilasi berubah jadi GPL — lisensi berbeda, dengan kewajiban yang tidak mungkin dipenuhi produk proprietary hanya dengan mengirim DLL. Penanda nonfree membuat hasil kompilasinya sama sekali tak boleh didistribusikan.

Jadi "build FFmpeg mana yang dikirim vendor?" bukan pertanyaan cerewet. Jawabannya menentukan lisensi mana yang benar-benar berlaku.

Ilusi penghubung MIT

Di npm, paket berlisensi MIT dapat hanya menjadi penghubung ke pustaka native berlisensi LGPL. Contohnya paket kontrol kamera berbasis libgphoto2 dan penghubung FFmpeg. Lisensi MIT mencakup kode penghubung JavaScript, sedangkan pustaka yang dimuat memiliki lisensi sendiri.

Pustaka native tetap memakai lisensi LGPL. Kewajiban produk mengikuti cara penautan dan apakah pustaka atau karya gabungan didistribusikan. Pemindai yang hanya membaca package.json tidak bisa melihat ini. Pemeriksaan yang benar: lihat apa yang benar-benar dimuat proses saat runtime — berkas .so dan .dll-nya, bukan manifest-nya. Jebakan ini dan kawan-kawannya saya bahas di lisensi sumber terbuka di perangkat lunak komersial.

Celah vendor menjadi celah integrator

Di sinilah kepatuhan yang tadinya abstrak berubah jadi urusan komersial. Menyertakan SDK vendor dalam paket hasil kerja berarti mendistribusikan ulang komponen yang ikut dikirim — termasuk berkas biner LGPL yang disertakan vendor beserta kewajiban apa pun yang mereka biarkan tak terpenuhi.

Pemeriksaan kepatuhan produk Anda dapat menemukan dokumen lisensi yang tidak disertakan vendor. Integrator yang mendistribusikan ulang komponen tetap perlu memeriksa kewajibannya. Minta pernyataan kepatuhan dan hak redistribusi dalam kontrak pengadaan sebelum SDK menjadi bagian penting arsitektur.

Daftar pemeriksaan integrator

Sebelum serah terima apa pun yang menyertakan native, daftar pemeriksaan saya begini: inventaris setiap .dll dan .so di paket, termasuk yang terbawa SDK vendor. Cek lisensi sebenarnya satu per satu — untuk FFmpeg berarti mencari tahu konfigurasi hasil kompilasinya. Verifikasi tiga kewajiban untuk semua yang LGPL, lalu minta pernyataan tertulis vendor untuk bagian yang belum lengkap.

Pemeriksaan sebelum serah terima membantu mencegah perubahan arsitektur yang mahal setelah masalah lisensi ditemukan. LGPL dapat digunakan secara terencana jika bukti kepatuhannya lengkap. Risiko lisensi lain dibahas dalam AGPL dan visi komputer komersial.

Apa yang perlu diminta dari vendor?

Minta daftar komponen dan versi, konfigurasi FFmpeg, teks lisensi, serta cara mendapatkan kode sumber yang sesuai. Vendor juga perlu menunjukkan bahwa pengguna dapat mengganti bagian LGPL melalui mekanisme yang dipilih. Simpan bukti tersebut bersama paket serah terima.