Lisensi LGPL di Produk Tertutup: Kasus FFmpeg

Lisensi LGPL di Produk Tertutup: Kasus FFmpeg

LGPL adalah lisensi open-source yang "setengah longgar": library berlisensi ini boleh dipakai di dalam produk tertutup (proprietary), asal library-nya sendiri tetap bisa diganti oleh pengguna. Banyak orang merasa paham aturannya — "aman asal link-nya dinamis" — dan kalimat itu kurang-lebih benar, tapi sama sekali tidak cukup. Kewajibannya konkret, bisa diperiksa, dan di produk komersial yang beredar sering cuma dipenuhi setengah — siapa pun yang pernah membuka folder SDK vendor pasti pernah melihat buktinya.

FFmpeg adalah codebase LGPL yang paling sering di-bundle sedunia — contoh paling pas untuk membedahnya. (Catatan standar: panduan engineering, bukan nasihat hukum.)

Tiga kewajiban itu, secara konkret

Bayangkan meminjam obeng dari tetangga: boleh dipakai untuk proyek yang sedang dikerjakan, tapi obengnya harus tetap bisa dikembalikan dan diganti kapan saja. Itulah semangat LGPL. Mengirim library LGPL di dalam produk proprietary menimbulkan tiga kewajiban:

1. Sertakan teks lisensinya. Teks LGPL plus notice copyright 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 library LGPL dengan build mereka sendiri. Dynamic linking adalah mekanisme klasiknya: library dikirim sebagai DLL — file library terpisah yang dimuat program saat dijalankan. Kalau avcodec-61.dll ada di sebelah executable-nya, pengguna bisa rebuild FFmpeg dan menaruh DLL-nya sendiri. Begitu kode itu di-static-link ke binary, argumen replaceability runtuh — dan kepatuhannya ikut runtuh.
3. Sediakan source untuk bagian LGPL-nya. Bukan aplikasinya sendiri — library LGPL-nya sendiri, termasuk kalau ada modifikasi di dalamnya. Pakai upstream tanpa modifikasi? Penawaran tertulis, atau tautan stabil ke source yang persis sama dengan build-nya, sudah cukup.

Yang tidak dituntut LGPL adalah membuka aplikasinya sendiri. Itu inti lisensinya — dan justru karena itu batas-batas di atas layak dipahami persis.

DLL yang bersanding dengan binary tertutup

Install suite access control proprietary, video management system CCTV, atau platform kiosk, 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 sepenuhnya legal — selama tiga kewajiban tadi dipenuhi. Praktiknya, teks lisensi sering tidak ada, dan permintaan source FFmpeg yang sesuai ke vendor biasanya tidak pernah dibalas.

Ada satu detail yang sering kelewat dan bikin risikonya berlipat: lisensi FFmpeg tergantung cara build-nya. Build default itu LGPL; begitu dikonfigurasi dengan --enable-gpl (untuk x264 dan kawan-kawan), seluruh build berubah jadi GPL — lisensi berbeda, dengan kewajiban yang tidak mungkin dipenuhi produk proprietary cuma dengan mengirim DLL. Flag nonfree membuat build-nya sama sekali tak boleh didistribusikan.

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

Ilusi wrapper MIT

Ekosistem npm menambah satu jebakan lagi. Sebuah paket bisa berlisensi MIT, tampak bersih di semua license scanner, dan sebenarnya cuma binding tipis di atas native library LGPL. Wrapper kontrol kamera ala libgphoto2 contoh klasiknya, dan paket-paket wrapper FFmpeg sama saja. Lisensi MIT si wrapper hanya mencakup glue code JavaScript-nya, tidak lebih.

Begitu produk memuat native library-nya, LGPL berlaku penuh pada produk itu. Scanner yang membaca package.json tidak bisa melihat ini. Pemeriksaan yang benar: lihat apa yang benar-benar dimuat proses saat runtime — file .so dan .dll-nya, bukan manifest-nya. Jebakan ini dan kawan-kawannya saya bahas di lisensi open-source di software komersial.

Celah vendor menjadi celah integrator

Di sinilah kepatuhan yang tadinya abstrak berubah jadi urusan komersial. Mengintegrasikan SDK vendor ke deliverable berarti mendistribusikan ulang semua isinya — termasuk binary LGPL yang di-bundle vendor beserta kewajiban apa pun yang mereka biarkan tak terpenuhi.

Review due-diligence atas produk Anda yang akan menemukan teks lisensi vendor yang hilang. "Vendornya memang mengirim begitu" tidak bisa jadi pembelaan — integrator sekarang ikut jadi distributor. Saat paling tepat membereskannya adalah saat kontrak: minta pernyataan kepatuhan dan hak redistribusi di perjanjian pengadaan, sebelum SDK-nya terlanjur dilas ke arsitektur produk.

Checklist integrator

Sebelum delivery apa pun yang mem-bundle native code, checklist 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 build-nya. Verifikasi tiga kewajiban untuk semua yang LGPL, lalu minta pernyataan tertulis vendor untuk bagian yang bolong.

Ini kerja satu jam untuk kebanyakan produk. Bandingkan dengan menegosiasi ulang arsitektur setelah surat somasi datang. LGPL adalah copyleft yang terkendali, tapi hanya bagi integrator yang mau meluangkan satu jam itu. Saudaranya yang lebih galak lain cerita — karena itu AGPL dan computer vision komersial dapat artikelnya sendiri.