MODUL HUKUM DAN KEBIJAKAN TEKNOLOGI INFORMASI

Mata Kuliah: Hukum dan Kebijakan Teknologi Informasi
Kode MK: INF2505
SKS: 2 (Teori)
Semester: 2
Program Studi: Informatika
Fakultas: Ekonomi dan Bisnis Islam
Universitas: UIN K.H. Abdurrahman Wahid Pekalongan

Dosen Pengampu: Mohammad Reza Maulana, M.Kom
NIP: 199110082025051002

Pertemuan: 11 dari 16
Durasi: 100 menit (2 × 50 menit)

Panduan Penggunaan Modul

Modul ini mencakup Pertemuan 11 (Hak Kekayaan Intelektual di Era Digital: Hak Cipta, Lisensi OSS, dan Paten Perangkat Lunak). Ini adalah pertemuan pertama dari blok baru setelah pembahasan cybercrime (P9–P10), membawa mahasiswa dari perspektif "apa yang dilarang" ke perspektif "apa yang dilindungi" dalam ekosistem digital.

Catatan Administratif:

• Tugas 7 (Analisis Lisensi OSS) diumumkan resmi pada pertemuan ini.
• Esai Refleksi P10 seharusnya sudah dikumpulkan via Ngaji UIN Gusdur (3 hari setelah P10).
• Workshop analisis lisensi di bagian akhir sesi memerlukan akses internet untuk mengecek lisensi proyek OSS secara langsung — pastikan proyektor dan koneksi tersedia.

PERTEMUAN 11

Hak Kekayaan Intelektual di Era Digital: Hak Cipta, Lisensi OSS, dan Paten Perangkat Lunak

Sub-CPMK: Sub-CPMK03.4.1
Bobot: 7% dari Nilai Akhir
→ PENGUMUMAN TUGAS 7 (Analisis Lisensi OSS)

JEMBATAN DARI PERTEMUAN 9–10

PERTEMUAN 9–10: CYBERCRIME              PERTEMUAN 11: HKI DIGITAL
"Apa yang DILARANG                      "Apa yang DILINDUNGI
dalam ekosistem digital:                dalam ekosistem digital:
  • Akses ilegal sistem                   • Hak cipta kode sumber
  • Pencurian data                        • Lisensi perangkat lunak
  • Penyebaran konten ilegal              • Paten inovasi teknis
  • Penipuan digital"                     • Merek produk digital"
          │                                          │
          └──────────────────┬───────────────────────┘
                             ▼
            "Dua sisi koin hukum yang sama:
             Cybercrime = melanggar hak orang lain.
             HKI = melindungi hak kreatif seseorang.

             Seorang programmer yang kodenya dicuri
             adalah korban dua pelanggaran sekaligus:
             (1) Pasal 32 UU ITE — manipulasi/pencurian data
             (2) Pasal 113 UU Hak Cipta — pelanggaran hak cipta"

Pertanyaan jembatan: Di Pertemuan 10, kita membahas bagaimana penyidik menyita hard disk sebagai barang bukti. Pertanyaan baru: Jika kode sumber milik sebuah perusahaan ada di hard disk yang disita itu, siapa pemilik hak atas kode tersebut? Apakah programmer yang menulis kode, perusahaan yang mempekerjakan programmer, atau keduanya? Ini adalah pertanyaan inti hukum HKI digital.

CAPAIAN PEMBELAJARAN

Sub-CPMK yang Dituju

Indikator Ketercapaian

Setelah pertemuan ini, mahasiswa mampu:

1. Menjelaskan sistem perlindungan HKI digital di Indonesia berdasarkan UU No. 28/2014 (C2).
2. Membedakan empat jenis perlindungan HKI untuk perangkat lunak: hak cipta, paten, trade secret, dan merek (C2).
3. Menganalisis perbedaan antara lisensi copyleft kuat, copyleft lemah, dan permisif beserta implikasi hukumnya dalam pengembangan perangkat lunak komersial (C4).
4. Mengevaluasi kompatibilitas lisensi OSS dalam skenario pengembangan produk nyata (C5).
5. Menjelaskan kerangka perlindungan hak cipta internasional melalui Konvensi Berne, WCT, WPPT, dan DMCA (C2).
6. Mengidentifikasi risiko pelanggaran HKI dalam proses pengembangan perangkat lunak (C4).

BAGIAN 11.1 — MENGAPA HKI PENTING BAGI PENGEMBANG PERANGKAT LUNAK

11.1.1 Paradoks Dunia Digital: Mudah Disalin, Mahal Diciptakan

Sebelum membahas hukumnya, penting memahami mengapa HKI ada. Di dunia fisik, menyalin sebuah sepeda motor memerlukan pabrik, bahan baku, dan tenaga kerja. Di dunia digital, menyalin sebuah aplikasi hanya membutuhkan Ctrl+C dan beberapa detik.

PARADOKS PERANGKAT LUNAK

BIAYA PENCIPTAAN:                    BIAYA PENGGANDAAN:
Tim 10 developer × 12 bulan         Copy-paste: Rp 0
Rp 3 miliar investasi                Waktu: < 1 detik
Hardware, cloud, testing             Kualitas: identik 100%
Dokumentasi, QA
                │                              │
                └──────────────────┬───────────┘
                                   ▼
                    Tanpa perlindungan hukum:
                    TIDAK ADA INSENTIF untuk
                    berinvestasi dalam inovasi.
                    Mengapa menghabiskan Rp 3 miliar
                    jika pesaing bisa menyalin gratis?

                    ➜ Di sinilah HKI hadir:
                    memberikan hak eksklusif sementara
                    kepada pencipta sebagai imbalan atas
                    investasi kreatif/inovatif mereka.

11.1.2 HKI sebagai Ekosistem, Bukan Sekadar Hak

HKI bukan hanya melindungi pencipta — ia membentuk seluruh ekosistem industri software:

BAGIAN 11.2 — KERANGKA HUKUM HAK CIPTA DIGITAL DI INDONESIA

11.2.1 UU No. 28 Tahun 2014 tentang Hak Cipta: Ikhtisar

UU Hak Cipta No. 28/2014 adalah regulasi utama yang mengatur perlindungan karya cipta di Indonesia, menggantikan UU No. 19/2002. Ia mengadopsi standar internasional dari Berne Convention dan WCT.

STRUKTUR UU NO. 28/2014 TENTANG HAK CIPTA

Bab I    : Ketentuan Umum (definisi: ciptaan, pencipta, hak cipta,
           program komputer, ekspresi, fiksasi)
Bab II   : Lingkup Hak Cipta
Bab III  : Masa Berlaku Hak Cipta
Bab IV   : Pencatatan Ciptaan (opsional, bukan syarat perlindungan)
Bab V    : Lisensi & Lisensi Wajib
Bab VI   : Lembaga Manajemen Kolektif (LMK)
Bab VII  : Teknologi Informasi & Hak Cipta
Bab VIII : Penyelesaian Sengketa
Bab IX   : Penyidikan
Bab X    : Ketentuan Pidana

11.2.2 Tiga Prinsip Dasar Hak Cipta yang Wajib Dipahami

Prinsip 1: Perlindungan Otomatis (Automatic Protection)

Hak cipta lahir secara otomatis pada saat karya diekspresikan dalam bentuk nyata — tanpa perlu didaftarkan, tanpa perlu dicantumkan simbol ©.

Implikasi langsung untuk pengembang: Kode yang Anda tulis hari ini sudah dilindungi hak cipta sejak baris pertama ditulis. Anda tidak perlu mendaftarkan kode ke Direktorat Jenderal Kekayaan Intelektual (DJKI) untuk mendapat perlindungan — meskipun pendaftaran tetap dianjurkan sebagai bukti kepemilikan jika terjadi sengketa.

PERBANDINGAN: PERLINDUNGAN OTOMATIS vs. PENDAFTARAN

              HAK CIPTA               MEREK / PATEN
              (UU 28/2014)            (UU 20/2016 & 13/2016)
              
Syarat        Otomatis saat karya     Wajib mendaftar ke DJKI
perlindungan  diekspresikan           sebelum ada perlindungan

Biaya         Rp 0 untuk lahirnya     Ada biaya pendaftaran
              hak cipta               resmi

Pembuktian    Lebih kompleks jika     Sertifikat sebagai bukti
dalam         tidak ada bukti         kepemilikan yang kuat
sengketa      tertulis

Prinsip 2: Ide Tidak Dilindungi, Ekspresi Dilindungi (Idea-Expression Dichotomy)

Hak cipta tidak melindungi ide, konsep, atau metode — ia hanya melindungi ekspresi konkret dari ide tersebut.

Ini adalah prinsip paling penting dan paling sering disalahpahami:

IDEA-EXPRESSION DICHOTOMY DALAM SOFTWARE

IDE (tidak dilindungi):               EKSPRESI (dilindungi):
─────────────────────                 ───────────────────────
"Aplikasi pencarian                   Kode sumber spesifik
 berdasarkan lokasi"                  yang mengimplementasikan
                                      fitur pencarian lokasi

"Algoritma sorting                    Implementasi kode
 yang efisien"                        algoritma sorting tersebut
                                      dalam bahasa tertentu

"Sistem autentikasi                   Arsitektur dan kode
 dua faktor"                          spesifik sistem 2FA yang
                                      dibuat

IMPLIKASI:
✓ Anda boleh membuat aplikasi dengan FUNGSI serupa dengan
  aplikasi pesaing — karena ide/fungsi tidak dilindungi.
✗ Anda TIDAK boleh menyalin kode sumber pesaing untuk
  mengimplementasikan fungsi tersebut.

Prinsip 3: Hak Moral dan Hak Ekonomi yang Terpisah

DUA JENIS HAK DALAM HAK CIPTA

HAK MORAL (Moral Rights)              HAK EKONOMI (Economic Rights)
─────────────────────────             ───────────────────────────────
Melekat permanen pada                 Dapat dialihkan, dijual,
pencipta — tidak bisa                 atau dilisensikan kepada
dipindahtangankan                     pihak lain

Isi hak moral:                        Isi hak ekonomi:
• Hak untuk diakui sebagai            • Hak penerbitan (publishing)
  pencipta (attribution)              • Hak reproduksi (copying)
• Hak integritas karya                • Hak distribusi
  (karya tidak boleh                  • Hak adaptasi/modifikasi
  dirusak/diubah tanpa izin)          • Hak pengumuman publik
• Hak untuk merahasiakan              • Hak penyewaan
  identitas sebagai pencipta
  anonim

RELEVANSI UNTUK DEVELOPER:
Meski Anda mengalihkan hak ekonomi ke perusahaan
melalui kontrak kerja, hak moral Anda sebagai pencipta
tetap melekat — perusahaan tidak boleh menghapus nama
Anda dari kode yang Anda tulis (kecuali dengan persetujuan
eksplisit dalam kontrak).

11.2.3 Masa Berlaku Perlindungan Hak Cipta

Mengapa software hanya 50 tahun (bukan seumur hidup + 70)? Karena software dianggap memiliki siklus hidup yang lebih pendek dibanding karya seni atau sastra — teknologi yang digunakan hari ini mungkin sudah usang dalam 10 tahun. Pembuat UU menilai 50 tahun sudah cukup untuk membalas investasi inovatif.

11.2.4 Program Komputer sebagai Ciptaan yang Dilindungi

Pasal 1 angka 9 UU No. 28/2014 mendefinisikan program komputer sebagai:

"Seperangkat instruksi yang diekspresikan dalam bentuk bahasa, kode, skema, atau dalam bentuk apa pun yang apabila digabungkan dengan media yang dapat dibaca dengan komputer akan mampu membuat komputer bekerja untuk melakukan fungsi-fungsi khusus atau untuk mencapai hasil yang khusus, termasuk persiapan dalam merancang instruksi- instruksi tersebut."

Yang dilindungi dalam konteks program komputer:

LINGKUP PERLINDUNGAN HAK CIPTA PERANGKAT LUNAK

DILINDUNGI:                           TIDAK DILINDUNGI:
────────────────                      ─────────────────
✓ Kode sumber (source code)           ✗ Ide/konsep di balik
✓ Kode objek (object code /             program
  bytecode / compiled code)           ✗ Algoritma (sebagai
✓ Struktur, urutan, dan                 konsep abstrak)
  organisasi kode secara              ✗ Fungsi/fitur program
  keseluruhan                         ✗ Format data
✓ Antarmuka pengguna (UI)             ✗ Bahasa pemrograman
  jika orisinal                         itu sendiri
✓ Dokumentasi teknis                  ✗ Standar terbuka
✓ Komentar dalam kode                   (open standards)
✓ Nama variabel dan struktur          ✗ Protokol komunikasi
  secara keseluruhan

11.2.5 Kepemilikan Hak Cipta: Siapa Pemilik Kode?

Pertanyaan ini menjadi sangat relevan dalam konteks pekerjaan sebagai developer:

SIAPA PEMILIK HAK CIPTA ATAS KODE YANG ANDA TULIS?

SKENARIO 1: Kode Ditulis Sendiri (Freelancer/Proyek Pribadi)
→ ANDA sebagai pencipta adalah pemegang hak cipta.

SKENARIO 2: Kode Ditulis sebagai Karyawan Perusahaan
→ Pasal 36 UU 28/2014: jika tidak ada perjanjian lain,
  PERUSAHAAN (badan hukum) adalah pemegang hak cipta
  atas ciptaan yang dibuat dalam hubungan kerja.
→ Namun HAK MORAL tetap milik Anda sebagai pencipta.

SKENARIO 3: Kode Ditulis atas Pesanan (Kontrak)
→ PIHAK YANG MEMESAN adalah pemegang hak ekonomi,
  kecuali diperjanjikan lain dalam kontrak.
→ Pastikan klausul kepemilikan IP jelas dalam kontrak!

SKENARIO 4: Kode Ditulis Bersama-Sama (Co-authorship)
→ HAK BERSAMA: semua pencipta memiliki hak cipta,
  dan tindakan apa pun atas karya bersama memerlukan
  persetujuan semua pihak (kecuali diperjanjikan lain).

SKENARIO 5: Kode Dihasilkan oleh AI (Pertanyaan Baru)
→ Hukum Indonesia (dan mayoritas hukum dunia) belum
  mengatur ini secara eksplisit.
→ Posisi umum saat ini: AI tidak dapat menjadi pencipta
  — AI-generated code mungkin tidak memiliki perlindungan
  hak cipta, atau hak cipta jatuh kepada pengguna AI
  yang mengarahkan pembuatannya.
→ Ini akan menjadi pertanyaan hukum penting di dekade
  mendatang.

BAGIAN 11.3 — EMPAT LAPISAN PERLINDUNGAN HKI UNTUK PERANGKAT LUNAK

Sebuah produk perangkat lunak dapat dilindungi oleh empat jenis HKI secara bersamaan, masing-masing melindungi aspek yang berbeda:

EMPAT LAPISAN PERLINDUNGAN HKI UNTUK SOFTWARE

Produk Software
(contoh: aplikasi e-commerce)
         │
    ┌────┴──────────────────────────────────┐
    │                                        │
    ▼                                        ▼
HAK CIPTA                                PATEN
• Melindungi: kode sumber, UI            • Melindungi: metode/proses
  dokumentasi, aset visual                 teknis yang inovatif
• Syarat: orisinalitas                   • Syarat: baru, inventif,
• Masa: 50 tahun (software)                dapat diterapkan industri
• Lahir: otomatis                        • Masa: 20 tahun
                                         • Lahir: setelah pendaftaran
    │                                        │
    ▼                                        ▼
MEREK                                    TRADE SECRET
• Melindungi: nama, logo,                • Melindungi: kode sumber
  tagline produk                           yang dirahasiakan,
• Syarat: distinctiveness                  algoritma proprietary,
• Masa: 10 tahun (dapat                    data bisnis rahasia
  diperpanjang)                          • Syarat: upaya menjaga
• Lahir: setelah pendaftaran               kerahasiaan

11.3.1 Hak Cipta Perangkat Lunak (Sudah Dibahas di Bagian 11.2)

Perlindungan terhadap ekspresi konkret dari kode — bukan ide di baliknya.

11.3.2 Paten Perangkat Lunak

Paten memberikan hak monopoli sementara (20 tahun) kepada penemu atas invensi teknis yang baru, inventif, dan dapat diterapkan dalam industri.

Perdebatan: Apakah Software Bisa Dipatenkan?

Ini adalah salah satu isu paling kontroversial dalam hukum HKI global:

POSISI BERBAGAI JURISDIKSI TERHADAP PATEN SOFTWARE

AMERIKA SERIKAT (USPTO):
• Paten software diakui secara luas sejak 1980-an
• Putusan Alice Corp. v. CLS Bank (2014) membatasi:
  software tidak bisa dipatenkan jika hanya
  mengimplementasikan "ide abstrak" tanpa elemen
  teknis tambahan yang signifikan
• Ribuan paten software ada di AS

UNI EROPA (EPO):
• Pasal 52 EPC: program komputer sebagai such
  dikecualikan dari patenabilitas
• Namun: "computer-implemented inventions" (CII)
  yang memiliki "technical character" BISA dipatenkan
• Praktiknya: banyak paten software lolos lewat celah ini

INDONESIA (DJKI):
• UU Paten No. 13/2016 Pasal 4: mengecualikan dari
  paten antara lain: program komputer, skema,
  aturan dan metode untuk melakukan kegiatan bisnis
• Artinya: KODE PROGRAM tidak bisa dipatenkan
• TETAPI: invensi yang MENGGUNAKAN software sebagai
  bagian dari sistem teknis yang lebih luas
  MUNGKIN bisa dipatenkan

Contoh praktis di Indonesia:

Mengapa Paten Software Kontroversial?

PRO PATEN SOFTWARE:            KONTRA PATEN SOFTWARE:
──────────────────             ──────────────────────
Mendorong R&D dan              Menciptakan "patent thicket"
inovasi baru                   (ribuan paten tumpang tindih
                               yang harus dinavigasi)

Memberi perusahaan             Mengancam inovasi independen
aset yang bisa                 dan startup yang tidak mampu
dimonetisasi                   membayar lisensi paten

Perlindungan lebih             Troll paten (entitas yang
kuat dari hak cipta            mengakuisisi paten untuk
(melindungi fungsi,            mengajukan gugatan, bukan
bukan hanya kode)              untuk berinovasi)

                               Siklus inovasi software
                               terlalu cepat untuk 20
                               tahun perlindungan paten

11.3.3 Trade Secret (Rahasia Dagang)

Trade secret adalah informasi bisnis yang secara aktif dirahasiakan dan memberikan keunggulan kompetitif karena kerahasiaannya.

Dasar Hukum Indonesia: UU No. 30 Tahun 2000 tentang Rahasia Dagang.

Contoh trade secret dalam industri software:

• Algoritma rekomendasi Google yang tidak dipublikasikan.
• Kode sumber proprietary yang tidak pernah dirilis.
• Formula/model pricing platform e-commerce.
• Dataset pelatihan model AI yang dikurasi secara khusus.

Perbedaan kunci trade secret vs. hak cipta:

Kasus: Apakah kode sumber yang dipublikasikan masih trade secret? TIDAK. Begitu kode sumber dipublikasikan (bahkan di GitHub sebagai open source), ia bukan lagi trade secret. Inilah mengapa perusahaan harus memilih strategi HKI dengan cermat: open source vs. closed source adalah keputusan bisnis sekaligus keputusan hukum.

11.3.4 Merek Digital

Merek melindungi identitas komersial produk — nama, logo, slogan — dari penggunaan oleh pihak yang tidak berwenang.

Dasar Hukum Indonesia: UU No. 20 Tahun 2016 tentang Merek dan Indikasi Geografis.

Relevansi merek dalam ekosistem digital:

MEREK DIGITAL: CONTOH NYATA

Nama Produk:
"Tokopedia", "Gojek", "Traveloka", "DANA"
→ Nama-nama ini adalah merek terdaftar yang dilindungi.
→ Membuat aplikasi bernama "Toko-pedia" atau "GoJek2" bisa
  dianggap pelanggaran merek (passing off / infringement).

Domain dan Merek:
→ Mendaftarkan domain yang mengandung merek orang lain
  (cybersquatting) dapat dianggap pelanggaran merek.
→ Indonesia mengatur sengketa domain via IDNC (Indonesia
  Network Information Center).

App Store / Play Store:
→ Mengunggah aplikasi dengan nama serupa dengan aplikasi
  populer (misalnya "WhatsApp Plus") untuk menipu pengguna
  adalah pelanggaran merek + berpotensi fraud.

BAGIAN 11.4 — LISENSI PERANGKAT LUNAK OPEN SOURCE

11.4.1 Apa Itu Open Source?

Open source bukan berarti "gratis" atau "bebas tanpa syarat." Open source memiliki definisi teknis yang ketat dari Open Source Initiative (OSI):

"Open source software is software that can be freely used, modified, and shared by anyone." — Open Source Initiative

Untuk mendapat label "open source" dari OSI, sebuah lisensi harus memenuhi 10 kriteria (Open Source Definition), termasuk:

• Distribusi bebas.
• Kode sumber tersedia.
• Izin modifikasi dan karya turunan.
• Tidak diskriminatif terhadap siapapun atau bidang penggunaan.

Mengapa pengembang profesional harus paham lisensi OSS?

SKENARIO NYATA YANG SERING DIABAIKAN DEVELOPER:

Developer A membangun aplikasi SaaS komersial.
Ia menggunakan library open source untuk backend.
Ia deploy produk dan mulai mengenakan biaya ke pelanggan.

Pertanyaan: Apakah tindakan ini legal?

JAWABAN: TERGANTUNG LISENSINYA.

Jika library berlisensi MIT → Legal, boleh komersial.
Jika library berlisensi GPL v3 → MASALAH BESAR:
  - Developer A wajib merilis kode sumbernya.
  - Jika tidak, ia melanggar lisensi GPL.
  - Bisa kena tuntutan dari pencipta library.

Ignorantia juris non excusat: "Tidak tahu hukum bukan alasan."
Ribuan startup dan pengembang telah menghadapi masalah hukum
karena tidak membaca lisensi OSS yang mereka gunakan.

11.4.2 Spektrum Lisensi Open Source: Dari Copyleft ke Permisif

Semua lisensi OSS dapat dipetakan dalam satu spektrum berdasarkan seberapa banyak kebebasan yang diberikan kepada pengguna:

SPEKTRUM LISENSI OPEN SOURCE

KETAT ←─────────────────────────────────────────→ BEBAS
(Copyleft Kuat)     (Copyleft Lemah)      (Permisif)

      GPL v3          LGPL v3          Apache 2.0
      GPL v2          LGPL v2          MIT License
      AGPL v3         MPL 2.0          BSD 2/3-Clause
                      EUPL             ISC License

"Viral effect"      "Weak copyleft"    "Do whatever you
Turunan HARUS        Hanya modul OSS    want, just
menggunakan          yang copyleft,     credit the author"
lisensi yang sama    bukan seluruh
                     produk

11.4.3 Analisis Mendalam Per Jenis Lisensi

GPL (GNU General Public License) — Copyleft Kuat

Dibuat oleh: Richard Stallman & Free Software Foundation (FSF) Versi utama: GPL v2 (1991), GPL v3 (2007) Proyek terkenal: Linux Kernel (GPL v2), GIMP, WordPress (GPL v2+)

Prinsip inti GPL: Copyleft / "Viral Effect"

CARA KERJA GPL (COPYLEFT)

Anda mengambil kode GPL
         │
         ▼
Anda memodifikasi atau membangun
software yang menggunakan kode GPL tersebut
         │
         ▼
Anda mendistribusikan software tersebut
(baik gratis maupun berbayar)
         │
         ▼
KEWAJIBAN GPL BERLAKU:
• Anda WAJIB merilis kode sumber lengkap
  (termasuk modifikasi Anda)
• Kode yang dirilis WAJIB menggunakan lisensi GPL
  yang sama (atau kompatibel)
• Anda harus menyertakan teks lisensi GPL
• Anda tidak boleh menambahkan pembatasan tambahan
  di atas GPL

Perbedaan GPL v2 vs GPL v3:

Apa "celah SaaS" GPL? Jika Anda menjalankan software GPL di server Anda sendiri dan hanya memberikan akses melalui web (SaaS), Anda tidak "mendistribusikan" software tersebut — sehingga kewajiban copyleft tidak berlaku. Ini mengapa Google bisa menggunakan banyak komponen GPL tanpa merilis kode sumber Google Search.

AGPL v3 (Affero GPL) menutup celah ini: jika software AGPL digunakan untuk memberikan layanan jaringan, kode sumber tetap wajib dirilis.

LGPL (GNU Lesser General Public License) — Copyleft Lemah

Dibuat oleh: FSF, sebagai "kompromi" GPL untuk library Versi utama: LGPL v2.1, LGPL v3 Proyek terkenal: GNU C Library (glibc), FFmpeg, Qt

Mengapa LGPL diciptakan? FSF menyadari bahwa jika semua library menggunakan GPL, pengembang komersial tidak akan bisa menggunakannya sama sekali. LGPL memberikan keseimbangan: library bisa digunakan dalam produk proprietary, tetapi modifikasi pada library itu sendiri tetap harus open.

CARA KERJA LGPL

Aplikasi Anda (Proprietary)
         │
         │ Menggunakan via dynamic linking
         ▼
Library LGPL (misal: FFmpeg)
         │
         │ Kewajiban LGPL:
         ▼
Jika Anda memodifikasi LIBRARY LGPL:
→ Modifikasi library WAJIB dirilis sebagai LGPL

Jika Anda HANYA MENGGUNAKAN library tanpa memodifikasinya:
→ Aplikasi Anda BOLEH proprietary/closed source

Perbedaan krusial: Dynamic vs. Static Linking

MPL 2.0 (Mozilla Public License) — Copyleft File-Level

Dibuat oleh: Mozilla Foundation Proyek terkenal: Mozilla Firefox, Mozilla Thunderbird

MPL 2.0 adalah "copyleft per file" — hanya file yang diambil dari MPL yang harus tetap MPL, sementara file lain dalam proyek yang sama bisa menggunakan lisensi berbeda. Ini memberikan fleksibilitas antara GPL dan LGPL.

MIT License — Permisif Paling Populer

Asal: Massachusetts Institute of Technology Proyek terkenal: React, jQuery, Rails, Node.js, .NET (MIT), Bootstrap

TEKS INTI MIT LICENSE (DITERJEMAHKAN):

"Izin diberikan secara gratis kepada siapapun yang
mendapatkan salinan perangkat lunak ini dan file
dokumentasi terkait ("Perangkat Lunak"), untuk
berurusan dengan Perangkat Lunak tanpa batasan,
termasuk tanpa batasan hak untuk menggunakan,
menyalin, memodifikasi, menggabungkan, menerbitkan,
mendistribusikan, mensublisensikan, dan/atau menjual
salinan Perangkat Lunak...

DENGAN SYARAT BERIKUT:
Pemberitahuan hak cipta di atas dan pemberitahuan
izin ini HARUS disertakan dalam semua salinan atau
bagian substansial dari Perangkat Lunak."

Kewajiban MIT yang sering diabaikan: Anda WAJIB menyertakan teks lisensi MIT dan pemberitahuan hak cipta asli dalam distribusi Anda — bahkan dalam produk komersial.

Apache License 2.0 — Permisif dengan Perlindungan Paten

Dibuat oleh: Apache Software Foundation Proyek terkenal: Apache HTTP Server, Kubernetes, TensorFlow, Android (AOSP)

Apache 2.0 mirip MIT dalam kebebasannya, tetapi memiliki dua fitur tambahan yang penting:

Fitur 1 — Grant Paten Eksplisit: Kontributor memberikan lisensi paten implisit atas paten yang mungkin mereka miliki terkait kontribusinya. Ini melindungi pengguna dari gugatan paten dari kontributor.

Fitur 2 — Klausul Terminasi Paten: Jika Anda mengajukan gugatan paten terhadap Apache 2.0 software, lisensi Anda atas software tersebut secara otomatis berakhir.

Implikasi: Apache 2.0 lebih "ramah paten" untuk perusahaan dibanding MIT.

BSD License — Permisif Klasik

Asal: University of California, Berkeley Varian: BSD 2-Clause (Simplified), BSD 3-Clause (New), BSD 4-Clause (Original)

BSD 3-Clause menambahkan satu ketentuan dibanding 2-Clause: tidak boleh menggunakan nama pemegang hak cipta untuk endorsement tanpa izin tertulis.

11.4.4 Kompatibilitas Lisensi: Puzzle yang Harus Diselesaikan

Ketika menggabungkan komponen dari beberapa lisensi dalam satu produk, Anda harus memastikan lisensi-lisensi tersebut kompatibel satu sama lain:

MATRIKS KOMPATIBILITAS LISENSI OSS

Lisensi    Dapat digabung dengan:
produk Anda  MIT    BSD    Apache 2.0   LGPL   GPL v2   GPL v3
──────────────────────────────────────────────────────────────
Proprietary  ✓      ✓      ✓           ✓*     ✗        ✗
MIT          ✓      ✓      ✓           ✓      ✓        ✓
Apache 2.0   ✓      ✓      ✓           ✓      ✗        ✓
LGPL         ✓      ✓      ✓           ✓      ✓        ✓
GPL v2       ✓      ✓      ✗**         ✓      ✓        ✗
GPL v3       ✓      ✓      ✓           ✓      ✓        ✓

✓ = Kompatibel (dapat digabungkan)
✗ = Tidak kompatibel (JANGAN digabungkan)
✓* = Dengan catatan (perhatikan kewajiban LGPL)
✗** = GPL v2 dan Apache 2.0 diketahui tidak kompatibel oleh FSF
      karena Apache 2.0 memiliki klausul paten yang tidak ada
      di GPL v2

Contoh konflik nyata: GPL v2 × Apache 2.0 Linux Kernel menggunakan GPL v2. Android (AOSP) menggunakan Apache 2.0. Karena keduanya tidak kompatibel, Google harus sangat berhati-hati dalam memastikan komponen GPL v2 di kernel tidak "mengkontaminasi" kode Android yang berlisensi Apache 2.0. Solusinya: Linux Kernel yang digunakan di Android memiliki klausul khusus "syscall exception" yang memungkinkan aplikasi userspace berlisensi berbeda.

11.4.5 Lima Proyek OSS yang Wajib Dikenal Developer Indonesia

Catatan khusus WordPress: WordPress Foundation menyatakan bahwa tema dan plugin WordPress yang berjalan di atas WordPress inti adalah "karya turunan" dari WordPress dan karenanya wajib berlisensi GPL. Ini adalah posisi kontroversial yang telah menjadi sumber banyak debat dan sengketa hukum dalam komunitas WordPress.

BAGIAN 11.5 — INSTRUMEN INTERNASIONAL HKII DIGITAL

11.5.1 Arsitektur Perlindungan HKI Internasional

HIERARKI PERJANJIAN HKI INTERNASIONAL

        WIPO (World Intellectual Property Organization)
        PBB, berdiri 1967, 193 negara anggota
                │
    ┌──────────┬┴──────────┬────────────┐
    │          │            │            │
    ▼          ▼            ▼            ▼
Berne       TRIPS          WCT          WPPT
Convention  Agreement    (1996)        (1996)
(1886/1979) (WTO, 1994)
"Hak cipta  "Standar     "Hak cipta   "Pertunjukan
dasar"      minimum       digital"     & rekaman"
            HKI global"

Indonesia adalah anggota WIPO dan WTO, sehingga terikat pada Berne Convention (melalui TRIPs) dan telah meratifikasi WCT serta WPPT.

11.5.2 Berne Convention for the Protection of Literary and Artistic Works

Lahir: 1886, direvisi berkali-kali, versi terbaru 1979 Prinsip-prinsip utama:

1. Perlindungan Otomatis (No Formalities) Hak cipta lahir otomatis tanpa pendaftaran — prinsip yang juga diadopsi UU Indonesia.

2. National Treatment (Perlakuan Nasional) Setiap negara anggota harus memberikan perlindungan yang sama kepada karya dari negara anggota lain seperti kepada karya warga negaranya sendiri.

Implikasi: Kode yang Anda tulis di Indonesia dilindungi hak cipta di semua negara anggota Berne (163+ negara) tanpa perlu mendaftar di masing-masing negara.

3. Masa Perlindungan Minimum Berne mensyaratkan minimum perlindungan seumur hidup pencipta + 50 tahun untuk sebagian besar karya. Banyak negara (termasuk UE dan AS) menerapkan + 70 tahun.

11.5.3 WIPO Copyright Treaty (WCT, 1996)

WCT adalah "perjanjian internet" yang mengadaptasi Berne Convention untuk era digital. Dua ketentuan terpenting:

1. Perlindungan terhadap Circumvention TPM (Anti-Circumvention)

Negara anggota wajib melindungi Technological Protection Measures (TPM) — yaitu teknologi seperti DRM (Digital Rights Management) yang digunakan untuk membatasi penggunaan karya digital.

CONTOH TPM YANG DILINDUNGI WCT:

DRM di e-book      → mencegah penyalinan/print berlebihan
Enkripsi Blu-ray   → mencegah ripping DVD
Region lock        → mencegah penggunaan konten lintas region
Watermark digital  → mencegah distribusi tidak sah
License key        → membatasi instalasi software proprietary

YANG DILARANG WCT:
• Membuat, menjual, atau mendistribusikan alat untuk
  membobol TPM/DRM
• Membobol TPM untuk mendapat akses tidak sah

KONTROVERSI:
• Larangan anti-circumvention terlalu luas?
• Bagaimana dengan security researchers yang perlu
  "membobol" DRM untuk menemukan kerentanan?
• Bagaimana dengan preservation (pengarsipan karya lama)?

2. Perlindungan Rights Management Information (RMI) Melarang penghapusan atau manipulasi metadata yang mengidentifikasi pencipta dan ketentuan penggunaan karya.

11.5.4 DMCA (Digital Millennium Copyright Act, AS, 1998)

Meskipun DMCA adalah hukum Amerika Serikat, ia sangat relevan secara global karena sebagian besar platform digital besar (Google, YouTube, GitHub, Meta) tunduk pada DMCA:

Dua Ketentuan DMCA yang Paling Berpengaruh Global:

Ketentuan 1: Anti-Circumvention (Pasal 1201)

Melarang pembuatan atau distribusi alat untuk membobol TPM/DRM. Lebih ketat dari WCT.

Dampak kontroversial: Seorang peneliti keamanan yang menemukan kerentanan dalam software dengan DRM berpotensi melanggar DMCA meskipun tujuannya legitimate (security research exception ada, tapi terbatas).

Ketentuan 2: Safe Harbor untuk Platform (Pasal 512)

Ini adalah ketentuan yang membentuk internet modern sebagaimana kita kenal:

SAFE HARBOR DMCA (Pasal 512) — Cara Kerjanya:

TANPA SAFE HARBOR:
YouTube bertanggung jawab atas SETIAP video yang
mengandung konten berhak cipta yang diunggah pengguna
→ YouTube secara teoritis harus memeriksa setiap video
  sebelum diunggah → mustahil secara operasional
→ YouTube tidak akan pernah ada

DENGAN SAFE HARBOR:
Platform online (ISP, hosting, platform berbagi konten)
TIDAK bertanggung jawab atas konten yang diunggah pengguna
ASALKAN:
1. Tidak mengetahui konten pelanggaran tersebut
2. Tidak mendapat manfaat finansial langsung dari pelanggaran
3. Segera menghapus konten setelah menerima DMCA Takedown Notice

MEKANISME NOTICE AND TAKEDOWN:
Pemegang hak cipta → Kirim DMCA Notice ke platform
         │
         ▼
Platform menerima notice
         │
         ▼
Platform menghapus/blokir konten tersebut
         │
         ▼
Pengunggah bisa mengajukan counter-notice jika konten
dianggap tidak melanggar (fair use, dll.)

Mengapa ini penting untuk developer Indonesia? Jika Anda mengunggah kode ke GitHub dan seseorang mengajukan DMCA notice yang mengklaim kode Anda melanggar hak cipta mereka, GitHub akan menghapus repositori Anda. Ini adalah praktik yang nyata dan sering digunakan (dan juga sering disalahgunakan).

11.5.5 Posisi Indonesia dalam Sistem HKI Internasional

Implikasi belum meratifikasi WCT: Indonesia belum secara resmi terikat kewajiban perlindungan anti-circumvention DRM. Namun, UU Hak Cipta 2014 Pasal 52–54 telah mengadopsi beberapa prinsip WCT secara domestik, sehingga perlindungan TPM secara substansial tetap ada.

BAGIAN 11.6 — PELANGGARAN HKI DIGITAL DAN IMPLIKASINYA

11.6.1 Bentuk-Bentuk Pelanggaran HKI dalam Dunia Software

PELANGGARAN HKI YANG UMUM DALAM PENGEMBANGAN SOFTWARE

1. SOFTWARE PIRACY (Pembajakan Perangkat Lunak)
   Menggunakan, mendistribusikan, atau menjual software
   tanpa lisensi yang sah.
   Contoh: Menginstal software berbayar tanpa membeli lisensi;
   Menjual laptop dengan software bajakan pre-installed.
   Ancaman pidana: Pasal 113 UU 28/2014 — penjara maks.
   4 tahun + denda maks. Rp 1 miliar.

2. OSS LICENSE VIOLATION
   Menggunakan komponen OSS tanpa memenuhi ketentuan lisensinya.
   Contoh: Menggunakan kode GPL tanpa merilis kode sumber;
   Menghapus copyright notice dari kode MIT.
   Risiko: Gugatan perdata dari pemegang lisensi; kewajiban
   menghapus produk dari pasar.

3. PLAGIARISME KODE (Code Plagiarism)
   Menyalin kode orang lain dan mengklaim sebagai karya sendiri.
   Relevan juga untuk: menyerahkan kode orang lain sebagai
   tugas akademik.
   Risiko: Sanksi akademik + potensi gugatan hak cipta.

4. REVERSE ENGINEERING ILLEGAL
   Membongkar kode yang dikompilasi untuk menduplikasi
   fungsionalitas proprietary.
   Catatan: Reverse engineering untuk INTEROPERABILITAS
   diizinkan dalam banyak yurisdiksi (termasuk UE).
   Tetapi reverse engineering untuk menduplikasi produk
   pesaing adalah pelanggaran.

5. PENGGUNAAN ASET TANPA IZIN
   Menggunakan gambar, musik, font, atau aset kreatif
   berhak cipta dalam produk digital tanpa izin.
   Contoh: Menggunakan foto dari Google Images sebagai aset
   UI tanpa lisensi.
   Solusi: Gunakan aset dengan lisensi Creative Commons
   (CC0, CC BY) atau bayar lisensi komersial.

11.6.2 Sanksi Pidana Pelanggaran Hak Cipta

UU No. 28/2014 tentang Hak Cipta — Bab X Ketentuan Pidana:

Catatan: Ini adalah delik aduan — artinya, proses pidana baru bisa berjalan setelah pemegang hak cipta mengajukan aduan. Berbeda dengan delik umum yang bisa diproses tanpa aduan korban.

11.6.3 Kasus Nyata: Sengketa HKI Software

Kasus Oracle v. Google (AS, 2010–2021): Oracle menggugat Google karena Android menggunakan API Java. Pertanyaan hukumnya: apakah API (antarmuka pemrograman) dilindungi hak cipta? Setelah 11 tahun, Mahkamah Agung AS memutuskan (2021): penggunaan Google atas 11.500 baris kode API Java adalah fair use — bukan pelanggaran hak cipta. Putusan ini sangat signifikan bagi industri software global karena memberi kepastian bahwa API tidak bisa dimonopoli.

Kasus WordPress vs. WooThemes/Premium Themes: WordPress Foundation menyatakan semua tema dan plugin yang "derived from" WordPress wajib GPL. Beberapa developer tema premium menolak dan menggunakan lisensi split (GPL untuk PHP, proprietary untuk CSS/JS). Hingga kini perdebatan tentang apa yang masuk "derived work" WordPress terus berlangsung.

Relevansi untuk Indonesia: Indonesia belum memiliki yurisprudensi yang kaya dalam sengketa HKI software. Namun dengan semakin berkembangnya industri teknologi, sengketa semacam ini akan semakin sering muncul.

BAGIAN 11.7 — AUDIT LISENSI: PRAKTIK PROFESIONAL PENGEMBANG

11.7.1 Mengapa Audit Lisensi Diperlukan

Setiap proyek software modern menggunakan puluhan bahkan ratusan dependensi OSS. Tanpa audit lisensi yang terstruktur, risiko pelanggaran hukum sangat nyata.

Contoh skala dependensi dalam proyek modern:

RATA-RATA DEPENDENSI PROYEK SOFTWARE MODERN (2024)

Aplikasi Node.js menengah:
node_modules dapat berisi 500–2.000+ paket
dengan berbagai lisensi berbeda

Proyek Python (pip):
Puluhan hingga ratusan package dengan
lisensi MIT, Apache, BSD, LGPL, GPL campur aduk

Android App:
Bisa menggunakan 50–200+ library dengan
lisensi yang perlu diaudit sebelum rilis

11.7.2 Alat Bantu Audit Lisensi OSS

11.7.3 Software Bill of Materials (SBOM)

SBOM (Software Bill of Materials) adalah inventarisasi formal semua komponen dalam sebuah produk software, termasuk lisensi masing-masing. Konsep ini semakin penting:

• Presiden AS mengeluarkan Executive Order (2021) yang mewajibkan SBOM untuk software yang dijual ke pemerintah federal.
• Uni Eropa dalam Cyber Resilience Act (2024) mewajibkan SBOM untuk produk digital.
• Standar internasional: SPDX (ISO/IEC 5962) dan CycloneDX.

BAGIAN 11.8 — PERSPEKTIF ISLAMI: HARTA INTELEKTUAL SEBAGAI AMANAH DAN HAK

Hak Kekayaan Intelektual dalam Perspektif Islam

Prinsip-prinsip Islam memberikan panduan yang relevan tentang bagaimana memperlakukan karya intelektual:

1. Hak Kepemilikan yang Diperoleh Melalui Kerja (Al-Milk)

Islam mengakui kepemilikan yang diperoleh melalui usaha dan kerja (kasb):

"Wa an laysa lil-insāni illā mā sa'ā" "Dan bahwa manusia hanya mendapatkan apa yang telah diusahakannya" (QS. An-Najm: 39)

Kode yang ditulis programmer adalah hasil kerja kreatif yang nyata. Islam mengakui hak programmer atas karyanya sebagai bentuk kepemilikan yang sah.

2. Larangan Mengambil Hak Orang Lain

"Wa lā ta'kulū amwālakum baynakum bil-bāṭil" "Dan janganlah kamu memakan harta sesama kamu dengan cara yang batil" (QS. Al-Baqarah: 188)

Pembajakan software adalah pengambilan hasil kerja orang lain tanpa bayaran yang adil — ini adalah "memakan harta secara batil" yang dilarang Islam.

3. Amanah dalam Kontrak Lisensi

Ketika Anda menerima lisensi software (GPL, MIT, atau komersial), Anda telah membuat perjanjian dengan pencipta — dan Islam sangat menekankan pemenuhan janji:

"Yā ayyuhā alladhīna āmanū awfū bil-'uqūd" "Hai orang-orang beriman, penuhilah akad-akad itu" (QS. Al-Maidah: 1)

Menggunakan software GPL tanpa memenuhi kewajiban copyleft adalah pelanggaran perjanjian yang bertentangan dengan nilai ini.

4. Ijtihad dan Kontroversi HKI dalam Fiqh Kontemporer

Para ulama kontemporer berbeda pendapat tentang HKI:

PANDANGAN ULAMA TENTANG HKI INTELEKTUAL

MENDUKUNG PERLINDUNGAN HKI:
• Lembaga Fikih OKI (Organisasi Kerjasama Islam) dalam
  keputusannya mengakui hak kekayaan intelektual dan
  melarang pelanggarannya
• Argumen: hak atas hasil karya adalah prinsip syariah
• Contoh negara: Malaysia (fatwa HKI dilindungi)

LEBIH BERHATI-HATI ATAU MENOLAK:
• Beberapa ulama berpendapat pengetahuan/ilmu harus
  disebarkan secara luas demi maslahat umum
• Argumen: monopoli pengetahuan bertentangan dengan
  semangat penyebaran ilmu dalam Islam
• Khusus software: ada argumen bahwa software untuk
  kemaslahatan umum (pendidikan, kesehatan) harus
  lebih mudah diakses

POSISI TENGAH (YANG BANYAK DIADOPSI):
• HKI diakui, tapi ada batasan untuk kepentingan umum
• Konsep "fair use" dalam hukum positif sejalan dengan
  maslahah dalam fiqh
• Lisensi open source dapat dipandang sebagai bentuk
  infaq/sedekah ilmu yang dianjurkan Islam

Implikasi bagi Pengembang Muslim:

• Menghormati lisensi software yang Anda gunakan adalah kewajiban moral dan spiritual.
• Memilih mengembangkan open source adalah pilihan mulia yang menyebarkan manfaat.
• Membantu komunitas dengan kontribusi open source adalah bentuk sadaqah jariyah (amal yang terus mengalir) dalam era digital.

AKTIVITAS PEMBELAJARAN PERTEMUAN 11

Jadwal Sesi (100 Menit)

Workshop Analisis Lisensi (40 Menit)

Tujuan: Mahasiswa dapat menentukan apakah sebuah komponen OSS dapat digunakan dalam proyek komersial dan kewajiban apa yang menyertainya.

Pembagian Kelompok: 5 kelompok, masing-masing 1 proyek OSS.

INSTRUKSI UMUM UNTUK SEMUA KELOMPOK:

Analisis proyek OSS yang diberikan kepada kelompok Anda dengan menjawab keempat pertanyaan berikut. Siapkan presentasi singkat 3 menit di akhir workshop.

Pertanyaan yang harus dijawab:

Q1 — Identifikasi Lisensi (5 menit): Cari dan catat lisensi yang digunakan oleh proyek ini. Di mana Anda menemukannya? (file LICENSE, README, SPDX identifier dalam kode, dll.)

Q2 — Kategori Lisensi (10 menit): Masukkan lisensi ini ke dalam kategori yang tepat: copyleft kuat / copyleft lemah / permisif. Jelaskan mengapa.

Q3 — Analisis Penggunaan Komersial (15 menit): Skenario: Kelompok Anda adalah startup yang akan membangun aplikasi berbayar menggunakan proyek ini sebagai komponen. Bolehkah Anda:

• Menggunakan komponen ini tanpa merilis kode sumber aplikasi Anda? (Ya/Tidak/Kondisional)
• Mendistribusikan produk Anda secara komersial tanpa membayar royalti? (Ya/Tidak/Kondisional)
• Memodifikasi komponen ini sesuai kebutuhan tanpa menginformasikan siapapun? (Ya/Tidak/Kondisional)

Untuk setiap jawaban "Ya": pastikan teks lisensi mendukung jawaban Anda. Untuk setiap jawaban "Tidak": jelaskan konsekuensi hukumnya. Untuk setiap jawaban "Kondisional": jelaskan kondisinya.

Q4 — Rekomendasi (5 menit): Berdasarkan analisis Anda, apa satu hal yang wajib dilakukan startup ini sebelum merilis produk komersial yang menggunakan komponen ini?

KELOMPOK 1: Linux Kernel

• Lisensi: GPL v2 (dengan "Linux Syscall Note")
• Konteks: Startup ingin mengembangkan sistem operasi embedded berbasis Linux untuk perangkat IoT yang akan dijual ke konsumen.
• Pertanyaan tambahan: Apakah "Linux Syscall Note" mengubah kewajiban GPL v2 untuk aplikasi yang berjalan di atas kernel? Cari di: kernel.org/doc/html/latest/

KELOMPOK 2: React (Meta)

• Lisensi: MIT License
• Konteks: Startup ingin membangun aplikasi web SaaS berbayar menggunakan React sebagai framework frontend.
• Pertanyaan tambahan: Pada masa lalu (2017), React menggunakan lisensi "BSD + Patents" yang kontroversial. Cari apa yang terjadi dan mengapa Meta akhirnya beralih ke MIT. Pelajaran apa yang bisa diambil tentang bagaimana lisensi OSS bisa berubah?

KELOMPOK 3: TensorFlow (Google)

• Lisensi: Apache License 2.0
• Konteks: Startup AI ingin menggunakan TensorFlow untuk membangun produk machine learning komersial. Mereka mungkin akan mendapat paten atas model AI mereka di masa depan.
• Pertanyaan tambahan: Bagaimana klausul paten di Apache 2.0 berinteraksi dengan rencana startup untuk memiliki paten? Apakah menggunakan TensorFlow bisa membatasi kemampuan startup untuk mengajukan gugatan paten terhadap Google di masa depan?

KELOMPOK 4: WordPress

• Lisensi: GPL v2 (atau versi yang lebih baru)
• Konteks: Startup ingin membangun dan menjual tema premium WordPress melalui platform mereka sendiri dengan harga Rp 500.000 per tema.
• Pertanyaan tambahan: WordPress Foundation menyatakan semua tema WordPress wajib GPL. Cari posisi resmi ini di wordpress.org/about/license/ dan evaluasi apakah Anda setuju secara hukum atau tidak, serta apa implikasinya bagi bisnis startup ini.

KELOMPOK 5: SQLite

• Lisensi: Public Domain (+ "blessing" opsional)
• Konteks: Startup mobile app ingin menggunakan SQLite sebagai database embedded dalam aplikasi Android dan iOS mereka yang akan dijual di app store.
• Pertanyaan tambahan: SQLite berada di bawah "public domain" — bukan lisensi OSS formal. Apa bedanya public domain dengan MIT license? Apakah ada risiko hukum menggunakan software public domain dibanding software berlisensi formal? (Petunjuk: pertimbangkan jurisdiksi yang tidak mengakui konsep public domain)

Lembar Kerja Workshop

(Dikumpulkan di akhir pertemuan — dinilai sebagai komponen Tugas & Kuis)

LEMBAR KERJA WORKSHOP ANALISIS LISENSI OSS
Pertemuan 11 — INF2505 Hukum dan Kebijakan Teknologi Informasi

Nama Kelompok  : _________________________________
Anggota        : 1. ___________________________
                 2. ___________________________
                 3. ___________________________
                 4. ___________________________
Proyek OSS     : _________________________________

Q1 — Identifikasi Lisensi

Nama lisensi lengkap: __________________________________ SPDX Identifier (jika ada): __________________________ Lokasi teks lisensi: _________________________________ Versi lisensi: _______________________________________

Q2 — Kategori Lisensi

Kategori: ☐ Copyleft kuat ☐ Copyleft lemah ☐ Permisif ☐ Public domain

Alasan kategorisasi (2–3 kalimat):

Q3 — Analisis Penggunaan Komersial

Kewajiban yang wajib dipenuhi (sebutkan minimal 1, atau tulis "Tidak ada"):

Risiko hukum jika kewajiban tidak dipenuhi:

Q4 — Rekomendasi

Satu hal wajib sebelum rilis produk komersial:

Jawaban pertanyaan tambahan khusus kelompok:

EVALUASI PERTEMUAN 11 — PENGUMUMAN TUGAS 7

TUGAS 7 — Analisis Lisensi Perangkat Lunak Open Source

(Individu — Tenggat: 1 hari sebelum Pertemuan 14)

Latar Belakang Tugas: Sebagai pengembang profesional, Anda tidak bisa hanya menulis kode yang baik — Anda juga harus bertanggung jawab atas aspek hukum dari produk yang Anda bangun. Tugas ini mensimulasikan proses pengambilan keputusan legal yang nyata dalam pengembangan produk software komersial.

Deskripsi Tugas: Bayangkan Anda adalah lead developer yang akan membangun satu aplikasi komersial (Anda tentukan sendiri — misalnya: sistem informasi manajemen sekolah, aplikasi e-commerce lokal, platform e-learning, aplikasi keuangan personal, atau aplikasi kesehatan). Anda berencana mengintegrasikan komponen-komponen open source ke dalam aplikasi tersebut.

Lakukan analisis hukum lisensi yang komprehensif dan sampaikan dalam bentuk laporan.

Ketentuan Umum:

• Format: PDF, font Times New Roman atau Arial 12pt, spasi 1,5.
• Panjang: 1.500–2.500 kata (tidak termasuk daftar referensi dan lampiran).
• Cantumkan nama, NIM, kelas, dan tanggal pengumpulan.
• Bahasa: Indonesia, dengan istilah teknis tetap dalam bahasa aslinya.

Sistematika Laporan (Total 100 Poin):

Bagian 1 — Profil Aplikasi yang Dibangun (10 poin)

• Nama aplikasi dan deskripsi singkat fungsinya.
• Target pengguna dan model bisnis (apakah aplikasi gratis, freemium, atau berbayar).
• Platform target (web, Android, iOS, atau lintas platform).
• Mengapa Anda memilih aplikasi ini?

Bagian 2 — Inventarisasi Komponen OSS (25 poin)

Identifikasi minimal 5 library/framework/tool OSS yang akan Anda gunakan dalam aplikasi, dan untuk setiap komponen sebutkan:

Pastikan Anda benar-benar mengecek lisensi komponen tersebut dari sumbernya langsung (repositori GitHub, situs resmi, atau npmjs.com/pypi.org) — jangan hanya mengandalkan asumsi atau "dengar-dengar."

Bagian 3 — Analisis Kompatibilitas Lisensi (40 poin)

Ini adalah bagian terpenting dan yang paling dinilai.

3a. Analisis Per Komponen (20 poin): Untuk setiap komponen, jawab:

• Apa jenis lisensinya (copyleft kuat/lemah/permisif)?
• Apa kewajiban yang ditimbulkan oleh lisensi ini?
• Apakah komponen ini boleh digunakan dalam aplikasi komersial?

3b. Analisis Kompatibilitas Antar Lisensi (20 poin):

• Apakah semua lisensi komponen yang Anda pilih saling kompatibel?
• Apakah ada konflik lisensi? Jika ada, jelaskan konfliknya dan bagaimana Anda akan mengatasinya.
• Apakah model bisnis aplikasi Anda (gratis/berbayar) sesuai dengan semua lisensi yang digunakan?

Bagian 4 — Rekomendasi Lisensi Produk Anda (15 poin)

Berdasarkan analisis di Bagian 3, lisensi apa yang akan Anda gunakan untuk produk aplikasi Anda sendiri?

• Pilih satu lisensi (MIT, Apache 2.0, GPL, proprietary, atau lainnya).
• Jelaskan mengapa lisensi ini paling sesuai dengan model bisnis dan strategi Anda.
• Apa implikasi dari pilihan lisensi ini terhadap komunitas pengembang dan pengguna?

Bagian 5 — Potensi Risiko Hukum dan Mitigasi (10 poin)

Identifikasi minimal 2 risiko hukum HKI yang mungkin dihadapi dalam pengembangan dan distribusi aplikasi Anda, dan jelaskan langkah mitigasi untuk setiap risiko.

Rubrik Penilaian Tugas 7:

Sumber Referensi yang Direkomendasikan untuk Tugas 7:

• Open Source Initiative (OSI): https://opensource.org/licenses (opens in a new tab) (panduan resmi)
• Choose a License: https://choosealicense.com (opens in a new tab) (perbandingan lisensi yang ramah pengguna)
• TLDR Legal: https://tldrlegal.com (opens in a new tab) (ringkasan informal lisensi — verifikasi dengan teks asli)
• GNU Project: https://www.gnu.org/licenses/license-compatibility.html (opens in a new tab) (kompatibilitas GPL)
• FOSSA Blog: https://fossa.com/blog (opens in a new tab) (artikel komersial tentang audit lisensi)
• SPDX License List: https://spdx.org/licenses/ (opens in a new tab) (daftar lengkap SPDX identifiers)

KONEKSI KE PERTEMUAN LAIN

Koneksi ke Pertemuan 9–10 (Cybercrime & Penegakan Hukum)

KETERKAITAN HKI DENGAN CYBERCRIME

P9–P10: "Akses ilegal & pencurian data"   P11: "HKI digital"
─────────────────────────────────────     ─────────────────────
Pasal 32 UU ITE (merusak/                 Pasal 113 UU 28/2014
mengambil data orang lain)           →   (mendistribusikan karya
                                         tanpa hak)

Kode sumber yang dicuri adalah            Pencurian kode adalah
barang bukti dalam penyidikan       →    SEKALIGUS pelanggaran
cybercrime                               hak cipta

Seorang hacker yang                      Dan berpotensi digugat
menyalin kode sumber dari          →    secara perdata oleh
server yang ditembus bisa                pemilik kode atas
dijerat UU ITE                          pelanggaran hak cipta

Koneksi ke Pertemuan 12 (Regulasi AI & Fintech)

Pertanyaan HKI yang akan semakin relevan di P12:

• Siapa pemilik hak cipta atas karya yang dihasilkan AI? Tidak ada konsensus global.
• Apakah data yang digunakan melatih model AI dilindungi hak cipta? Sangat diperdebatkan.
• Apakah output AI yang menyerupai karya berhak cipta adalah pelanggaran? Banyak kasus sedang berjalan di pengadilan (Getty Images vs Stability AI, New York Times vs OpenAI).

Koneksi ke Pertemuan 15 (Etika Profesi TI)

Responsible disclosure yang dibahas di P10 bertemu dengan HKI di P11 dalam dilema: jika seorang researcher menemukan kerentanan dalam software closed source, apakah proses reverse engineering yang perlu dilakukan (untuk memahami kerentanan) melanggar hak cipta pemilik software?

Koneksi ke Pertemuan 16 (UAS + Proyek Legal Audit)

Dalam Proyek Legal Audit, kelompok Anda wajib mengidentifikasi apakah aplikasi yang diaudit memiliki ketentuan lisensi yang jelas:

• Apakah terms of service menyebutkan lisensi yang diberikan kepada pengguna?
• Apakah penggunaan komponen OSS tercantum dalam acknowledgement/credits?
• Apakah ada risiko pelanggaran HKI dalam produk yang diaudit?

KONEKSI KE UAS

Materi Pertemuan 11 termasuk dalam cakupan UAS (P9–P15). Antisipasi tipe soal:

RANGKUMAN MATERI PERTEMUAN 11

DAFTAR REFERENSI

Format APA edisi ke-7

Peraturan Perundang-Undangan

Undang-Undang Nomor 28 Tahun 2014 tentang Hak Cipta. Lembaran Negara Republik Indonesia Tahun 2014 Nomor 266.

Undang-Undang Nomor 13 Tahun 2016 tentang Paten. Lembaran Negara Republik Indonesia Tahun 2016 Nomor 176.

Undang-Undang Nomor 20 Tahun 2016 tentang Merek dan Indikasi Geografis. Lembaran Negara Republik Indonesia Tahun 2016 Nomor 252.

Undang-Undang Nomor 30 Tahun 2000 tentang Rahasia Dagang. Lembaran Negara Republik Indonesia Tahun 2000 Nomor 242.

Perjanjian & Instrumen Internasional

World Intellectual Property Organization. (1979). Berne Convention for the Protection of Literary and Artistic Works (as amended 1979). WIPO. https://www.wipo.int/treaties/en/ip/berne/ (opens in a new tab)

World Intellectual Property Organization. (1996). WIPO Copyright Treaty (WCT). WIPO. https://www.wipo.int/treaties/en/ip/wct/ (opens in a new tab)

World Intellectual Property Organization. (1996). WIPO Performances and Phonograms Treaty (WPPT). WIPO. https://www.wipo.int/treaties/en/ip/wppt/ (opens in a new tab)

Buku

Lessig, L. (2006). Code: Version 2.0. Basic Books. https://codev2.cc/ (opens in a new tab) (Tersedia gratis online — Bab 10 tentang IP di dunia digital)

Samuelson, P. (2016). Intellectual property and the digital economy: Why the anti-circumvention regulations need to be revised. University of California, Berkeley.

Spinello, R. A. (2011). Cyberethics: Morality and law in cyberspace (4th ed.). Jones & Bartlett Learning. (Bab 7 — Intellectual Property)

Artikel Jurnal

Sari, R. N. (2020). Perlindungan hak cipta perangkat lunak di Indonesia. Jurnal Hukum & Teknologi, 3(1), 15–32.

Dokumen Resmi & Panduan

Direktorat Jenderal Kekayaan Intelektual. Informasi & pendaftaran hak cipta. Kementerian Hukum dan HAM RI. https://dgip.go.id (opens in a new tab)

Open Source Initiative. (2024). The open source definition (annotated). OSI. https://opensource.org/osd (opens in a new tab)

Free Software Foundation. (2023). Various licenses and comments about them. GNU. https://www.gnu.org/licenses/license-list.html (opens in a new tab)

Apache Software Foundation. (2004). Apache License, Version 2.0. https://www.apache.org/licenses/LICENSE-2.0 (opens in a new tab)

SPDX Workgroup. (2024). SPDX license list. Linux Foundation. https://spdx.org/licenses/ (opens in a new tab)

Sumber Online

Choose a License. (2024). https://choosealicense.com (opens in a new tab) (Panduan memilih lisensi dari GitHub — sangat praktis untuk developer)

TLDR Legal. (2024). https://tldrlegal.com (opens in a new tab) (Ringkasan informal lisensi OSS — gunakan sebagai referensi awal, verifikasi dengan teks asli)

FOSSA. (2024). Open source license compliance. https://fossa.com (opens in a new tab)

Modul ini adalah bagian dari seri materi kuliah INF2505 — Hukum dan Kebijakan Teknologi Informasi. Materi akan diperbarui setiap semester menyesuaikan perkembangan regulasi HKI digital dan praktik industri open source terkini.

Dosen Pengampu: Mohammad Reza Maulana, M.Kom — Program Studi Informatika, Fakultas Ekonomi dan Bisnis Islam, UIN K.H. Abdurrahman Wahid Pekalongan