Memilih Lisensi untuk Produk Sendiri: MIT, Apache, AGPL, atau Closed

Memilih Lisensi untuk Produk Sendiri: MIT, Apache, AGPL, atau Closed

Lisensi adalah keputusan model bisnis yang memakai baju hukum. Putuskan model bisnisnya dulu, dan lisensinya memilih dirinya sendiri.

Artikel sebelumnya membahas lisensi yang dikonsumsi — kewajiban yang dibawa dependency. Artikel ini arah sebaliknya: lisensi apa yang dipasang di kode yang dirilis.

Tim sering salah dengan pola yang sama: pilih lisensi apa pun yang dipakai proyek populer terakhir, lalu setahun kemudian sadar lisensinya tidak cocok dengan cara mereka cari uang. (Catatan standar: ini panduan engineering, bukan nasihat hukum.)

Mulai dari cara kode itu menghasilkan uang

Setiap pertanyaan lisensi menyusut jadi satu: apa yang boleh dilakukan orang asing dengan kode ini, dan apa yang dijual? Cuma ada empat jawaban jujur. Masing-masing memetakan ke satu lisensi.

Kode untuk klien: closed, diatur kontrak

Sebagian besar output konsultan tidak seharusnya membawa lisensi open-source sama sekali. Kode yang dibangun untuk klien berstatus UNLICENSED di package.json, tanpa file LICENSE. Hak yang sebenarnya — siapa pemegang copyright, apa yang boleh dilakukan klien, apa yang boleh dipakai ulang — hidup di perjanjian jasa, tempat seharusnya.

Menempelkan MIT di deliverable klien adalah kesalahan nyata yang pernah saya temukan di repository serahan. Itu memberi seluruh dunia hak yang justru dibayar klien untuk dimiliki eksklusif. Tidak ada klausul kontrak yang bisa menarik kembali apa yang sudah diberikan header lisensi.

Default untuk proyek klien adalah closed. Selain itu harus jadi pengecualian yang disengaja dan didukung kontrak.

MIT atau ISC: saat adopsi adalah produknya

Kalau nilai sebuah kode adalah orang lain membangun di atasnya — SDK untuk sebuah platform, client library untuk sebuah API, contoh integrasi — friksi sekecil apa pun harus disingkirkan. MIT, atau ISC yang fungsinya identik, adalah alatnya.

Tidak ada syarat yang layak diperdebatkan. Langsung lolos approval legal di perusahaan mana pun. Penyebaran maksimal.

Jujurlah soal yang dilepaskan di sini: siapa pun boleh mengomersialkannya, mem-fork-nya, atau menanamnya di produk pesaing, dengan atribusi sebagai satu-satunya jaminan yang tersisa. Untuk API client yang seluruh tujuannya mendorong pemakaian layanan berbayar, pertukaran itu justru pas.

Apache-2.0: kebebasan sama, sikap paten eksplisit

Apache-2.0 adalah MIT dengan dua tambahan yang mulai penting begitu kodenya tidak trivial: patent grant eksplisit dari setiap kontributor, dan klausul retaliasi paten — gugat pengguna atas paten di kode itu, dan lisensinya gugur. Tim legal korporat lebih suka mengonsumsi Apache-2.0 persis karena alasan ini. Untuk proyek yang ingin menarik kontribusi dari perusahaan serius, ini default yang lebih aman.

Rule of thumb yang saya berikan ke klien: MIT untuk tool kecil dan contoh, Apache-2.0 untuk apa pun yang punya kedalaman algoritmik, kontributor luar, atau ambisi adopsi enterprise. Mekanika file NOTICE-nya sedikit lebih berat. Proteksinya sepadan.

AGPL: saat yang di-open-source-kan adalah yang dijual

AGPL-3.0 adalah lisensi untuk satu model bisnis spesifik: produknya terbuka, dan pengecualian komersialnya yang dijual. Bayangkan seperti resep restoran yang dipajang terbuka di dinding dapur — siapa pun boleh masak sendiri di rumah, tapi kalau mau jualan pakai nama dan sistem restorannya, mereka bayar lisensi.

Kewajiban AGPL terpicu bahkan saat software cuma disajikan lewat jaringan. Pesaing tidak bisa mengambil kodenya dan diam-diam menjalankannya sebagai SaaS mereka sendiri — mereka mempublikasikan modifikasinya, atau membeli lisensi komersialnya. Ultralytics menjalankan model ini. Begitu juga Grafana, MinIO, dan separuh dunia infrastruktur modern.

Model ini hanya jalan kalau copyright-nya dipegang penuh. Setiap kontribusi luar butuh contributor agreement yang mengalihkan atau melisensikan hak kembali ke pemilik produk — kalau tidak, kemampuan menjual pengecualiannya hilang. Mekanika lengkapnya layak artikel sendiri: dual licensing dengan AGPL.

Yang bukan tempatnya AGPL: library yang ingin disebarkan luas. Sifat viralnya memang disengaja, dan justru itu yang membuat kode yang mengejar adopsi sulit hidup di bawahnya.

Higiene repo: buat keputusannya terbaca

Keputusan lisensi yang cuma disimpan di kepala tim sama saja tidak pernah dibuat. Tiga artefak membuatnya nyata:

1. Field license di package.json (atau manifest ekosistem yang relevan) — "MIT", "Apache-2.0", "AGPL-3.0-only", atau "UNLICENSED" untuk kode tertutup. Scanner dan registry membaca field ini. Field kosong terbaca "risiko tidak diketahui" di setiap audit.
2. File LICENSE di root repo, berisi teks sebenarnya. Field manifest mendeklarasikan; file-nya yang memberi hak.
3. File NOTICE, dipakai saat mendistribusikan ulang kode pihak ketiga yang mensyaratkan atribusi — terutama dependency Apache-2.0. Pilihan lisensi sendiri tidak pernah menghapus kewajiban yang diwariskan.

Mengaudit portofolio campuran

Siapa pun yang sudah beberapa tahun merilis software memegang campuran: deliverable klien, tool internal, SDK publik, mungkin produk open-core. Auditnya mekanis — susuri setiap repository, pastikan field manifest, file LICENSE, dan model bisnis yang dimaksud saling setuju.

Temuannya bisa ditebak: kode klien yang tidak sengaja membawa lisensi permisif dari template, repo publik tanpa lisensi sama sekali (artinya all rights reserved, jadi tidak ada yang bisa memakai secara legal apa yang ingin dibagikan), dan fork yang lisensi upstream-nya diam-diam hilang. Satu sore beres-beres, dan setiap percakapan due-diligence ke depan jadi lebih singkat.

Intinya

Closed dan diatur kontrak untuk proyek klien. MIT atau ISC saat adopsi adalah tujuannya. Apache-2.0 begitu paten atau kontributor korporat masuk hitungan. AGPL plus lisensi komersial saat produknya sendiri yang dijual.

Pilih berdasarkan model bisnis. Tuliskan di manifest dan file LICENSE. Lapisan hukumnya tetap membosankan — pujian tertinggi yang bisa diterima sebuah lapisan hukum.