Isikliku inseneri peaks ettevõttega ühisettevõtte korral eelnevalt koostama lepingu

Meie büroo, kus endine IT-insener on peajurist, on õigusbüroo, mis võtab vastu õigusnõuandeid mitte ainult ettevõtetelt, vaid ka inseneridelt. Üks tüüpiline näide on konsultatsioon, kus “isikuna, kes on teinud koostööd teatud ettevõttega uue äri edendamiseks, ei saa ta ettevõttelt piisavat jaotust”. Näiteks järgmised olukorrad.

1. Isikuna, kes on IT-insener, on ta algusest peale tegelema uue süsteemi arendamisega ettevõttes, mis ei ole tingimata tugev IT-s.
2. Vastav süsteem on tänu oma heale jõudlusele müüki suurendanud.
3. Kuigi ta on nõudnud aktsiate jaotamist või kasumi jaotamist müügipõhiselt, ei ole ettevõte sellele vastanud.

Selles olukorras selgitame, mida peaks mõtlema isiklik insener, miks selline olukord tekib ja kuidas seda ennetada.

Vaidlused ühisettevõtte osas saab vältida lepinguga

Esiteks, kui järeldusest alustada, on selliste olukordade “ennetamine” tegelikult lihtne. Vastus on lihtne

Et selliseid olukordi vältida, tuleks eelnevalt sõlmida “ühisettevõtte leping”, mis sisaldab järgmisi punkte.

See ongi kogu mõte. Ühisettevõtte lepingus võib näiteks olla järgmised sätted:

• Süsteemi autoriõigused jagatakse enda ja ettevõtte vahel
• Müügitulust saab endale ●%
• Aktsiate üleandmise sätted

Need tuleks kavandada optimaalses tasakaalus ja sõlmida eelnevalt.

Kuid tegelikkuses lükatakse selliste lepingute sõlmimine sageli edasi, mistõttu on ülaltoodud probleemid kergesti esile kerkivad.

• Kui probleemid ilmnevad, milline on õigussuhete olukord?
• Kuidas peaks ühisettevõtte lepingu koostama eelnevalt, milline peaks olema kavandamise strateegia?
• Miks on probleemid sageli esile kerkivad, kui lepingut pole sõlmitud?

Allpool selgitan neid punkte järjekorras.

Programmi lähtekoodi kuuluvus ühisettevõtetes

Nagu ülaltoodud probleemid näitavad, on individuaalse inseneri suurimaks “õiguseks”, mida ta saab ettevõtte ees väita, autoriõigus. Programmi lähtekood on autoriõiguse objektiks olev “teos”. Ja lähtekoodi autoriõiguse kuuluvus määratakse järgmiste reeglite järgi:

1. Põhimõtteliselt kuulub see isikule, kes koodi kirjutas
2. Kui koodi kirjutanud isik on tööle võetud ettevõtte poolt või täidab teatud tingimusi, muutub see “tööalaseks autorluseks” ja kuulub ettevõttele
3. Kui lepingus on sätestatud autoriõiguse kuuluvus, järgitakse seda sätet

Seega:

1. Põhimõtteliselt kuulub see individuaalsele insenerile, kes koodi kirjutas
2. Individuaalne insener ei ole ettevõtte töötaja, seega tööalane autorlus ei kehti
3. Järgitakse lepingulist kuuluvuse sätet, kuid “lepingut” ei ole olemas

Selle põhjal võiks arvata, et autoriõigused kuuluvad individuaalsele insenerile, kuid kui see vaidlus peaks kohtusse jõudma, ei pruugi kohus tingimata sellist otsust teha.

Muuseas, kas süsteemiarenduse leping kehtib ka siis, kui lepingut ei ole, selgitatakse üksikasjalikult allpool toodud artiklis.

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

Kui lepingut pole, muutub otsustamine ebamääraseks

Kuigi see pole süsteemiarenduse projekt, oli juhtum, kus individuaalse disaineri ja tellimuse esitanud ettevõtte vahel vaidlustati autoriõiguse kuuluvus seoses raudteejaama paigaldatava monumentaalse disainiga. Tokyo kõrgem kohus tunnistas 31. mail 2004 (Heisei 16) järgmistel põhjustel:

• Lepingut ei olnud
• Algusest peale oli ettevõtte juhtimisel kavandatud, et monument paigaldatakse jaama ja muid kasutusviise ei olnud ette nähtud
• Ettevõte maksis individuaalsele disainerile tasu

autoriõiguse üleandmist individuaalsest disainerist ettevõttele.

Nii et kui lepingut või muid kirjalikke dokumente pole, otsustatakse, kas autoriõigus on tellijale üle antud või mitte, erinevate asjaolude alusel, otsides tellija ja alltöövõtja mõistlikku tahtmist. Teisisõnu, see muutub väga “ebamääraseks” otsuseks ja selget reeglit pole. Näiteks “kuidas makstakse tasu koodi kirjutamise eest” on üldiselt käsitletud järgmiselt “ebamäärase” otsuse kontekstis:

• Kui makseid tehakse kuutasu vormis → see on hoolduse jms hõlmava täisteenuse tasu ja eriti kui alltöövõtja on isik, hinnatakse seda tõenäoliselt palgalaadse rahana, mis kinnitab autoriõiguse üleminekut tellijale
• Kui hinnangud saadakse iga kord, kui versiooni uuendatakse → seda hinnatakse tõenäoliselt lihtsalt selle versiooni loomise tasuna, eitades autoriõiguse üleminekut tellijale

Kui isiklik insener võtab ettevõttelt tellimuse “ühisettevõtte” vormis, makstakse tasu sageli kuutasu vormis ja selle tulemusena on kalduvus kinnitada autoriõiguse üleminek ettevõttele. Lisaks, vähemalt isikliku inseneri seisukohast, kui kirjalikke dokumente pole, on raske öelda, et “autoriõigus on selgelt minu poolel”.

Need, mis puudutavad programmi lähtekoodi autoriõiguse kuuluvust, on üksikasjalikult selgitatud järgmises artiklis.

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

Mida peaks ühisettevõtte lepingus määratlema

Sellise olukorra põhjuseks on see, et lepingut ei ole eelnevalt koostatud. Võib-olla mõtlete intuitiivselt, et “lepingu eelnevalt koostamine ei ole realistlik”, kuid sellest räägime hiljem. Kõigepealt selgitame, milline peaks olema leping.

Autoriõiguse määratlus

Lepingus peaks olema määratlus autoriõiguse kohta, nagu eespool mainitud. Isiklikust inseneri vaatepunktist on suurim risk, kui teete süsteemiarendust koostöövormis ettevõttega, see, et pärast projekti kasumlikuks muutmist “lõigatakse ära”.

Teisisõnu, isegi kui sõlmite lepingu, mis näiteks “maksab isiklikule insenerile 20% müügitulust”, kui leping ise lõpetatakse, ei saa te lõpuks kasumit teenida. Selleks, et lepingut ei lõpetataks, on oluline omada “õigusi” enda poolel, ja kõige olulisem neist õigustest on autoriõigus. Autoriõiguse kohta

• Autoriõigus kuulub isiklikule insenerile
• Autoriõigus jagatakse ettevõtte ja isikliku inseneri vahel
• Autoriõigus kuulub ettevõttele, kuid ettevõte ei saa seda kasutada ega üle anda ilma isikliku inseneri nõusolekuta

Kui teete selliseid määratlusi, siis ettevõtte vaatepunktist, kui “isiklik insener lõigatakse ära, ei saa ettevõte jätkata”, saab vältida “äralõikamist” ülaltoodud viisil.

Muuseas, IT-süsteemi ja autoriõiguse üldpilti selgitatakse üksikasjalikult järgmises artiklis.

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

Tasu määratlus

Lisaks on tasu määratlus loomulikult vajalik. See ei ole ainult selliste juhtumite puhul, kuid kui teete koostööd ettevõttega, on müügitulu mitte saava poole jaoks kasulikum saada jaotust müügitulu alusel, mitte kasumi alusel. Teisisõnu, näiteks

• Ettevõte maksab isiklikule insenerile süsteemi äritegevuse kasumi ●%
• Ettevõte maksab isiklikule insenerile süsteemi äritegevuse müügitulu ●%

Võimalikult peaks valima viimase. Isiklik insener ei saa täpselt teada, kui palju tulu ettevõttel tekib, kui palju kulusid on, ja kas need kulud on tõesti “äri jaoks”. Müügitulu saamine, kulude maksmine, selle kuluga saadud asjade, näiteks personali juhtimise ja järelevalve, on lõppkokkuvõttes ettevõtte ülesanne. Ja selles kontekstis võib öelda, et müügitulu on kõige lihtsamini mõistetav. On kasulikum saada makseid, mis on lihtsalt arvutatavad ainult lihtsasti mõistetavatest asjadest.

Aktsiate ülekandmise määratlus

Lisaks on võimalik nõuda aktsiate ülekandmist. Kuid käesolevas artiklis ei käsitleta üksikasju, kuid “välistöövõtja isiklik insener, kes tegeleb ühisettevõttega”, näiteks suure hulga aktsiate nõudmine on praktiliselt keeruline. Kui sellisel positsioonil olev väline isik omab märkimisväärset hulka aktsiaid, muutub VC investeering või IPO praktiliselt väga keeruliseks. Näiteks peaks läbirääkimisi pidama realistlikus ulatuses, näiteks 5%.

Miks lepinguid ei koostata ette?

Nagu näha, on olukord, kus isiklik insener teeb ettevõttega “ühisettevõtte” ja selle kohta ei ole olemas lepingut, mis hõlmaks ka tulevaste maksete tegemist, isiklikule insenerile väga “ebasoovitav”. On oluline, et lepingud koostataks ette, kuid paljud inimesed tunnevad, et “kuigi see on nii, on raske lepingut korralikult koostada ja sõlmida”.

See tuleneb tõenäoliselt ettevõtte ja isikliku poole erinevatest arusaamadest “ettevõtluse” suhtes. Alguses tekivad sellised ühisettevõttega seotud vaidlused enamasti järgmise ajakava alusel:

1. Ettevõte ja isiklik insener lepivad kokku, et insener arendab süsteemi uue ettevõtte loomiseks. Sel ajal lepitakse kokku, et insenerile makstakse elamiskulude katmiseks näiteks “300 000 jeni kuus”.
2. Ettevõte hakkab kasumit teenima ja eelnevalt mainitud tasu suureneb veidi.
3. Ettevõte kasvab veelgi, teenides kümneid miljoneid või miljardeid jene.
4. Sel hetkel on inseneri “500 000 jeni kuus” võrreldes ettevõtte kasumiga väike ning süsteemi arendamise hind on võrreldes teiste ettevõtetega odav.
5. Inseneri ja ettevõtte suhted halvenevad.

Isikliku inseneri vaatepunktist on tõsi, et kui ta ei saa esimeses etapis igakuist tasu, tekivad elamiskuludega probleemid. Ja neljandas etapis on “500 000 jeni kuus” tõepoolest väike summa võrreldes:

1. ettevõtte kasumiga
2. summa, mida teine ettevõte oleks süsteemi loomise eest küsinud

Kuid selliseid võrdlusi on ebaõiglane teha. Sest:

1. ettevõte teeb esimeses etapis ettevõtlusse investeeringuid, makstes insenerile ja müügimeestele palka, ilma et oleks kindel, kas see toob kasumit
2. kui teine ettevõte oleks süsteemi loonud, oleksid nad tõenäoliselt kokku leppinud autoriõiguste üleandmises ja ei oleks rääkinud “kasumi jagamisest müügitulude alusel”

Julmalt öeldes, “kui sa said töö eest tasu riskivabalt, kui sa ei teadnud, kas see toob kasumit, siis sul ei ole õigust nõuda kasumi jagamist, kui see lõpuks kasumit toob”. Kohtu otsused on tavaliselt sarnased selle väärtushinnanguga.

Kokkuvõte

Äritegevuse edukuse üle pole algstaadiumis kindlust ja seetõttu võib tunduda, et ühisettevõtte lepingu koostamisele aja kulutamine või advokaadi palkamine on “risk”. Kui äriprojekt lõpuks ebaõnnestub, muutuvad need ajakulud ja kulud “kuludeks”.

Kuid äritegevuse põhiolemus seisneb selles, et “riski võtnud isik saab ülejäägi kasu, kui asjad lähevad hästi”. Isikliku insenerina, kui te võtate selliseid kulusid nagu aeg ja raha, isegi kui te pole kindel, kas see on kasumlik, ja võtate selle riski, siis kui äriprojekt on edukas, saate paremaid tulemusi kui juhul, kui te poleks riski võtnud.

Ühisettevõtte lepingud on paratamatult spetsialiseerunud. Selleks, et vältida tulevasi vaidlusi ja tagada õiglane kasu, on oluline koostada ja sõlmida lepingud, mis selgitavad lepingulisi suhteid, näiteks pöördudes advokaadi poole varajases staadiumis.

Meie büroo poolt lepingute koostamise ja ülevaatamise teenuste tutvustus

Monolis õigusbüroo pakub oma klientidele ja nõustatavatele ettevõtetele mitmesuguseid lepingute koostamise ja ülevaatamise teenuseid, olles IT, interneti ja äriõiguse valdkonnas tugev õigusbüroo.

Lisateabe saamiseks vaadake palun allpool toodud lehte.

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