Lisensi Open-Source di Software Komersial: Mana yang Beneran Berisiko

Lisensi Open-Source di Software Komersial: Mana yang Beneran Berisiko

Setiap codebase komersial yang saya review sebagian besar isinya kode orang lain. Produk Anda adalah lapisan tipis logika bisnis di atas ratusan paket open-source. Masing-masing membawa lisensi — kontrak yang disetujui lewat npm install. Kebanyakan tim tidak pernah membacanya, sampai tim legal klien, checklist due-diligence pihak pengakuisisi, atau email penegakan dari vendor memaksa.

Kabar baiknya: Anda tidak perlu membaca 400 lisensi. Cukup tahu kategori tiap dependency — sama seperti tidak perlu baca perjanjian sewa tiap rumah kontrakan, cukup tahu apakah statusnya sewa, cicilan, atau hak milik. Kategori itu, bukan teks satu per satu, yang menentukan kewajiban Anda. (Catatan standar: ini panduan engineering, bukan nasihat hukum.)

Tiga tingkat risiko

Permisif — MIT, Apache-2.0, BSD, ISC. Bebas dipakai untuk hampir apa pun, asal notice copyright ikut disertakan. Apache-2.0 menambahkan patent grant eksplisit, alasan tim legal korporat menyukainya. Kewajiban praktis: sertakan teks lisensinya di produk. Risiko: nyaris nol.

Copyleft lemah — LGPL, MPL-2.0. Library boleh dipakai di dalam software proprietary, tapi library-nya sendiri harus tetap terbuka dan bisa diganti. Untuk LGPL, klasiknya berarti dynamic linking (library dimuat terpisah saat program jalan): pengguna harus bisa mengganti komponen LGPL dengan build mereka sendiri. Risiko nyata, tapi terkendali selama aturan batasnya dipahami.

Copyleft kuat — GPL, AGPL. Distribusikan software yang memuat kode GPL, maka software Anda wajib GPL juga. AGPL menutup celah SaaS: sekadar menyajikan software lewat jaringan sudah memicu kewajiban berbagi source. Risiko: di sinilah produk komersial paling sering terbakar.

Titik tempat tim beneran kena

Dependency AGPL yang tidak ada yang menandai

Kasus nyata paling umum sekarang ada di computer vision. Ultralytics YOLO — stack object detection default yang dipakai separuh industri — berlisensi AGPL-3.0 dengan opsi lisensi komersial berbayar. Tarik ke produk closed-source dan pilihan patuhnya cuma dua: beli lisensi komersial, atau open-source-kan produk itu di bawah AGPL. Di proyek CV komersial, jawaban praktisnya sering yang ketiga: bangun di atas keluarga model Apache-2.0, dan putuskan itu sebelum arsitektur mengeras, bukan setelah pilot sukses.

Binary LGPL yang bersembunyi di produk vendor

Ekosistem hardware proprietary — access control, CCTV, sistem kiosk — gemar mem-bundle FFmpeg. Buka folder SDK vendor, dan di sana ada avcodec.dll dan avformat.dll duduk di sebelah binary tertutup. Itu kode LGPL di dalam produk proprietary, dan itu boleh selama teks lisensinya ikut, bagian LGPL tetap bisa diganti, dan source bagian itu tersedia. Saat SDK semacam ini terintegrasi ke deliverable, celah kepatuhan vendor ikut menjadi celah kepatuhan Anda.

Ilusi wrapper permisif

Paket npm berlisensi MIT bisa saja cuma wrapper tipis di atas native library LGPL. Lisensi wrapper tidak menjelaskan apa yang sebenarnya di-link. License scanner yang hanya membaca package.json pasti kecolongan — Anda harus melihat apa yang benar-benar dimuat kode saat runtime.

SDK tanpa lisensi sama sekali

Vendor hardware — kontroler vending, pembaca biometrik, SDK kamera — sering mengirim SDK binary tanpa teks lisensi apa pun. Tanpa lisensi bukan berarti "bebas dipakai"; artinya default copyright, all rights reserved, dan hak Anda mendistribusikan ulang di dalam produk secara hukum tidak terdefinisi. Solusinya kontraktual: minta hak redistribusi tertulis di perjanjian pengadaan sebelum SDK itu masuk production.

Triase lima menit

Yang saya periksa sebelum delivery komersial

1. Inventaris semuanya — dependency langsung dan transitif, plus native library dan binary vendor yang tidak pernah muncul di manifest.
2. Tandai yang copyleft dan yang tanpa lisensi — dua kelompok itu tempat semua risiko nyata berada.
3. Periksa apa yang dimuat kode, bukan cuma isi manifest — wrapper dan DLL bundelan adalah titik butanya.
4. Masukkan hak SDK vendor ke kontrak — redistribusi, sublisensi (hak meneruskan lisensi ke pihak berikutnya), dan apa yang terjadi kalau vendornya hilang.

Satu jebakan lagi layak artikel sendiri: di produk AI, lisensi kode, lisensi model weights, dan lisensi dataset adalah tiga hal berbeda — lampu hijau di satu sisi tidak berlaku untuk sisi lain. Itu artikel berikutnya di seri ini.

Untuk bagaimana keputusan lisensi bersinggungan dengan integrasi hardware, lihat normalisasi perangkat IoT multi-protokol — SDK vendor adalah titik temu kedua masalah itu.