Sengketa AGPL: Pelajaran untuk Pembeli Perangkat Lunak

Dua sengketa yang diberitakan pada 2026 memperlihatkan risiko lisensi AGPL bagi pembeli perangkat lunak: syarat merek, hak mengembangkan salinan proyek, dan komponen tertutup. AGPL dapat mewajibkan penyediaan kode sumber, termasuk untuk versi yang dimodifikasi dan digunakan lewat jaringan. Batas kewajibannya perlu dibaca dari lisensi serta bentuk integrasinya. 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 pengembang yang membuat fork komunitas dari perangkat lunak pengolah model cetak 3D (slicer) miliknya.

Kedua kasus memperlihatkan bahwa izin mengembangkan salinan proyek perlu dibedakan dari syarat merek, atribusi, dan penyediaan kode sumber. Pembedaan ini membantu pembeli menilai risiko sebelum mengintegrasikan produk.

ONLYOFFICE dan Euro-Office: sengketa penghapusan merek

Nextcloud dan IONOS membangun Euro-Office sebagai alternatif "berdaulat" untuk Microsoft Office. Editornya dikembangkan dari salinan kode ONLYOFFICE yang berlisensi AGPL. Keberatan ONLYOFFICE berpusat pada penghapusan identitas merek dari salinan tersebut.

AGPL memberikan hak untuk membuat fork, dengan tetap memenuhi ketentuan lisensinya. Termasuk alasan "kami tidak mau lagi bergantung pada vendor yang didirikan di Rusia." Keberatan ONLYOFFICE adalah Euro-Office mencopot identitas merek 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 identitas merek sebagai syarat tambahan (additional term) menurut Pasal 7 AGPLv3. Pasal 7 mengizinkan beberapa syarat terbatas, termasuk pemeliharaan pemberitahuan hukum atau atribusi yang wajar serta penolakan pemberian hak merek tertentu. ONLYOFFICE berpendapat syarat identitas mereknya termasuk di dalam ketentuan itu; keabsahan kewajiban mempertahankan logo tersebut merupakan pokok sengketa.

Tapi Pasal 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 identitas merek itu persis jenis pembatasan yang bisa dihapus.

Pemberitaan yang dirujuk artikel ini belum memuat penyelesaian sengketa. ONLYOFFICE tetap menjalankan konektor Nextcloud-nya untuk pelanggan lama meski sudah menghentikan kemitraan. Komentar hukum dari luar pun terbelah soal Pasal 7 ini.

Yang justru paling terang dari sengketa ini adalah satu hal yang disepakati kedua pihak: hukum merek dan lisensi hak cipta mengatur hak yang berbeda. Lisensi hak cipta dapat menolak memberikan hak atas merek, tetapi tidak menciptakan kewajiban merek yang sebelumnya tidak ada. Belum jelas apakah syarat ONLYOFFICE selamat dari klausul self-cleaning. Bahwa fork itu sendiri diizinkan, tidak pernah dipersoalkan.

SFC dan Bambu Lab: komponen tertutup dalam program gabungan

Bambu Studio dibangun di atas PrusaSlicer yang berlisensi AGPLv3. Bambu menyertakan pustaka jaringan berkode tertutup, libbambu_networking, tanpa menerbitkan kode sumber pustaka tersebut. 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 pengembang independen Paweł Jarczak menerbitkan fork OrcaSlicer yang memulihkan fitur tanpa konektor tertutup Bambu, perusahaan mengirimkan surat tuntutan penghentian (cease-and-desist) kepadanya. SFC memperlakukan ancaman hukum itu sebagai pelanggaran tersendiri. Pasal 10 AGPLv3 melarang pengenaan "pembatasan tambahan atas pelaksanaan hak yang diberikan" oleh lisensi, dan SFC menilai bahwa tekanan terhadap pengguna lanjutan yang berhak mengembangkan kode tersebut termasuk dalam larangan itu.

Dalam kasus Bambu, SFC menilai distribusi program gabungan dan pembatasan hak pengguna. Penilaian organisasi itu bukan putusan pengadilan. Kewajiban distribusi perlu dibedakan dari Pasal 13 AGPL, yang mengatur tawaran kode sumber bagi pengguna jaringan atas versi yang dimodifikasi. Apakah sebuah pustaka menjadi bagian karya gabungan bergantung pada cara integrasinya, bukan sekadar nama "helper".

Analogi resep hanya membantu menggambarkan hak atas salinan. Pemicu hukum tetap perlu dibaca: distribusi karya yang tercakup serta ketentuan tersendiri untuk versi yang dimodifikasi dan diakses pengguna jaringan.

Dalam pengumuman yang dirujuk, SFC menawarkan langkah rekayasa, bukan mengumumkan gugatan. Organisasi ini membuka pendanaan dan proyek untuk merekayasa balik pustaka yang tidak tersedia, lalu memelihara fork independen. Tindakan tersebut menunjukkan bahwa perselisihan lisensi dapat menambah pekerjaan rekayasa dan mengurangi kepercayaan publik meskipun tidak dibawa ke pengadilan.

Apa yang sebenarnya dibatasi AGPL

Tiga koreksi, langsung dari kedua sengketa ini:

1. Hak membuat salinan pengembangan perlu dipisahkan dari pelanggaran ketentuan lain. Lisensi copyleft melindungi hak pengembangan lanjutan dengan kewajiban lisensi yang tetap berlaku. Tidak satu pun sengketa ini mempersoalkan hak Nextcloud atau Jarczak untuk fork. Keduanya mempersoalkan sesuatu yang ditumpuk di atasnya: syarat identitas merek di satu kasus, pustaka tertutup yang tidak diungkap di kasus lain.
2. Pemberitahuan hak cipta berbeda dari logo. AGPL mewajibkan pemeliharaan pemberitahuan hak cipta dan lisensi. Mewajibkan fork tetap menampilkan merek pemegang lisensi adalah permintaan terpisah. Apakah pemegang lisensi bisa melekatkan itu sebagai syarat Pasal 7 yang selamat dari klausul self-cleaning, itu persis yang masih diperdebatkan ONLYOFFICE dan Nextcloud.
3. Periksa pemicu dan cakupan kewajiban. Pasal 13 AGPL menyebut versi yang dimodifikasi dan interaksi pengguna lewat jaringan. Distribusi memiliki ketentuannya sendiri. Penggunaan internal, penggabungan pustaka, dan program terpisah perlu diperiksa berdasarkan fakta integrasinya; keberadaan di satu server saja tidak cukup untuk menyimpulkan seluruh produk harus dibuka.

Mengevaluasi komponen AGPL sebelum diadopsi

Penilaian perlu mencakup teks lisensi dan cara sistem benar-benar digunakan. Sebelum menambahkan komponen AGPL ke suatu 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 kode penghubung internal dan konektor berkode tertutup. Cakupan komponen inilah yang dipersoalkan SFC dalam kasus Bambu Lab.
• Putuskan sebelum arsitektur sulit diubah: "jalankan sebagai AGPL" atau "beli lisensi komersial." Saya sudah membahas jalur kedua dari sisi vendor di pelisensian ganda produk AGPL, termasuk alasan modelnya lebih sederhana daripada dugaan banyak pendiri usaha.
• Kalau pemegang lisensi melekatkan syarat identitas merek atau atribusi di luar kewajiban pemberitahuan standar, baca itu terhadap Pasal 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 kewajiban lisensi sumber terbuka dalam perangkat lunak komersial.

Pelajaran untuk keputusan pengadaan

Sumber yang dirujuk belum menunjukkan penyelesaian kedua sengketa ini, dan itu tidak masalah. Pelajarannya tidak bergantung pada siapa yang menang. Janji inti copyleft, bahwa fork tidak bisa dikunci, tetap utuh di kedua kasus.

Perhatikan syarat identitas merek, cakupan pustaka tertutup, dan perlindungan hak pengguna lanjutan. Baca ketentuan AGPL bersama fakta integrasinya. Kesimpulan yang terlalu luas maupun terlalu sempit dapat membuat keputusan pengadaan keliru.