Dual Licensing dari Sisi Vendor: Satu Produk, Dua Pintu

Dual Licensing dari Sisi Vendor: Satu Produk, Dua Pintu

Dual licensing itu satu produk dengan dua pintu masuk: gratis asal semua turunannya ikut buka kode, atau berbayar tanpa syarat itu. Salah satu produk operasional yang saya maintain pakai model ini: lisensi terbuka AGPL-3.0 di file LICENSE, lisensi komersial berbayar ditawarkan di sebelahnya. Modelnya lebih kecil dan lebih membosankan dari dugaan kebanyakan founder. Justru itu bagusnya.

Saya sudah pernah menulis tentang lisensi open-source dari sisi konsumen: kewajiban yang muncul saat kode orang lain ikut terkirim di produk sendiri. Ini sisi satunya — membangun produknya sendiri, merilisnya sebagai open source, lalu ingin bisnis yang mengambil untung darinya ikut membayar.

Kenapa AGPL adalah copyleft-nya vendor

Copyleft itu keluarga lisensi yang mewajibkan turunan kode ikut terbuka. Lisensi permisif seperti MIT kebalikannya: bebas dipakai untuk apa saja, tanpa kewajiban itu.

Kalau produk serius dirilis di bawah MIT, risiko terbesarnya bukan produknya tidak dikenal. Risikonya: perusahaan hosting mengambil kode itu, menjalankannya sebagai SaaS tertutup, tidak menyumbang apa pun, lalu berjualan lebih laris di atas karya Anda.

GPL juga tidak menghentikan mereka. Kewajiban GPL terpicu oleh distribusi, dan SaaS tidak pernah mendistribusikan apa pun. Software-nya jalan di server mereka; pengguna cuma menyentuh browser.

AGPL menutup celah itu. Begitu software disajikan lewat jaringan, kewajiban berbagi source-nya sama seperti kalau software itu dikirimkan. Bagi siapa pun yang bersedia menjaga turunannya tetap terbuka, produk itu benar-benar gratis.

Bagi yang ingin menanamnya ke sesuatu yang tertutup — integrasi proprietary, fork internal yang tidak akan dipublikasikan, SaaS yang kodenya rahasia — AGPL adalah tembok. Lisensi komersial adalah pintu di tembok itu, dan pintunya ada harganya.

Itulah seluruh model bisnisnya. Lisensi membagi pengguna jadi dua kelompok yang sama-sama jujur, dan hanya kelompok yang mengambil nilai komersial secara tertutup yang membayar.

Mekanismenya: dua file, bukan departemen hukum

Implementasinya sengaja dibikin biasa-biasa saja. Repository membawa teks AGPL-3.0 utuh tanpa modifikasi di LICENSE. Jangan pernah pakai copyleft racikan sendiri — pengacara di kedua sisi langsung waswas.

Di sebelahnya ada COMMERCIAL.md, satu halaman yang menyatakan tiga hal: produk ini AGPL untuk penggunaan terbuka; lisensi komersial tanpa kewajiban AGPL tersedia untuk integrasi proprietary, deployment closed-source, dan produk SaaS; dan ini kontaknya, mohon jelaskan use case serta rencana deployment.

File itu sengaja dijaga pendek — justru di situ intinya. Tugasnya memulai percakapan, bukan menjadi kontrak. Cakupan, harga, dan syarat tempatnya di perjanjian yang benar-benar ditandatangani, disesuaikan dengan cara pembeli men-deploy.

Disiplin NOTICE: dependency Anda sendiri

Begitu Anda menjual lisensi, kepatuhan Anda sendiri ikut disorot. Vendor yang memonetisasi copyleft sambil mengabaikan copyleft di pohon dependency-nya sendiri tidak punya muka untuk menagih orang lain.

Produk yang saya maintain bergantung pada library LGPL — python-telegram-bot di bawah LGPL-3.0, paramiko di bawah LGPL-2.1 — di samping stack permisif biasa. Maka repository-nya membawa file NOTICE: setiap komponen pihak ketiga, baris copyright-nya, lisensinya, URL-nya.

File itu punya dua fungsi sekaligus. Fungsi pertama, memenuhi sisi atribusi dari kewajiban itu. Sisi swappability LGPL — kewajiban memastikan pengguna bisa menukar library itu dengan versi mereka sendiri — adalah topik tersendiri, saya bahas di LGPL dynamic linking di produk vendor.

Fungsi kedua, menjawab pertanyaan pertama tim legal setiap pembeli komersial — "sebenarnya isinya apa saja?" — bahkan sebelum mereka sempat bertanya. Checklist due-diligence yang dijawab dengan file NOTICE yang terawat cenderung jauh lebih pendek.

Yang beneran ditanyakan pembeli komersial

Inquiry yang berujung deal mengikuti pola, dan jawaban yang sudah disiapkan untuk pola itu benar-benar bernilai uang:

1. Scope — lisensinya per instance, per site, atau satu perusahaan? Pilih satuan yang cocok dengan cara produk Anda di-deploy.
2. Coverage — apakah lisensinya mencakup modifikasi mereka? Redistribusi ke klien mereka? Nyatakan eksplisit.
3. Dependency — file NOTICE, plus konfirmasi tidak ada komponen di pohon dependency yang membawa kewajiban yang seharusnya sudah dihapus lisensi komersial.
4. Support dan update — pisahkan grant lisensi dari perjanjian maintenance; umur keduanya berbeda.
5. Warranty dan indemnity — AGPL menyangkal semuanya; pembeli komersial sering membayar justru supaya ada pihak yang bertanggung jawab atas kodenya.

Kontributor menentukan opsi masa depan Anda

Jebakan paling senyap di dual licensing: begitu pull request eksternal di-merge di bawah AGPL saja, kode kontributor itu berlisensi AGPL. Vendor tidak lagi berhak menjual pengecualian komersial yang mencakupnya. Hak istimewa pemegang copyright yang membuat dual licensing berfungsi hanya berlaku untuk kode yang copyright-nya dipegang sendiri.

Opsinya standar: CLA — contributor license agreement, perjanjian yang memberi vendor hak melisensikan ulang kontribusi — atau menjaga kontribusi eksternal di luar core yang di-dual-license. Yang penting, putuskan sebelum PR luar pertama datang. Mengurainya belakangan berarti mengejar tanda tangan orang-orang yang mungkin sudah menghilang.

Intinya

Dual licensing adalah model pendanaan untuk open source, bukan perlawanan terhadapnya. AGPL menjaga produk tetap terbuka dan tak bisa ditunggangi gratis. Lisensi komersial mengubah penggunaan closed-source menjadi pemasukan yang membiayai maintenance.

Mekanismenya muat di tiga file plus satu kebijakan: LICENSE yang bersih, COMMERCIAL.md yang pendek, NOTICE yang terawat, dan keputusan soal kontributor yang diambil di hari pertama.