Memilih Lisensi Perangkat Lunak: MIT, Apache, atau AGPL

Pilih lisensi perangkat lunak berdasarkan hak yang ingin Anda berikan dan cara bisnis menghasilkan uang. MIT dan Apache-2.0 memudahkan pemakaian ulang; AGPL membawa kewajiban berbagi kode pada kondisi tertentu. Kode khusus klien dapat diatur lewat kontrak tertutup. Periksa juga hak kontributor dan lisensi komponen pihak ketiga sebelum menetapkan pilihan.

Artikel sebelumnya membahas kewajiban lisensi komponen yang digunakan. Artikel ini membahas keputusan dari sisi pembuat: hak apa yang diberikan melalui lisensi kode yang Anda rilis.

Meniru lisensi proyek populer tanpa memeriksa model bisnis dapat menimbulkan masalah ketika produk mulai menghasilkan pendapatan. Pertimbangkan hak penggunaan, distribusi, dan komponen pihak ketiga sebelum menetapkan lisensi.

Mulai dari cara kode itu menghasilkan uang

Mulailah dari pertanyaan: apa yang boleh dilakukan pihak lain dengan kode ini, dan dari mana pendapatannya? Empat pilihan berikut membantu membandingkan kebutuhan tersebut.

Kode untuk klien: tetapkan hak dalam kontrak

Untuk hasil kerja klien yang disepakati tertutup, nyatakan UNLICENSED pada package.json dan jangan menambahkan lisensi sumber terbuka pada kode milik proyek tanpa persetujuan. Hak cipta, penggunaan oleh klien, dan izin penggunaan ulang ditetapkan dalam perjanjian jasa. Komponen pihak ketiga tetap mengikuti lisensinya sendiri.

Menempelkan MIT di hasil kerja klien adalah kesalahan nyata yang pernah saya temukan di repository serahan. Itu memberi seluruh dunia hak yang justru dibayar klien untuk dimiliki eksklusif. Jangan mengandalkan klausul kontrak untuk membatalkan hak yang telah diberikan melalui lisensi.

Untuk pola proyek klien tertutup yang dibahas di sini, penerbitan kode sebagai sumber terbuka perlu menjadi keputusan yang disengaja dan disetujui dalam kontrak.

MIT atau ISC: saat adopsi adalah produknya

Kalau nilai sebuah kode adalah orang lain membangun di atasnya — SDK untuk sebuah platform, pustaka klien untuk sebuah API, contoh integrasi — ketentuan yang singkat dapat memudahkan adopsi. MIT atau ISC menjadi pilihan yang dapat dipertimbangkan.

Kewajibannya relatif singkat, sehingga peninjauan sering lebih mudah. Tetap sertakan pemberitahuan yang diwajibkan dan ikuti kebijakan komponen pihak ketiga milik pembeli.

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

Apache-2.0: periksa pemberian hak paten

Apache-2.0 memiliki ketentuan tersendiri. Dua hal yang perlu diperhatikan ialah pemberian hak paten secara eksplisit dari setiap kontributor, dan ketentuan penghentian izin paten: menurut Pasal 3, izin paten atas karya tersebut berakhir jika Anda mengajukan gugatan paten yang menuduh karya atau kontribusinya melanggar paten. Ketentuan paten ini dapat menjadi pertimbangan tim hukum perusahaan. Untuk proyek yang ingin menarik kontribusi dari perusahaan serius, ini default yang lebih aman.

Pedoman praktis yang saya berikan kepada klien: MIT untuk tool kecil dan contoh, Apache-2.0 untuk apa pun yang punya kedalaman algoritmik, kontributor luar, atau ambisi penggunaan oleh perusahaan besar. Ketentuan berkas NOTICE memerlukan pemeriksaan tambahan, sepadan dengan perlindungan yang dibutuhkan.

AGPL dan lisensi komersial untuk produk terbuka

Salah satu model bisnis yang dapat menggunakan AGPL-3.0 ialah produknya terbuka, dan pengecualian komersialnya yang dijual. Lisensi komersial memberikan syarat berbeda kepada pembeli yang tidak dapat atau tidak ingin memenuhi AGPL.

Untuk versi yang dimodifikasi dan diakses lewat jaringan, Pasal 13 mewajibkan tawaran Corresponding Source, yaitu kode sumber yang diperlukan untuk versi tersebut, kepada pengguna itu. Distribusi memiliki kewajiban tersendiri. Penggunaan komersial tetap diperbolehkan oleh AGPL; kebutuhan izin berbayar bergantung pada kewajiban yang tidak dapat dipenuhi. Periksa cakupan karya gabungan, jangan menganggap semua layanan terpisah harus dibuka.

Penawaran lisensi komersial memerlukan hak yang memadai atas kode produk. Untuk kontribusi luar, gunakan perjanjian kontributor yang mengalihkan atau memberikan hak pelisensian yang diperlukan kepada pemilik produk. Mekanika lengkapnya layak artikel sendiri: dual licensing dengan AGPL.

Untuk pustaka yang ingin digunakan luas dalam produk tertutup, kewajiban AGPL dapat membatasi pilihan pengguna. Bandingkan kebutuhan adopsi dengan tujuan menjaga keterbukaan karya turunannya.

Nyatakan keputusan dalam berkas repositori

Catat keputusan lisensi agar pengembang berikutnya dan pembeli dapat memeriksanya. Gunakan tiga tempat berikut:

1. Kolom license di package.json (atau manifest ekosistem yang relevan) — "MIT", "Apache-2.0", "AGPL-3.0-only", atau "UNLICENSED" untuk kode tertutup. Pemindai dan registri membaca kolom ini. Kolom kosong terbaca "risiko tidak diketahui" di setiap audit.
2. Berkas LICENSE di akar repositori untuk kode sumber terbuka, berisi teks lisensi sebenarnya. Untuk kode tertutup, dokumentasikan hak yang dicadangkan dan ketentuan kontrak.
3. Berkas NOTICE, dipakai saat mendistribusikan ulang kode pihak ketiga yang mensyaratkan atribusi — terutama komponen Apache-2.0. Pilihan lisensi sendiri tidak pernah menghapus kewajiban yang diwariskan.

Mengaudit portofolio campuran

Siapa pun yang sudah beberapa tahun merilis perangkat lunak memegang campuran: hasil kerja klien, alat internal, SDK publik, mungkin produk open-core, dengan bagian terbuka dan komersial. Periksa setiap repositori dan cocokkan kolom lisensi dalam manifes, berkas LICENSE, serta model bisnis yang dimaksud.

Temuannya bisa ditebak: kode klien yang tidak sengaja membawa lisensi permisif dari templat, repo publik tanpa lisensi sama sekali (artinya seluruh hak dilindungi, 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 pemeriksaan bisnis ke depan jadi lebih singkat.

Cocokkan hak yang diberikan dengan model bisnis

Gunakan pengaturan tertutup dan kontrak untuk proyek klien yang memerlukannya. 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 manifes dan berkas LICENSE. Keputusan yang jelas memudahkan pemeriksaan hak dan kewajiban pada rilis berikutnya.