# Lisensi open source untuk aplikasi bisnis: apa yang diperiksa?

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Komponen yang bisa diunduh gratis tetap dapat memiliki syarat pemakaian dan distribusi. Catat komponen, versi, lisensi, perubahan, dan cara produk diberikan kepada pengguna sebelum memutuskan kewajibannya.

URL kanonis: https://kompli.id/panduan/operasional-digital/lisensi-open-source-untuk-bisnis/
Sumber diakses: 2026-09-28
Diperbarui: 2026-09-28
Penulis: Kompli
Sumber diperiksa: 2026-09-28


## Apakah open source boleh dipakai untuk bisnis?

**Boleh sesuai lisensinya, tetapi gratis diunduh tidak berarti bebas dari kewajiban.** Definisi open source dari Open Source Initiative (OSI) tidak membatasi penggunaan pada bidang usaha tertentu. Izin konkret tetap berasal dari lisensi komponen yang Anda pakai.

Kode yang terlihat di repositori publik belum tentu berlisensi open source. Jika lisensi tidak jelas, minta penjelasan pemegang hak sebelum memasukkannya ke produk. Artikel ini membantu tim membuat daftar pemeriksaan; bukan keputusan hukum tentang gabungan kode tertentu.

## Mulai dari komponen yang benar-benar dikirim

Jangan hanya memeriksa daftar paket yang ditulis pengembang secara langsung. Minta daftar dependensi ikutannya, komponen dalam aplikasi mobile, pustaka antarmuka, gambar, font, dan berkas yang disalin manual. Hak pakai font atau gambar perlu diperiksa tersendiri.

Contoh daftar kerja Kompli untuk produk fiktif:

| Komponen | Cara dipakai | Bukti yang dicatat |
| --- | --- | --- |
| Pustaka tabel versi tertentu | Dikirim ke browser pelanggan | Berkas lisensi dari versi yang dipakai dan lokasi atribusi |
| Mesin laporan yang diubah tim | Berjalan pada server | Perubahan yang dibuat dan syarat lisensi yang perlu dinilai |
| Paket pengujian | Hanya di lingkungan pengembangan | Bukti bahwa paket tidak masuk hasil distribusi |
| Font untuk PDF | Disertakan dalam dokumen keluaran | Izin penyematan dan distribusi font |

Daftar komponen perangkat lunak, atau *software bill of materials* (SBOM), membantu inventaris. Daftar itu sendiri belum membuktikan syarat setiap lisensi telah dipenuhi.

## Apa perbedaan syarat MIT, Apache, dan AGPL?

| Lisensi contoh | Bagian yang perlu dibaca |
| --- | --- |
| MIT | Pemberitahuan hak cipta dan izin perlu disertakan pada salinan atau bagian substansial perangkat lunak |
| Apache 2.0 | Bagian 4 mengatur distribusi, pemberitahuan perubahan, serta pemberitahuan yang dipertahankan; periksa NOTICE jika tersedia. Bagian 3 dan 6 membahas paten dan batas izin merek |
| AGPL 3.0 | Bagian 13 mengatur penawaran kode sumber terkait kepada pengguna yang berinteraksi lewat jaringan dengan versi program yang dimodifikasi |

Tabel ini bukan isi lengkap lisensi. Jangan menyimpulkan seluruh aplikasi wajib dibuka hanya karena ada satu nama lisensi dalam hasil pemindaian. Sebaliknya, jangan menganggap layanan yang hanya berjalan di server selalu bebas dari kewajiban penyediaan sumber. Periksa versi, perubahan, penggabungan, dan cara distribusinya bersama pihak yang memahami lisensi tersebut.

## Contoh keputusan sebelum serah terima

Sebuah software house fiktif akan menyerahkan aplikasi dan paket pemasang kepada klien. Kontrak menyebut “seluruh kode menjadi milik klien”. Namun, aplikasi memuat komponen pihak lain.

Tim membuat tiga kelompok: kode buatan sendiri, komponen pihak ketiga, dan aset berlisensi terpisah. Tim lalu memperbaiki lampiran serah terima agar tidak menjanjikan kepemilikan atas hak pihak lain. Untuk setiap komponen, tim mencatat dasar penggunaan, kewajiban yang sudah dipenuhi, serta persoalan yang masih perlu keputusan.

Jika sebuah komponen belum jelas, pilih tindakan konkret: minta penjelasan lisensi, ganti komponen, atau tahan fitur terkait dari rilis. Jangan menutup catatan hanya dengan kalimat “sudah diperiksa developer”.

## Bukti apa yang diminta dari vendor?

Minta daftar versi yang terpasang, salinan lisensi dari rilis tersebut, catatan perubahan, lokasi pemberitahuan, serta siapa yang menilai kasus meragukan. Cocokkan dengan paket yang benar-benar diserahkan. Hasil pemindai lisensi dapat menjadi petunjuk, tetapi perlu diperiksa jika berkas hilang, hasilnya ambigu, atau paket berisi beberapa lisensi.

Untuk langganan komersial, periksa juga batas pengguna, lingkungan produksi/uji, hak akses afiliasi, perpanjangan, ekspor data, dan penggunaan setelah kontrak berakhir. Jangan menyamakan ketentuan itu dengan izin open source.

Gunakan [checklist lisensi komponen](/template/checklist-lisensi-komponen-aplikasi/) sebelum rilis. Hubungkan hasilnya dengan [proses pengembangan yang aman](/panduan/keamanan/pengembangan-aplikasi-yang-aman/) dan [serah terima aplikasi](/industri/software-house/).
## Sumber rujukan

- [Open Source Initiative — Open Source Definition](https://opensource.org/osd) — Open Source Definition; penggunaan komersial dan syarat lisensi
- [MIT License — teks lisensi](https://opensource.org/license/mit) — Izin dan syarat menyertakan pemberitahuan hak cipta serta izin
- [Apache License 2.0 — teks lisensi](https://opensource.org/license/apache-2.0) — Bagian 3–4 dan 6; paten, distribusi, perubahan, NOTICE dan merek
- [GNU Affero General Public License 3.0 — teks lisensi](https://opensource.org/license/agpl-3.0) — Bagian 13; interaksi jaringan dengan versi program yang dimodifikasi

## Perlu membahas kebutuhan tim Anda?

Ceritakan layanan digital yang Anda kelola dan kebutuhan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=operasional-digital)

## Bacaan terkait

- [Pengembangan aplikasi yang aman: threat modeling sampai rilis](https://kompli.id/panduan/keamanan/pengembangan-aplikasi-yang-aman/)
- [Checklist lisensi komponen sebelum rilis aplikasi](https://kompli.id/template/checklist-lisensi-komponen-aplikasi/)