Dua Sengketa AGPL yang Sedang Berjalan dan Apa yang Sebenarnya Mereka Ajarkan

Dua Sengketa AGPL yang Sedang Berjalan dan Apa yang Sebenarnya Mereka Ajarkan

Dua sengketa AGPL — lisensi open source yang mewajibkan kode sumber ikut dibagikan, bahkan untuk software yang hanya diakses lewat jaringan — sedang berlangsung terbuka saat ini. Keduanya bukan soal apakah lisensinya bisa ditegakkan. ONLYOFFICE menghentikan kemitraan delapan tahunnya dengan Nextcloud pada 31 Maret 2026, setelah Nextcloud dan IONOS meluncurkan fork — salinan proyek yang dikembangkan terpisah — dari editor ONLYOFFICE, bernama Euro-Office. Tujuh minggu kemudian, 18 Mei 2026, Software Freedom Conservancy (SFC) mengumumkan dua pelanggaran AGPLv3 oleh Bambu Lab, produsen printer 3D. Pengumuman itu menyusul ancaman Bambu kepada seorang developer yang membuat fork komunitas dari software slicer-nya.

Kedua kasus ini layak ditelusuri. Sengketa ini menunjukkan persis di mana batas AGPL berada, dan batasnya bukan di tempat kebanyakan tim mengira.

ONLYOFFICE vs. Euro-Office: fork bukan masalahnya

Nextcloud dan IONOS membangun Euro-Office sebagai alternatif "berdaulat" untuk Microsoft Office. Editornya di-fork langsung dari ONLYOFFICE yang berlisensi AGPL. Keberatan ONLYOFFICE bukan soal fork itu sendiri.

AGPL memberi hak fork itu secara mutlak, kepada siapa saja, untuk alasan apa saja. Termasuk alasan "kami tidak mau lagi bergantung pada vendor yang didirikan di Rusia." Keberatan ONLYOFFICE adalah Euro-Office mencopot branding dan logonya. CEO ONLYOFFICE, Lev Bannov, berargumen lisensinya tidak mengizinkan itu: "kami tidak memberi siapa pun hak untuk mencopot branding kami atau mengubah kode open source kami tanpa atribusi yang layak."

Mekanisme di balik klaim itu penting dipahami. ONLYOFFICE menambahkan syarat branding sebagai "additional term" di bawah AGPLv3 Section 7. Lisensinya memang mengizinkan ini: pemegang lisensi boleh menambahkan syarat tambahan yang sempit, termasuk menolak memberi hak trademark tertentu.

Tapi Section 7 juga memuat klausul self-cleaning. Kalau karya yang diterima "memuat notice yang menyatakan diatur oleh Lisensi ini beserta syarat yang merupakan pembatasan tambahan, Anda boleh menghapus syarat itu." Posisi Nextcloud: syarat branding itu persis jenis pembatasan yang bisa dihapus.

Sengketa ini belum selesai sampai tulisan ini dibuat. ONLYOFFICE tetap menjalankan konektor Nextcloud-nya untuk pelanggan lama meski sudah menghentikan kemitraan. Komentar hukum dari luar pun terbelah soal Section 7 ini.

Yang justru paling terang dari sengketa ini adalah satu hal yang disepakati kedua pihak: hukum trademark dan lisensi copyright itu dua rezim berbeda. Lisensi copyright bisa menolak memberi hak trademark, tapi tidak bisa memunculkan kewajiban trademark yang sebelumnya tidak ada. Belum jelas apakah syarat ONLYOFFICE selamat dari klausul self-cleaning. Bahwa fork itu sendiri diizinkan, tidak pernah dipersoalkan.

SFC vs. Bambu Lab: tidak ada pengecualian "kami kan tidak benar-benar mendistribusikannya"

Bambu Studio dibangun di atas PrusaSlicer yang berlisensi AGPLv3. Bambu membundelnya dengan library networking proprietary, libbambu_networking, tanpa mempublikasikan source library itu. Penilaian SFC tegas: mengirimkan program gabungan tanpa Corresponding Source untuk setiap komponen di dalamnya "merupakan pelanggaran AGPLv3 yang serius dan terus berlangsung."

Ada pelanggaran kedua yang terpisah. Ketika developer independen Paweł Jarczak mempublikasikan fork OrcaSlicer yang mengembalikan fitur tanpa konektor proprietary Bambu, Bambu mengirimkan cease-and-desist kepadanya. SFC memperlakukan ancaman hukum itu sebagai pelanggaran tersendiri. AGPLv3 Section 10 melarang pengenaan "pembatasan tambahan atas pelaksanaan hak yang diberikan" oleh lisensi, dan menekan pengguna downstream atas kode yang sepenuhnya berhak mereka bangun jelas masuk larangan itu.

Tidak satu pun temuan ini bergantung pada apakah Bambu "mendistribusikan" software dalam arti sempit yang biasa diasumsikan orang. Kewajiban menyediakan Corresponding Source melekat begitu program disampaikan ke pengguna, baik sebagai download, installer bundelan, maupun layanan yang diakses lewat jaringan. Tidak ada pengecualian untuk helper library proprietary yang di-link ke binary yang sama.

Bayangkan AGPL seperti resep masakan yang wajib dibagikan lengkap kalau hidangannya disajikan ke tamu, bukan cuma kalau resepnya dijual. Kalau ia dikirim sebagai bagian dari karya gabungan, source-nya juga harus dikirim, atau lisensinya dilanggar.

SFC tidak mengajukan gugatan. Mereka membuka dana dan proyek untuk reverse-engineer library yang hilang itu, lalu memelihara fork independen. Pelajarannya: penegakan tidak butuh ruang sidang untuk membuat vendor kehilangan waktu engineering nyata dan kepercayaan publik.

Apa yang sebenarnya dibatasi AGPL

Tiga koreksi, langsung dari kedua sengketa ini:

1. Fork tidak pernah jadi pelanggaran. Copyleft ada justru supaya fork tidak bisa dihentikan. Tidak satu pun sengketa ini mempersoalkan hak Nextcloud atau Jarczak untuk fork. Keduanya mempersoalkan sesuatu yang ditumpuk di atasnya: syarat branding di satu kasus, library proprietary yang tidak diungkap di kasus lain.
2. Atribusi berarti notice copyright, bukan logo pemegang lisensi. AGPL mewajibkan mempertahankan notice copyright dan lisensi. Mewajibkan fork tetap menampilkan brand pemegang lisensi adalah permintaan terpisah. Apakah pemegang lisensi bisa melekatkan itu sebagai syarat Section 7 yang selamat dari klausul self-cleaning, itu persis yang masih diperdebatkan ONLYOFFICE dan Nextcloud.
3. Klausul jaringan tidak punya pengecualian ukuran. Menjalankan software hanya secara internal, atau menganggap komponen yang di-link sebagai "cuma helper library," tidak menghapus kewajibannya. Kalau karya gabungan itu sampai ke pengguna mana pun, remote atau lokal, Corresponding Source untuk keseluruhannya tetap terutang.

Mengevaluasi komponen AGPL sebelum diadopsi

Yang penting bukan cuma apa yang dikatakan teks lisensinya, tapi apa yang akan dilakukan deployment yang sebenarnya. Sebelum menarik dependency AGPL ke sesuatu yang akan dijalankan sebagai layanan:

• Pastikan apakah ada modifikasi yang dilakukan. Pemakaian tanpa modifikasi dan tanpa redistribusi jauh lebih aman daripada fork yang direncanakan untuk dioperasikan sendiri.
• Petakan setiap komponen yang akan ikut dikirim atau berjalan bersamanya, termasuk glue code internal dan konektor proprietary apa pun. Itu persis celah yang menjerat Bambu Lab.
• Putuskan sebelum arsitektur mengeras: "jalankan sebagai AGPL" atau "beli lisensi komersial." Saya sudah membahas jalur kedua dari sisi vendor di dual licensing produk AGPL, termasuk kenapa modelnya lebih sederhana daripada dugaan kebanyakan founder.
• Kalau pemegang lisensi melekatkan syarat branding atau atribusi di luar kewajiban notice standar, baca itu terhadap Section 7. Jangan langsung asumsikan itu mengikat, atau bahwa itu bebas diabaikan.

Untuk peta yang lebih luas soal apa yang sebenarnya diwajibkan tiap lisensi, termasuk AGPL, lihat apa yang sebenarnya diwajibkan lisensi open-source di software komersial.

Intinya

Kedua sengketa ini masih berjalan sampai tulisan ini dibuat, dan itu tidak masalah. Pelajarannya tidak bergantung pada siapa yang menang. Janji inti copyleft, bahwa fork tidak bisa dikunci, tetap utuh di kedua kasus.

Yang dipersengketakan adalah semua yang dibangun di sekitarnya: syarat branding, library proprietary yang tidak diungkap, dan apakah mengancam pengguna downstream itu sendiri sudah melanggar lisensi. Baca AGPL untuk apa yang sebenarnya dikatakannya. Jangan telan begitu saja versi maksimalis atau minimalis yang dikutipkan orang.