GitHub kini menyediakan open source license compliance secara umum untuk pelanggan GitHub Enterprise Cloud. Fitur ini menambahkan pemeriksaan lisensi ke alur pull request, sehingga perubahan dependensi dapat dibandingkan dengan kebijakan lisensi yang dibuat organisasi sebelum kode digabungkan.
Pengumuman pada 16 Oktober 2026 menyasar repositori yang memakai GitHub Code Security. Di sana, administrator enterprise dapat membuat kebijakan terpusat tentang lisensi dependensi yang diizinkan, lalu menerapkannya melalui ruleset. GitHub menyebut dukungan ini tersedia juga untuk pelanggan Enterprise Cloud dengan data residency.
Perubahan ini menarik bukan karena GitHub baru menemukan bahwa dependensi memiliki lisensi. Masalahnya adalah skala. Sebuah aplikasi modern bisa membawa banyak paket langsung dan transitive dependencies yang tidak pernah ditulis oleh tim aplikasi sendiri. Ketika daftar itu berubah lewat pull request, pemeriksaan lisensi sering datang terlambat atau tersebar di dokumen dan skrip internal. GitHub mencoba memindahkan sebagian pemeriksaan tersebut ke pintu masuk perubahan kode.
Pemeriksaan terjadi saat pull request berubah
Menurut dokumentasi GitHub, license compliance memanfaatkan data dependency graph untuk mengevaluasi dependensi langsung maupun transitive. Ketika pull request mengubah manifest paket, sistem membandingkan perubahan tersebut dengan kebijakan lisensi yang berlaku. Jika sebuah dependensi memakai lisensi yang tidak diizinkan, pull request dapat diberi anotasi dan—jika ruleset berada dalam mode Active—ditahan sebelum merge.
Organisasi dapat menjalankan ruleset dalam mode Evaluate terlebih dahulu. Mode ini memberi hasil dan anotasi tanpa memblokir penggabungan, sehingga tim bisa melihat seberapa banyak pekerjaan yang muncul sebelum menerapkan penegakan penuh. Dalam mode Active, syarat Require license compliance results before merging membuat pelanggaran menjadi penghalang merge sampai masalahnya diselesaikan.
Penyelesaiannya tidak selalu berarti membuang paket. Tim dapat mengganti dependensi dengan alternatif yang sesuai, memperbarui kebijakan jika lisensinya memang dapat diterima, atau mengajukan pengecualian untuk paket tertentu. GitHub memperkenalkan peran Enterprise Open-Source License Manager untuk orang atau tim yang meninjau permintaan pengecualian tersebut.
Kebijakan pusat, pengecualian tetap terlihat
Model ini memisahkan dua keputusan yang sering tercampur: aturan umum dan kebutuhan sebuah repositori. Enterprise dapat menetapkan baseline di tingkat pusat, sementara repositori atau paket tertentu memperoleh pengecualian melalui proses yang tercatat. Dokumentasi GitHub juga menyebut kebijakan dapat diterapkan di tingkat enterprise, organisasi, dan repositori.
Pemisahan itu penting untuk perusahaan besar. Tanpa kebijakan pusat, setiap tim bisa memiliki daftar lisensi yang berbeda dan cara yang berbeda pula untuk menilai dependensi. Sebaliknya, aturan yang terlalu kaku bisa menghambat proyek yang punya alasan teknis atau legal untuk memakai paket tertentu. Jalur pengecualian memberi ruang untuk keputusan manusia tanpa menghapus jejaknya.
GitHub mengatakan perubahan kebijakan kini menghasilkan audit log event. Ada pula endpoint API baru untuk mengunduh, memperbarui, dan mengganti kebijakan lisensi enterprise, serta endpoint untuk memeriksa apakah daftar paket akan melanggar kebijakan. Bagian terakhir membuka kemungkinan integrasi dengan sistem internal dan coding agent: agen dapat memeriksa kebijakan sebelum menyarankan atau memasukkan paket ke proyek, bukan setelah pull request terlanjur gagal.
SPDX membantu mesin berbicara dengan bahasa yang sama
GitHub mendukung pemilihan lisensi dari daftar bawaan maupun input manual menggunakan SPDX license identifier. SPDX memang dirancang untuk memberi nama singkat dan standar pada lisensi, misalnya MIT, Apache-2.0, atau GPL-2.0-or-later. Identifier tersebut bukan pengganti teks lisensi dan bukan keputusan legal otomatis, tetapi membuat metadata lebih mudah diproses dibanding label bebas seperti “lisensi BSD-style”.
Batas ini perlu ditegaskan. Sebuah pemeriksaan otomatis dapat menemukan identifier, membandingkannya dengan policy, dan menunjukkan titik konflik. Ia tidak otomatis memahami seluruh kewajiban distribusi, kombinasi lisensi, perubahan kode, atau kontrak komersial yang mengelilingi sebuah produk. GitHub sendiri menulis bahwa pengelompokan risiko lisensi di antarmukanya hanya bersifat informasional dan bukan nasihat hukum.
Karena itu, fitur ini lebih tepat dibaca sebagai kontrol awal dan bukti proses, bukan pengganti tim legal atau security. Ia membantu menjawab pertanyaan yang sangat praktis: dependensi apa yang berubah, lisensi apa yang terdeteksi, aturan mana yang dilanggar, dan siapa yang menyetujui pengecualian. Keputusan akhirnya tetap perlu melihat konteks proyek dan kewajiban lisensi yang berlaku.
Dari keamanan paket ke tata kelola software
GitHub dalam beberapa hari terakhir juga memperluas pemeriksaan di sekitar pull request, termasuk Agentic Autofix untuk alert keamanan dan workflow lockfiles untuk mengurangi perubahan dependensi yang tidak terlihat. License compliance berada di jalur yang berbeda, tetapi arahnya sama: pull request bukan hanya tempat untuk meninjau baris kode, melainkan tempat untuk memeriksa asal-usul, risiko, dan aturan dari komponen yang ikut masuk ke produk.
Perubahan seperti ini paling berguna ketika diterapkan bertahap. Tim bisa mulai dengan mode Evaluate, membersihkan metadata dependensi yang ambigu, menetapkan kebijakan yang bisa dijelaskan, lalu mengaktifkan mode Active pada repositori yang sudah siap. Jika langsung memblokir semua perubahan tanpa memahami hasil deteksi dan jalur pengecualian, ruleset baru justru bisa menjadi sumber friksi.
Ketersediaan umum membuat license compliance lebih mudah dipakai sebagai bagian dari proses engineering perusahaan, bukan eksperimen terpisah. Nilai sebenarnya akan ditentukan oleh kualitas dependency graph, ketepatan metadata lisensi, dan disiplin organisasi dalam meninjau pengecualian. Mesin dapat menghentikan sebuah merge; manusialah yang tetap harus menjelaskan mengapa dependensi itu boleh atau tidak boleh masuk.