Career
Lisensi Open Source Dijelaskan: MIT, Apache 2.0, dan GPL untuk Developer
Mei 20269 menit baca
Career
MIT dan Apache 2.0 sama-sama merupakan lisensi permisif yang mengizinkan penggunaan komersial dan modifikasi, tetapi Apache 2.0 menambahkan pemberian paten eksplisit — kontributor memberikan lisensi paten mereka kepada pengguna, sehingga Anda terlindungi dari tuntutan hukum paten oleh kontributor. Jika adopsi enterprise dan perlindungan kekayaan intelektual penting bagi proyek Anda, pilih Apache 2.0; jika Anda menginginkan lisensi sesederhana mungkin dengan adopsi maksimal (seperti React atau Next.js), MIT adalah pilihan default yang tepat.
Copyleft berarti perangkat lunak apa pun yang menggabungkan kode berlisensi GPL juga harus dirilis di bawah GPL — inilah yang disebut efek 'viral'. Untuk proyek komersial, ini sangat krusial: jika Anda tidak sengaja menyertakan dependensi GPL dalam kodebase Anda, seluruh proyek mungkin harus dibuat open-source di bawah GPL. Alat seperti license-checker (npm) atau FOSSA dapat memindai pohon dependensi Anda dan menandai ketidakcocokan ini sebelum menjadi masalah hukum.
AGPL menutup 'celah SaaS' — tidak seperti GPL, AGPL mengharuskan perangkat lunak yang berjalan melalui jaringan (bukan didistribusikan) untuk tetap menyediakan kode sumber kepada pengguna. Ini menjadikannya pilihan yang disengaja bagi perusahaan seperti MongoDB dan Grafana yang ingin mencegah penyedia cloud menawarkan perangkat lunak mereka sebagai layanan managed tanpa berkontribusi balik. Sebagian besar perusahaan menghindari AGPL karena tim hukum menandainya sebagai tidak kompatibel dengan produk komersial, jadi gunakan secara sengaja hanya jika strategi Anda adalah dual licensing untuk monetisasi.
Anda harus selalu memeriksa lisensi semua dependensi sebelum memilih lisensi untuk proyek Anda sendiri. Alat seperti license-checker (npm) atau FOSSA dapat memindai seluruh pohon dependensi dan menandai ketidakcocokan — misalnya, kode GPL tidak dapat digunakan dalam proyek berlisensi MIT. Hal ini paling penting untuk proyek komersial, di mana lisensi yang tidak kompatibel secara tidak sengaja dalam pohon dependensi dapat menimbulkan masalah hukum bagi pelanggan enterprise.
Selain memilih lisensi, pengelola sebaiknya menambahkan file CONTRIBUTORS dan panduan kontribusi yang jelas, menyertakan CODE_OF_CONDUCT untuk mengatur ekspektasi komunitas, serta memperbarui package.json atau pyproject.toml dengan pengenal lisensi SPDX yang benar agar dikenali oleh manajer paket dan pemindai lisensi. Pertimbangkan CLA (Contributor License Agreement) jika Anda mungkin ingin mengubah lisensi di kemudian hari — tanpa CLA, persetujuan setiap kontributor diperlukan untuk perubahan lisensi. Situs choosealicense.com dari GitHub membuat proses pemilihan dapat dipahami oleh non-pengacara.
Data Open Source Initiative tahun 2025 menunjukkan MIT dan Apache 2.0 mendominasi lanskap open-source, dengan lisensi permisif menyumbang sebagian besar minat developer. MIT memimpin secara signifikan, dengan Apache 2.0 menarik 344.000 penayangan halaman — mencerminkan preferensi developer untuk lisensi dengan pembatasan minimal. Tetapi lisensi yang paling populer belum tentu yang tepat untuk proyek Anda. Lisensi yang Anda pilih menentukan bagaimana orang lain dapat menggunakan kode Anda, apakah penggunaan komersial diizinkan, apa yang terjadi ketika seseorang memodifikasinya, dan apakah proyek Anda dapat digunakan dalam perangkat lunak enterprise.
Lisensi open-source terbagi menjadi dua keluarga besar: permisif (pembatasan minimal — MIT, Apache 2.0, BSD) dan copyleft (persyaratan berbagi timbal balik — GPL, LGPL, AGPL). Lisensi permisif mengatakan 'lakukan apa pun yang Anda inginkan dengan kode ini, cukup kredit saya.' Lisensi copyleft mengatakan 'Anda dapat menggunakan dan memodifikasi ini, tetapi perangkat lunak apa pun yang menyertakan kode saya juga harus menjadi open source di bawah ketentuan yang sama.'
MIT adalah lisensi open-source mainstream yang paling permisif. Persyaratan: simpan pemberitahuan hak cipta dan teks lisensi dalam setiap distribusi. Itu saja. Pengguna dapat: menggunakan perangkat lunak secara komersial, memodifikasinya, mendistribusikan versi yang dimodifikasi, dan mensublisensikannya. Kesederhanaan MIT adalah kekuatannya — perusahaan dapat mengadopsi kode berlisensi MIT tanpa tinjauan hukum, itulah mengapa framework seperti Next.js, React, dan sebagian besar paket npm menggunakan MIT.
Open Source License Decision Tree (2025)
Start: What is your goal?
│
┌──────────────┼──────────────┐
│ │ │
Max adoption Enterprise/ Keep it open
minimal fuss patent safe (derivatives too)
│ │ │
MIT Apache 2.0 GPL v3
│ │ │
"Do whatever, "Do whatever + "Any derivative
keep copyright" patent grant" must be GPL"
│ │ │
Next.js, React Kubernetes, Linux kernel,
Most npm pkgs TensorFlow GNU tools
─────────────────────────────────────────────────────
Library that companies will use → LGPL
(can link to LGPL lib without making their code GPL)
SaaS with open source + commercial tier → AGPL
(forces cloud providers to contribute back)
─────────────────────────────────────────────────────
License Popularity (OSI 2025 pageviews):
MIT: ████████████████████████ #1 by far
Apache 2.0: ████████████ 344K views
BSD 3-Clause: ████████ 214K views
GPL-2.0/3.0: █████ 130K views combinedDari membangun proyek yang menggunakan pustaka open-source: selalu periksa lisensi dependensi Anda sebelum memilih lisensi untuk proyek Anda sendiri. Jika Anda menggunakan pustaka GPL dalam proyek Anda, proyek Anda mungkin perlu menjadi GPL juga (efek viral). Alat seperti license-checker (npm) atau FOSSA dapat memindai pohon dependensi Anda dan menandai ketidakcocokan lisensi.
Apache 2.0 kompatibel dengan MIT tetapi menambahkan pemberian paten eksplisit — kontributor untuk proyek Apache 2.0 memberikan pengguna lisensi paten untuk kode yang mereka kontribusikan. Ini berarti menggunakan kode Apache 2.0 tidak mengekspos Anda pada tuntutan hukum paten dari kontributor. Itulah mengapa organisasi besar lebih menyukai Apache 2.0 untuk proyek yang mereka kontribusikan. Kubernetes, TensorFlow, dan sebagian besar proyek Apache Foundation menggunakan Apache 2.0.
# Check all dependency licenses in your Node.js project
npm install -g license-checker
license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC'
# Exits non-zero if any dep uses a disallowed license
# package.json — SPDX identifier (machine-readable)
{
"name": "my-erp-module",
"version": "1.0.0",
"license": "MIT", # ← SPDX identifier, not plain text
...
}
# MIT License text (add as LICENSE file in repo root)
MIT License
Copyright (c) 2025 Matthews Wong
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...GPL (GNU General Public License) mengharuskan perangkat lunak apa pun yang menggabungkan kode GPL juga harus dirilis di bawah GPL. Ini adalah properti copyleft atau 'viral' — itu memastikan turunan dari perangkat lunak open-source tetap open source. LGPL (Lesser GPL) adalah varian yang lebih lemah — Anda dapat menautkan ke pustaka LGPL dalam proyek proprietary tanpa membuat proyek Anda GPL. AGPL (Affero GPL) menutup 'celah SaaS' — perangkat lunak yang berjalan melalui jaringan harus tetap menyediakan kode sumber ke pengguna.
AGPL adalah pilihan lisensi untuk perusahaan yang ingin menawarkan lisensi komersial di samping lisensi open-source (dual licensing). MongoDB, Grafana, dan Elastic menggunakan lisensi yang berdekatan dengan AGPL khusus untuk mencegah penyedia cloud menawarkan perangkat lunak mereka sebagai layanan managed tanpa berkontribusi balik. Jika Anda memilih AGPL untuk pustaka, sebagian besar perusahaan akan menghindari menggunakannya karena tim hukum mereka akan menandainya sebagai tidak kompatibel dengan produk komersial mereka.
Tidak semua lisensi kompatibel satu sama lain. MIT dan Apache 2.0 umumnya kompatibel — Anda dapat menggunakan keduanya dalam proyek yang sama dan merilis di bawah keduanya. MIT dan GPL kompatibel satu arah: Anda dapat menggunakan kode MIT dalam proyek GPL (GPL menyerap MIT), tetapi Anda tidak dapat menggunakan kode GPL dalam proyek MIT. Apache 2.0 dan GPL v2 memiliki ketidakcocokan halus — FSF merekomendasikan GPL v3 untuk kompatibilitas Apache 2.0.
Kerangka keputusan: (1) Adopsi maksimal, proyek sederhana → MIT. (2) Adopsi enterprise, perlindungan IP penting → Apache 2.0. (3) Ingin turunan tetap open source, tidak ada kekhawatiran batasan komersial → GPL v3. (4) Pustaka yang harus dapat digunakan oleh proyek komersial tanpa kepatuhan GPL → LGPL. (5) Produk SaaS yang Anda buat open-source sambil mencegah hosting cloud gratis → AGPL. (6) Tidak yakin → MIT.
Di luar pilihan lisensi: tambahkan file CONTRIBUTORS dan panduan kontribusi yang jelas jika Anda menginginkan kontribusi eksternal; pertimbangkan CLA (Contributor License Agreement) jika Anda mungkin ingin mengubah lisensi kemudian; perbarui package.json, pyproject.toml, atau setara dengan pengenal lisensi SPDX yang benar sehingga manajer paket dan pemindai lisensi mengambilnya dengan benar. Alat seperti choosealicense.com (dari GitHub) membuat proses pemilihan dapat dibaca oleh non-pengacara.