MONOLITH LAW OFFICE+81-3-6262-3248Hari kerja 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Kontrak yang Harus Dibuat Sebelumnya oleh Insinyur Pribadi dalam Bisnis Bersama dengan Perusahaan

IT

Kontrak yang Harus Dibuat Sebelumnya oleh Insinyur Pribadi dalam Bisnis Bersama dengan Perusahaan

Kantor kami, yang dikepalai oleh mantan insinyur IT sebagai pengacara utama, menerima konsultasi hukum tidak hanya dari perusahaan tetapi juga dari insinyur. Salah satu jenis konsultasi yang kami terima adalah, “Sebagai individu, saya telah bekerja sama dengan perusahaan untuk memulai bisnis baru, tetapi sekarang saya tidak dapat menerima pembagian yang cukup dari perusahaan.” Misalnya, dalam situasi seperti berikut.

  1. Sebagai insinyur individu, saya telah terlibat dalam pengembangan sistem baru oleh perusahaan yang tidak selalu kuat dalam IT sejak awal
  2. Sistem tersebut memiliki kinerja yang baik dan penjualan meningkat
  3. Saya telah meminta pembagian saham atau pembagian keuntungan berdasarkan penjualan, tetapi perusahaan tidak menyetujui ini

Dalam situasi seperti ini, apa yang harus dipikirkan oleh insinyur individu, mengapa situasi seperti ini terjadi, dan bagaimana cara mencegahnya, akan kami jelaskan.

Konflik Terkait Bisnis Patungan Dapat Dicegah Jika Ada Kontrak

Pertama-tama, jika kita menyimpulkan terlebih dahulu, mencegah situasi seperti ini sebenarnya cukup mudah. Jawabannya sederhana

Untuk mengantisipasi situasi seperti ini, sebaiknya Anda membuat ‘Kontrak Bisnis Patungan’ yang mencakup hal-hal berikut sebelumnya.

Itulah yang harus dilakukan. Dalam Kontrak Bisnis Patungan, misalnya, Anda dapat mempertimbangkan untuk menetapkan hal-hal berikut.

  • Hak cipta atas sistem tersebut akan dibagi antara Anda dan perusahaan
  • Persentase penjualan ●% akan didistribusikan kepada Anda
  • Ketentuan tentang transfer saham

Anda harus merancang ini dengan keseimbangan yang optimal dan menandatanganinya sebelumnya.

Namun, dalam praktiknya, penandatanganan kontrak seperti ini cenderung ditunda, dan itulah sebabnya masalah seperti yang disebutkan di atas cenderung muncul.

  • Apabila masalah muncul, bagaimana situasi masalah seperti hubungan hak?
  • Untuk membuat Kontrak Bisnis Patungan sebelumnya, bagaimana strategi yang harus diambil untuk merancangnya?
  • Meskipun demikian, mengapa masalah cenderung muncul jika kontrak belum ditandatangani?

Untuk poin-poin tersebut, saya akan menjelaskannya satu per satu di bawah ini.

Kepemilikan Kode Sumber Program dalam Bisnis Bersama

Hak cipta kode sumber program tidak selalu dimiliki oleh insinyur individu.

Sebagaimana disebutkan di atas, pada tahap masalah ini muncul ke permukaan, hak terbesar yang dapat diklaim oleh seorang insinyur individu terhadap perusahaan adalah hak cipta. Kode sumber program adalah “karya” yang menjadi subjek hak cipta. Dan kepemilikan hak cipta kode sumber mengikuti aturan sebagai berikut:

  1. Secara prinsip, hak cipta dimiliki oleh orang yang menulis kode tersebut
  2. Jika orang yang menulis kode tersebut dipekerjakan oleh perusahaan atau memenuhi kondisi tertentu, ini menjadi “hak cipta pekerjaan” dan dimiliki oleh perusahaan
  3. Jika ada ketentuan tentang kepemilikan hak cipta dalam kontrak, maka harus mengikuti ketentuan tersebut

Oleh karena itu,

  1. Secara prinsip, hak cipta dimiliki oleh insinyur individu yang menulis kode tersebut
  2. Insinyur individu bukan karyawan perusahaan, jadi tidak ada hak cipta pekerjaan
  3. Mengikuti ketentuan kepemilikan dalam kontrak, tetapi tidak ada “kontrak” yang ada

Itulah yang terjadi. Dari ini saja, tampaknya hak cipta akan dimiliki oleh insinyur individu, tetapi jika konflik ini berakhir di pengadilan, pengadilan tidak selalu membuat keputusan seperti itu.

Untuk informasi lebih lanjut tentang apakah kontrak pengembangan sistem dapat dibuat tanpa kontrak, silakan lihat artikel di bawah ini.

https://monolith.law/corporate/system-development-contract[ja]

Jika Tidak Ada Kontrak, Penilaian Menjadi Kabur

Meskipun bukan dalam kasus pengembangan sistem, terjadi perselisihan hak cipta antara desainer individu yang merancang monumen yang akan dipasang di stasiun dan perusahaan yang memesan desain tersebut. Pada tanggal 31 Mei 2004 (Heisei 16), Pengadilan Tinggi Tokyo memutuskan bahwa:

  • Tidak ada kontrak yang ada
  • Monumen tersebut sejak awal direncanakan untuk dipasang di stasiun di bawah pengawasan perusahaan, dan tidak ada penggunaan lain yang dipertimbangkan
  • Perusahaan telah membayar desainer individu sebagai imbalan

Berdasarkan poin-poin tersebut, pengadilan mengakui transfer hak cipta dari desainer individu ke perusahaan.

Dengan demikian, jika tidak ada dokumen seperti kontrak, apakah telah terjadi transfer hak cipta ke pihak yang memberi tugas atau tidak, akan ditentukan dengan mencari keinginan yang masuk akal dari pemberi dan penerima tugas berdasarkan berbagai keadaan. Dengan kata lain, penilaian menjadi sangat ‘kabur’, dan tidak ada aturan yang jelas. Misalnya, “Bagaimana imbalan untuk menulis kode sumber dibayarkan” biasanya ditangani sebagai berikut dalam penilaian ‘kabur’ ini.

  • Jika pembayaran dilakukan dalam bentuk biaya bulanan → Dianggap sebagai imbalan untuk layanan total termasuk pemeliharaan, dan terutama jika penerima tugas adalah individu, cenderung dinilai sebagai pembayaran yang mirip dengan gaji, dan arahnya adalah mengakui transfer hak cipta ke pihak yang memberi tugas
  • Jika estimasi diperoleh setiap kali ada peningkatan versi → Cenderung dinilai sebagai imbalan untuk membuat versi tersebut, dan arahnya adalah menolak transfer hak cipta ke pihak yang memberi tugas

Jika seorang insinyur individu menerima tugas dari perusahaan dalam bentuk ‘bisnis bersama’, imbalannya sering dibayarkan dalam bentuk biaya bulanan, dan sebagai hasilnya, ada kecenderungan untuk lebih mudah mengakui transfer hak cipta ke perusahaan. Selain itu, setidaknya, jika tidak ada dokumen tertulis, situasinya menjadi sulit untuk mengatakan “Hak cipta jelas ada di pihak saya” sebagai insinyur individu.

Untuk detail tentang kepemilikan hak cipta kode sumber, silakan lihat artikel di bawah ini.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Hal yang Harus Ditentukan dalam Kontrak tentang Bisnis Bersama

Alasan mendasar mengapa situasi seperti ini terjadi adalah karena tidak membuat kontrak sebelumnya. Meskipun Anda mungkin berpikir secara intuitif bahwa “membuat kontrak sebelumnya tidak realistis”, kita akan membahas hal tersebut nanti. Pertama, mari kita jelaskan tentang kontrak yang seharusnya ada.

Ketentuan tentang Hak Cipta

Dalam kontrak, seperti yang jelas dari pembicaraan di atas, Anda harus menetapkan ketentuan tentang hak cipta. Dari sudut pandang seorang insinyur individu, risiko terbesar dari “melakukan pengembangan sistem dalam bentuk bisnis bersama dengan perusahaan sebagai individu” adalah “dipotong” setelah proyek tersebut menghasilkan pendapatan.

Dengan kata lain, meskipun Anda mungkin telah menandatangani kontrak seperti “20% dari pendapatan akan dibayarkan kepada insinyur individu”, jika kontrak itu sendiri diakhiri, Anda akhirnya tidak akan bisa mendapatkan pendapatan. Untuk mencegah pengakhiran kontrak, penting untuk “memiliki hak” di pihak Anda, dan hak yang paling penting di antara “hak” tersebut adalah hak cipta. Mengenai hak cipta,

  • Hak cipta milik insinyur individu
  • Hak cipta dibagi antara perusahaan dan insinyur individu
  • Hak cipta milik perusahaan, tetapi perusahaan tidak dapat menggunakan atau mentransfer hak ini tanpa izin dari insinyur individu

Jika Anda menetapkan ketentuan seperti ini, dari sudut pandang perusahaan, “jika Anda memotong insinyur individu, Anda tidak akan bisa melanjutkan bisnis”, jadi Anda bisa mencegah “dipotong” seperti yang dijelaskan di atas.

Selain itu, untuk gambaran umum tentang sistem IT dan hak cipta, silakan lihat artikel di bawah ini untuk penjelasan lebih rinci.

https://monolith.law/corporate/internet-technology-system-copyright-problem[ja]

Ketentuan tentang Pembayaran

Selain itu, tentu saja, ketentuan tentang pembayaran juga diperlukan. Ini bukan hanya untuk kasus seperti ini, tetapi ketika “melakukan bisnis bersama”, pihak yang tidak menghasilkan penjualan lebih menguntungkan jika mendapatkan distribusi berdasarkan penjualan, bukan berdasarkan keuntungan. Dengan kata lain, misalnya

  • Perusahaan akan membayar insinyur individu ●% dari keuntungan bisnis yang berkaitan dengan sistem tersebut
  • Perusahaan akan membayar insinyur individu ●% dari penjualan bisnis yang berkaitan dengan sistem tersebut

Sebisa mungkin, Anda harus memilih yang terakhir. Insinyur individu tidak dapat memahami dengan tepat penjualan yang dihasilkan oleh perusahaan, jumlah biaya, atau apakah biaya tersebut benar-benar “untuk bisnis tersebut”. Mendapatkan penjualan, membayar biaya, dan mengelola dan mengawasi personel yang diperoleh dengan biaya tersebut, pada akhirnya adalah perusahaan. Dan dalam hal itu, penjualan adalah hal yang paling mudah dipahami. Dengan kata lain, lebih menguntungkan untuk menerima pembayaran yang dapat dihitung secara sederhana hanya dari hal-hal yang mudah dipahami.

Ketentuan tentang Transfer Saham

Selain itu, Anda juga bisa meminta transfer saham. Namun, meskipun kami tidak akan membahas secara detail dalam artikel ini, “insinyur kontrak eksternal yang menangani bisnis bersama” meminta banyak saham, misalnya puluhan persen, adalah masalah yang sulit dalam praktiknya. Jika orang luar dengan posisi seperti itu memiliki sejumlah saham, investasi dari VC dan IPO, misalnya, menjadi sangat sulit dalam praktiknya. Anda harus bernegosiasi dalam kisaran yang realistis, seperti 5%, misalnya.

Mengapa Kontrak Tidak Dibuat Sebelumnya

Dalam kontrak bisnis bersama, sebaiknya kita menjelaskan hubungan kontrak antara insinyur independen dan perusahaan.

Seorang insinyur independen yang menjalankan “bisnis bersama” dengan perusahaan tanpa adanya kontrak yang mencakup pembayaran di masa depan, berada dalam situasi yang sangat “tidak menguntungkan”. Penting untuk membuat kontrak sebelumnya, namun banyak orang merasa sulit untuk membuat dan menyelesaikan kontrak sebelumnya.

Ini mungkin disebabkan oleh perbedaan kesadaran tentang “bisnis” antara perusahaan dan individu. Pertama-tama, perselisihan tentang bisnis bersama ini sering terjadi dalam urutan waktu berikut:

  1. Perusahaan dan insinyur independen menugaskan pengembangan sistem kepada insinyur independen untuk memulai bisnis baru. Pada saat itu, gaji seperti “300.000 yen per bulan” disepakati untuk kehidupan insinyur independen.
  2. Bisnis tersebut mulai menghasilkan pendapatan, dan gaji di atas sedikit dinaikkan.
  3. Bisnis tersebut tumbuh lebih lanjut, menghasilkan pendapatan puluhan juta yen atau miliaran yen untuk perusahaan.
  4. Pada tahap ini, jumlah yang diterima oleh insinyur independen, seperti “500.000 yen per bulan”, menjadi kecil dibandingkan dengan keuntungan yang diperoleh perusahaan, dan juga menjadi murah dibandingkan dengan jumlah yang akan diterima jika sistem tersebut dikerjakan oleh perusahaan lain.
  5. Hubungan antara insinyur independen dan perusahaan memburuk.

Dari sudut pandang insinyur independen, memang, jika mereka tidak menerima biaya bulanan pada tahap 1, mereka akan mengalami kesulitan dalam kehidupan mereka. Dan pada tahap 4, memang, jumlah “500.000 yen per bulan” dalam contoh di atas adalah sedikit dibandingkan dengan:

  1. Keuntungan yang diperoleh perusahaan
  2. Jumlah yang akan diterima jika sistem tersebut dibuat oleh perusahaan lain

Namun, membandingkan ini secara sederhana adalah tidak adil secara ekonomi. Karena

  1. Pada tahap 1, perusahaan melakukan investasi awal, membayar gaji kepada insinyur independen dan gaji penjualan, untuk bisnis yang belum diketahui apakah akan menghasilkan pendapatan atau tidak.
  2. Jika perusahaan lain membuat sistem, seharusnya ada ketentuan seperti transfer hak cipta, dan tidak akan ada pembicaraan tentang “pembagian keuntungan berdasarkan pendapatan”.

Jika dikatakan dengan keras, “Jika Anda mendapatkan pembayaran untuk pekerjaan pada tahap di mana Anda tidak tahu apakah akan menguntungkan atau tidak, Anda tidak berhak meminta pembagian keuntungan ketika ternyata menguntungkan.” Keputusan pengadilan juga cenderung menghasilkan penilaian dan kesimpulan yang sama.

Kesimpulan

Di tahap di mana kita sama sekali tidak tahu apakah bisnis akan berhasil atau tidak, memang ada ‘risiko’ dalam menghabiskan waktu untuk membuat kontrak kerjasama bisnis atau membayar biaya kepada pengacara. Jika bisnis tersebut akhirnya gagal, waktu dan biaya yang telah dikeluarkan akan menjadi ‘biaya yang sia-sia’.

Namun, struktur dasar dari bisnis adalah bahwa ‘orang yang menanggung risiko, jika berhasil, akan mendapatkan keuntungan berlebih’. Dari sisi insinyur individu, jika mereka bersedia menanggung ‘risiko’ hingga batas tertentu dengan menghabiskan waktu dan biaya seperti yang disebutkan di atas pada tahap di mana mereka masih tidak tahu apakah akan menguntungkan atau tidak, mereka dapat memperoleh hasil yang lebih baik jika bisnis tersebut berhasil dibandingkan jika mereka tidak menanggung ‘risiko’ tersebut.

Kontrak yang berkaitan dengan kerjasama bisnis pasti akan menjadi hal yang sangat spesialis. Untuk mencegah konflik di masa depan dan juga untuk memastikan keuntungan yang seharusnya didapatkan, sangat penting untuk membuat dan menandatangani kontrak yang menjelaskan hubungan kontrak, seperti meminta bantuan pengacara sejak tahap awal.

Panduan Pembuatan dan Review Kontrak oleh Kantor Kami

Di Kantor Hukum Monolis, sebagai firma hukum yang memiliki keahlian di bidang IT, Internet, dan Bisnis, kami juga menyediakan berbagai layanan lainnya seperti pembuatan dan review kontrak untuk perusahaan klien dan perusahaan yang menjadi konsultan kami.

Untuk detail lebih lanjut, silakan lihat halaman berikut.

https://monolith.law/contractcreation[ja]

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Kembali ke atas