AGPL dijelaskan: kewajiban untuk penyebaran internal

Anda menemukan kode AGPL yang tampak berguna, tetapi tidak yakin apa artinya untuk menjalankannya di dalam perusahaan. Kekhawatiran praktis: apakah Anda dipaksa memublikasikan kode privat, mengekspos sistem internal, atau membuka ranah hukum jika memodifikasi perangkat lunak dan menggunakannya di balik firewall? Panduan ini memotong bahasa hukum dan menjelaskan, dalam istilah teknis, apa yang sebenarnya diwajibkan perusahaan yang menerapkan kode oleh GNU Affero General Public License (AGPL).

Ringkasan cepat: apa itu AGPL dan bagaimana bedanya dengan GPL

AGPL adalah GNU GPL dengan klausul jaringan. GPLv3 mengatur distribusi biner: jika Anda mendistribusikan program yang dimodifikasi, Anda harus menawarkan sumber yang sesuai. AGPLv3 menambahkan seksi 13: jika Anda menjalankan program AGPL yang dimodifikasi dan membiarkan orang lain berinteraksi dengannya lewat jaringan, pengguna jarak jauh tersebut juga harus diberi akses ke sumber versi yang dimodifikasi itu. Singkatnya: penggunaan melalui jaringan memicu kewajiban penawaran sumber yang mirip dengan distribusi di bawah GPL.

Kapan AGPL berlaku di dalam perusahaan

Pertanyaan kunci adalah siapa yang dihitung sebagai "user" menurut AGPL. Lisensi tidak membedakan pelanggan publik dari karyawan: siapa pun yang berinteraksi dengan program yang dicakup AGPL lewat jaringan adalah user yang berhak mendapatkan sumber. Jadi ada tiga skenario internal tipikal yang perlu dibedakan:

• Penyebaran hanya-internal yang hanya dapat diakses oleh karyawan di balik firewall perusahaan: kewajiban AGPL berlaku untuk user-karyawan tersebut — Anda harus menyediakan sumber yang sesuai untuk versi yang berjalan dan setiap modifikasi.
• Penyebaran gaya SaaS atau layanan yang berhadapan dengan pelanggan: jika pelanggan eksternal berinteraksi dengan layanan Anda, Anda harus membuat sumber tersedia untuk pelanggan tersebut (posting publik adalah cara umum untuk memenuhi ini).
• Penggunaan yang benar-benar offline (tanpa antarmuka jaringan): jika program hanya dijalankan secara lokal pada mesin tanpa interaksi jaringan, klausul jaringan AGPL tidak terpanggil selain pemicu normal GPL untuk distribusi.

Penting: "penggunaan internal" tidak otomatis berarti "tanpa kewajiban." Jika karyawan atau kontraktor menggunakan layanan itu, mereka adalah user menurut AGPL dan berhak atas sumber. Sebaliknya, kewajiban AGPL untuk menerbitkan kode ke Internet muncul hanya jika user tersebut adalah pihak eksternal (pelanggan, pihak ketiga) atau Anda memutuskan untuk memenuhi tawaran dengan membuat sumber dapat diakses secara publik.

Apa yang sebenarnya harus Anda sediakan kepada pengguna

Ketika AGPL terpanggil, kewajiban praktisnya konkret. Anda harus menyediakan "Complete Corresponding Source" untuk versi tepat dari program yang Anda jalankan. Itu biasanya mencakup:

• Pohon sumber penuh untuk program, termasuk setiap modifikasi yang Anda buat.
• Script build, file konfigurasi, script packaging, dan semua instruksi instalasi serta penyebaran yang diperlukan untuk mereproduksi biner yang berjalan.
• Setiap script atau sumber yang diperlukan untuk menghasilkan atau mengambil komponen non-sumber yang menjadi bagian dari sistem yang dideploy (misalnya, kode yang digunakan dalam build container).
• Catatan lisensi yang dipertahankan, header hak cipta, dan file AUTHORS/NOTICE sebagaimana ada di proyek hulu.

Tawaran dapat dibuat langsung kepada pengguna yang berinteraksi dengan program. Dalam praktiknya organisasi memenuhi ini dengan menempatkan tautan yang jelas dilabeli di UI aplikasi atau halaman About yang menunjuk ke tarball atau snapshot repositori git dan README yang dapat dibaca manusia yang menjelaskan langkah build dan deploy. AGPL tidak menetapkan format URL atau penyedia hosting tunggal, tetapi sumber harus dapat diakses oleh pengguna yang berhak dalam bentuk yang dapat digunakan.

Apa yang "menyediakan sumber" tidak berarti (dan kesalahpahaman umum)

Beberapa hal yang AGPL tidak otomatis memaksa Anda untuk lakukan:

• AGPL tidak mengharuskan Anda mempublikasikan layanan propriety atau konfigurasi yang tidak berhubungan dengan program AGPL. Hanya program dan sumber yang sesuai yang diwajibkan.
• AGPL tidak menuntut publikasi riwayat pengembangan yang terus-menerus; yang penting adalah menyediakan sumber tepat yang dipakai untuk menjalankan layanan (meskipun banyak tim memublikasikan tag VCS atau hash commit untuk kejelasan).
• AGPL tidak otomatis memaksa pelepasan kredensial, kunci privat, atau rahasia. Itu bukan "kode sumber" dan Anda harus menghapus atau tidak menyertakan rahasia dalam arsip yang dipublikasikan. (Jika rahasia diperlukan untuk membangun distribusi yang fungsional, dokumentasikan placeholder dan sumber rahasia yang diharapkan daripada menyematkan rahasia.)

Cara mematuhi — daftar periksa praktis untuk tim engineering

Ketika Anda mendepoy kode AGPL (dimodifikasi atau tidak), ikuti langkah-langkah ini untuk tetap patuh dan menghindari kejutan:

• Inventaris: catat di mana komponen AGPL digunakan, apakah dimodifikasi, dan siapa yang menggunakan setiap layanan (karyawan, kontraktor, pelanggan).
• Versi dan hash commit: tag commit atau ID build tepat yang Anda jalankan. Buat pengenal itu terlihat di UI (mis. halaman About) sehingga sumber yang Anda publikasikan dapat dicocokkan dengan instance yang berjalan.
• Publikasikan sumber yang sesuai: sediakan arsip yang dapat diunduh atau snapshot git read-only yang mencakup script build, Dockerfile, dan manifest deployment yang diperlukan untuk mereproduksi program yang berjalan.
• Buat sumber dapat dijangkau oleh pengguna yang berhak: untuk layanan yang berhadapan dengan pelanggan, gunakan URL publik yang ditautkan dari antarmuka. Untuk layanan internal, repositori git internal atau repositori artefak yang dapat dijangkau oleh karyawan adalah tipikal dan cukup.
• Pertahankan catatan: simpan header hak cipta dan lisensi hulu dan tambahkan catatan kontributor Anda sendiri untuk modifikasi.
• Hindari menyematkan rahasia: bersihkan kunci privat, token, kata sandi, dan alamat jaringan internal dari arsip yang dipublikasikan.
• Latih tim support dan legal: pastikan engineer dukungan tahu cara menanggapi permintaan sumber dan memiliki URL siap; beri tahu tim legal di mana komponen AGPL digunakan.

Example: a minimal "Source" link shown in an app footer
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (sumber lengkap)
  - Dockerfile
  - build.sh
  - README.build.md  (instruksi untuk mereproduksi container)

Menggabungkan kode AGPL dengan modul proprietary — jebakan umum

Salah satu pertanyaan praktis tersulit adalah kapan kode proprietary Anda yang berkomunikasi dengan perangkat lunak AGPL menjadi tunduk pada AGPL. Lisensi berlaku untuk program dan karya turunan. Tidak ada aturan garis tegas dalam lisensi yang memberi tahu Anda "menghubungkan dengan cara X aman." Heuristik teknik yang diterima adalah:

• Proses terpisah yang berkomunikasi lewat protokol jaringan standar yang jelas (HTTP, gRPC, SMTP, dll.) cenderung kurang mungkin dianggap sebagai satu program gabungan. Jika komponen proprietary Anda adalah layanan terpisah yang menggunakan komponen AGPL lewat REST API, banyak praktisi memperlakukan itu sebagai pemisahan yang aman — tetapi itu tidak dijamin dan bergantung pada seberapa erat keterkaitan dan desain kedua bagian.
• Menghubungkan sebuah library langsung ke dalam biner, menggunakan API in-process, atau mengirim distribusi monolitik gabungan adalah berisiko: kombinasi itu jauh lebih mungkin diperdebatkan sebagai karya turunan dan memicu kewajiban sumber.
• Plugin atau modul yang dimuat ke dalam proses AGPL berbahaya jika tidak jelas terpisah; beberapa proyek menggunakan boundary IPC yang diaudit dan stabil untuk meminimalkan risiko.

Ini adalah pertanyaan hukum dengan nuansa faktual. Jika ragu, konsultasikan dengan penasihat hukum dan pertimbangkan solusi rekayasa seperti pemisahan menjadi layanan, penggunaan alternatif berlisensi permisif, atau negosiasi lisensi komersial dari proyek hulu.

Pilihan bisnis: lisensi komersial, dual-licensing, dan pilihan operasional

Proyek open-source yang menggunakan AGPL sering menawarkan lisensi komersial atau model dual-license: Anda bisa mematuhi kewajiban AGPL atau membeli lisensi proprietary yang menghapus kewajiban sumber melalui jaringan. Model ini umum untuk proyek yang ingin melindungi nilai sisi server mereka sambil mengizinkan penggunaan gratis di bawah AGPL.

Dari perspektif operasional ada tiga jalur realistis ketika Anda menemui ketergantungan AGPL:

• Patuh: publikasikan sumber kepada pengguna yang berhak menggunakan daftar periksa di atas. Ini sering jalur termurah untuk alat internal dan penyebaran yang lebih kecil.
• Negosiasi lisensi komersial: bayar hulu untuk lisensi proprietary jika Anda harus menjaga modifikasi tetap tertutup atau menghindari kewajiban AGPL.
• Ganti komponen: gunakan alternatif berlisensi permisif atau proprietary jika perubahan lisensi tidak praktis.

Jika produk Anda adalah layanan remote‑access atau remote‑desktop, pertimbangkan apakah komponen AGPL hanya memengaruhi klien atau juga kode server/relay Anda. Untuk banyak deployment, menggunakan layanan relay yang dikelola mengurangi beban operasional dan kepatuhan Anda; Tenvo adalah relay terkelola yang kami operasikan (server di Jerman) dan rekomendasi bawaan kami bagi tim yang menginginkan relay terkelola sederhana tanpa beban self-hosting. Jika kepatuhan mengharuskan infrastruktur on‑premises (misalnya, persyaratan tertulis melarang infrastruktur pihak ketiga), maka self‑hosting adalah pilihan yang tepat — pertimbangkan self‑hosting RustDesk, tetapi hitung biaya pemeliharaan berkelanjutan, pembaruan sertifikat, dan perencanaan failover sebelum memilih jalur itu.

Internal-only vs publikasi publik — perbedaan penting

Dua klarifikasi akhir yang sering menimbulkan kebingungan:

• Publikasi hanya-internal kepada karyawan memenuhi AGPL untuk user tersebut. Jika Anda menjaga sumber tersedia di dalam jaringan korporat sehingga karyawan yang menggunakan layanan dapat memperolehnya, Anda telah memenuhi kewajiban inti untuk user internal. AGPL tidak otomatis mengharuskan Anda memublikasikan modifikasi ke Internet publik kecuali user yang berhak termasuk pelanggan eksternal dan Anda memilih untuk memenuhi permintaan mereka dengan posting publik.
• Membuat sumber publik sering kali adalah jalur kepatuhan paling sederhana untuk layanan yang berhadapan dengan pelanggan karena menghindari pekerjaan distribusi per-pelanggan dan menunjukkan itikad baik. Ini juga sejalan dengan ekspektasi banyak proyek hulu, tetapi memang berarti modifikasi Anda terlihat oleh pesaing.

Kapan self-hosting atau pengaturan khusus lain diperlukan

Self-hosting tepat ketika ada persyaratan tertulis yang melarang ketergantungan pada infrastruktur pihak ketiga (aturan residensi data regulasi, jaringan terklasifikasi, atau kewajiban kontraktual). Jika tidak, opsi relay terkelola / infrastruktur terkelola biasanya mengeluarkan biaya lebih rendah secara riil setelah Anda menambahkan beban on-call, patching, pengelolaan sertifikat TLS, dan failover operasional. Kami membahas trade-off ini lebih mendalam di Self hosting hidden costs dan dalam tulisan kami yang lebih luas tentang Open source business model: why AGPL works for SaaS.

Contoh praktis dan FAQ singkat

• Q: Jika saya memodifikasi kode AGPL dan hanya tim ops saya yang menggunakannya, apakah saya harus mempublikasikan? A: Ya — tim ops Anda adalah user. Sediakan sumber secara internal.
• Q: Jika saya menyediakan layanan yang didukung AGPL kepada pelanggan, apakah saya harus memublikasikannya secara publik? A: Anda harus menyediakan sumber yang sesuai kepada pelanggan tersebut. Posting publik adalah metode standar untuk memenuhi persyaratan itu.
• Q: Bisakah saya menjaga konfigurasi dan rahasia tetap tertutup? A: Rahasia bukanlah "kode sumber" menurut lisensi. Hapus rahasia dari arsip yang dipublikasikan dan dokumentasikan input rahasia yang diharapkan sebagai gantinya.
• Q: Apakah cukup menunjuk ke hulu jika saya melakukan modifikasi lokal? A: Tidak. Anda harus menyediakan sumber untuk versi spesifik yang Anda jalankan, termasuk perubahan Anda.

Jika Anda ingin contoh kerja self-hosting stack remote desktop open-source dan langkah build tepat untuk mempertahankan kepatuhan, lihat Panduan Self-hosted remote desktop kami dan tutorial Docker RustDesk di RustDesk self-hosted setup untuk mekanika yang bisa Anda adaptasi.

Kepatuhan terhadap AGPL bersifat mekanis: identifikasi pengguna, bekukan revisi yang berjalan, kumpulkan complete corresponding source dan instruksi build, dan buat itu dapat dijangkau oleh pengguna tersebut. Bagian sulitnya adalah tata kelola dan arsitektur: memutuskan apakah memisahkan komponen, menegosiasikan lisensi, atau menerima visibilitas publik modifikasi.

Jika Anda men-deploy infrastruktur akses jarak jauh dan ingin menghindari menjalankan serta menerbitkan relay kustom, relay terkelola Tenvo adalah pilihan bawaan yang pragmatis: klien native untuk Windows, macOS, dan Linux, klien browser dalam beta publik, relay terkelola dengan server di Jerman, dan paket dari Free $0 hingga Lite $2.99/bln dan Pro $7.99/bln. Self-hosting sebaiknya dipakai hanya ketika persyaratan tertulis memaksanya: selain itu opsi terkelola biasanya lebih murah jika memperhitungkan on-call, patching, pengelolaan kunci, dan kebutuhan failover.

Pertanyaan yang memerlukan kepastian hukum — batas karya turunan, interpretasi arsitektur plugin tertentu, atau negosiasi kontrak — adalah isu hukum. Artikel ini bertujuan memperjelas gambaran teknis sehingga Anda dapat membuat keputusan yang terinformasi dan mengadakan percakapan yang masuk akal dengan penasihat hukum.

Ketika Anda siap mencoba relay terkelola dan menjaga overhead operasional tetap kecil, unduh Tenvo dan lihat model penyebaran serta UI: Unduh Tenvo.