Авторско право върху софтуер, създаден от служител: За кого са правата – за служителя или за фирмата?

Дигиталният актив за милиони и скритият правен риск в IT сектора

В съвременната икономика софтуерният код често е най-ценният актив на една технологична компания – дигитална интелектуална собственост, която може да струва милиони. Неяснотата относно собствеността върху този актив обаче представлява огромен, често подценяван бизнес риск. Един недобре формулиран трудов договор може да блокира инвестиционна сделка, да провали придобиване (M&A) или да доведе до скъпоструващи съдебни спорове, които да застрашат самото съществуване на компанията.

Това ни изправя пред един фундаментален въпрос, който стои в основата на всеки IT бизнес: Когато софтуерен разработчик, нает на стандартен трудов договор, създаде революционен софтуер, кой притежава авторските права върху него? Индивидуалният талант, който е написал кода, или компанията, която е осигурила заплатата, ресурсите, работната среда и бизнес целите?

Отговорът се крие в българското законодателство, и по-конкретно в Закона за авторското право и сродните му права (ЗАПСП). Както ще видим, законът дава различни отговори в зависимост от вида на създаденото произведение, което създава пластове от правни нюанси. Целта на този анализ е да предостави изчерпателно и ясно ръководство по темата, да демистифицира ключовите разпоредби – чл. 14 и чл. 41 от ЗАПСП – и да предложи практически съвети както за работодатели, така и за служители, за да защитят ефективно своите права и интереси.

Основите – Защо софтуерният код е „литературно произведение“ според закона?

За да разберем кой притежава правата върху софтуера, първо трябва да изясним неговия правен статут. Основата на авторскоправната закрила в България е заложена в чл. 3 от ЗАПСП, който постановява, че обект на авторско право е всяко произведение на литературата, изкуството и науката, което е резултат на творческа дейност.  

Ключовият момент за IT индустрията се намира в чл. 3, ал. 1, т. 1 от ЗАПСП, където законодателят изрично и недвусмислено постановява, че компютърните програми се причисляват към категорията на „литературни произведения“. Тази на пръв поглед странна класификация е от фундаментално значение. Тя означава, че софтуерният код не се третира като изобретение (което би попаднало под закрилата на патентното право) или като физически продукт. Вместо това, той е обект на същия режим на закрила като роман, стихотворение или научна статия. Именно тази правна фикция определя кои последващи членове на закона ще бъдат приложими.  

След като установихме, че софтуерът е закрилян обект, трябва да разграничим двата основни вида права, които съставляват авторското право:

Имуществени и Неимуществени права

• Имуществени (икономически) права: Това е пакетът от права, който има пряка търговска стойност. Той включва изключителното право за използване, възпроизвеждане, разпространение, публично представяне, преработка (модифициране) и превод на софтуера. Това са правата, които могат да бъдат прехвърляни, лицензирани и притежавани от юридическо лице (компания). Те са в сърцето на бизнес модела на всяка софтуерна фирма.
• Неимуществени (морални) права: Тези права са неразривно свързани с личността на твореца. Основното неимуществено право е правото на автора да иска името му, псевдонимът му или друг идентифициращ го знак да бъде обозначаван по съответния начин при всяко използване на произведението. Според българското законодателство, тези права са неотчуждими – те не могат да бъдат прехвърлени или продадени.  

Тук се сблъскваме с един важен и често пренебрегван парадокс. Дори когато една компания придобие пълните и изключителни икономически права върху софтуера, служителят, който го е създал, законово остава негов „автор“ и запазва своите морални права. На практика това означава, че компанията притежава актива и може да го експлоатира търговски, но служителят запазва „кредита“ за неговото създаване. Оттук следва, че един разработчик може напълно легитимно да включи създадения от него софтуер в своето професионално портфолио или автобиография, тъй като това е упражняване на неговото морално право да бъде признат за автор. Обратно, компанията не може да твърди, че нейният изпълнителен директор или самото юридическо лице е „автор“ на кода в творческия смисъл на думата. Това разграничение е ключово при спорове, свързани с авторство, професионална репутация и интелектуален принос.  

Общият режим за служебни произведения – Член 41 от ЗАПСП

Преди да се потопим в спецификата на софтуера, е важно да разгледаме общото правило, което ЗАПСП установява за произведения, създадени в рамките на трудово правоотношение. Този режим е уреден в чл. 41 от ЗАПСП и се прилага за повечето творчески продукти, създадени от служители – например статии от журналисти, маркетингови текстове от копирайтъри, графични дизайни от дизайнери и др.

Основното правило, заложено в чл. 41, ал. 1, гласи, че авторското право върху такова произведение принадлежи на автора, т.е. на служителя. Това е отправната точка, която често изненадва работодателите.  

Въпреки че служителят е носител на авторското право, законът дава значителни права и на работодателя. Съгласно чл. 41, ал. 2 от ЗАПСП, работодателят придобива изключително право да използва създаденото произведение за своите цели, без да е необходимо допълнително разрешение от автора и без да дължи отделно възнаграждение за това (освен ако в трудовия договор не е уговорено друго). Важно ограничение тук е, че това право на използване е обвързано с „обичайната дейност“ на работодателя. Например, ако счетоводител напише роман, докато е на работа, неговият работодател (ако не е издателска къща) не може автоматично да го публикува, тъй като това излиза извън рамките на обичайната му дейност.  

Тук стигаме до критично важен момент: този общ режим, уреден в чл. 41, не се прилага за компютърни програми и бази данни. Именно това изключение е източник на много правни недоразумения в IT сектора. Разглеждането на чл. 41 служи за създаване на контраст, който да подчертае специалния и коренно различен режим, приложим за софтуера.

Lex Specialis – Специалният закон за софтуер по Член 14 от ЗАПСП

В правото съществува фундаментален принцип: (специалният закон отменя общия). Именно този принцип се прилага при софтуера. Член 14 от ЗАПСП е, който въвежда специален режим, изключващ приложението на общото правило по чл. 41, когато става дума за компютърни програми и бази данни.  

Разпоредбата на чл. 14 е кратка, ясна и променя изцяло играта:

„Ако не е уговорено друго, авторското право върху компютърни програми и бази данни, създадени в рамките на трудово правоотношение, принадлежи на работодателя.“  

Тази законова презумпция (предположение) е в полза на работодателя. За разлика от всички други видове служебни произведения, при софтуера законът обръща правилото по подразбиране. Работодателят автоматично и по силата на закона придобива пълния пакет от икономически (имуществени) авторски права. Това включва правото да продава софтуера, да го лицензира на трети страни, да го променя, доразвива и разпространява, без да е необходимо каквото и да е допълнително разрешение от служителя-автор и без да му дължи възнаграждение извън договорената работна заплата. Този подход е в пълна хармония и с европейското законодателство, по-конкретно с Директива 2009/24/ЕО, която също предвижда, че икономическите права върху софтуер, създаден от служител в изпълнение на задълженията му, принадлежат на работодателя.  

Създаването на това изключение за софтуер не е случайно. То отразява съзнателен избор на законодателя, продиктуван от икономическата реалност на IT индустрията. Разработката на софтуер обикновено изисква значителни инвестиции от страна на компанията – в инфраструктура, заплати, обучение и пазарна реализация. Законодателят е преценил, че за да се насърчат тези инвестиции и да се осигури правна сигурност, е необходимо по подразбиране правата върху крайния продукт да принадлежат на инвестиращия субект – работодателя. По този начин IT секторът е поставен в по-благоприятна правна позиция по отношение на своите ключови активи в сравнение с други творчески индустрии като издателския бизнес или рекламните агенции.

Силата на договора – Какво означава „ако не е уговорено друго“?

Ключовата фраза в чл. 14 е „ако не е уговорено друго“. Тя разкрива, че законовата презумпция в полза на работодателя е диспозитивна, а не императивна. Това означава, че законът установява правило по подразбиране, но дава пълна свобода на страните (работодател и служител) да договорят нещо различно в трудовия си договор.

Общината Ви е начислила твърде висок данък сгради или такса смет?

Предварителен договор за имот се провали? Какви са правата Ви, ако другата страна се откаже

Какво е мълчалив отказ и как се обжалва? Отговорите от адвокат по административно право

Чуждестранни предприемачи: Как да регистрират и управляват ООД в България

Спорове за общи части в етажна собственост: Какви са правата ни според ЗУЕС?

Сексуален и психически тормоз на работното място: Как да ги разпознаем и да потърсим защита в България?

Тази договорна свобода превръща трудовия договор от стандартен HR документ в най-критичния инструмент за управление на интелектуалната собственост и свързания с нея риск в една IT компания.

• За работодателите: Въпреки че законът е на тяхна страна по подразбиране, разчитането единствено на законовата разпоредба не е най-добрата бизнес практика. Включването на изрична и детайлна клауза за интелектуална собственост в трудовия договор е абсолютно задължително. Такава клауза трябва да потвърждава, че всички авторски права върху софтуер, код, бази данни и всякакви други материали, създадени от служителя в рамките на неговите задължения, стават изключителна собственост на компанията. Това премахва всякаква двусмисленост и е от критично значение при процеси на дю дилиджънс (правен анализ) по време на инвестиционни рундове, сливания или придобивания. Инвеститорите и купувачите щателно проверяват тези договори, а качеството им е пряк показател за нивото на IP риск в компанията.  
• За служителите: Фразата „ако не е уговорено друго“ е техният прозорец за преговори. Макар и по-рядко срещано на практика, един висококвалифициран и ценен специалист (например senior архитект или разработчик) би могъл да договори по-различни условия. Например, той може да запази собствеността върху определени генерични инструменти, библиотеки или модули, които създава, като предостави на компанията широк, но неизключителен лиценз за ползването им. Друга възможност е договарянето на допълнителен бонус или процент от приходите (revenue share), ако създаденият софтуер се окаже изключително успешен на пазара – възнаграждение, което надхвърля стандартната заплата.

При липса на каквато и да е конкретна уговорка в договора, важи правилото по подразбиране – чл. 14 се прилага с пълна сила и работодателят е собственик на софтуера. Ето защо инвестицията в експертно изготвяне на трудови договори от специализирана адвокатска кантора не е разход, а инвестиция в сигурността и стойността на компанията.

„В рамките на трудовото правоотношение“ – Къде се тегли чертата?

Другият ключов елемент за приложението на чл. 14 е софтуерът да е създаден „в рамките на трудовото правоотношение“. Това изискване не се отнася просто до времето (например, създаден в работно време от 9 до 17 ч.), а до функцията – софтуерът трябва да е създаден в изпълнение на служебните задължения на служителя.

Основният документ, който дефинира тези задължения, е длъжностната характеристика. Ако в нея е записано, че длъжността на служителя е „Софтуерен разработчик“, „Програмист“ или подобна, връзката е очевидна и всеки написан код, свързан с проектите на фирмата, ще се счита за създаден в изпълнение на задълженията му.

Проблемите и споровете възникват в „сивите зони“:

• Сценарий 1: Личният проект. Разработчик работи по свой личен проект вечер и през уикендите, на собствения си компютър, използвайки собствени идеи, които не са свързани с работата му. Авторското право върху този проект е изцяло и безспорно негово.
• Сценарий 2: Работа извън офиса. Разработчик се сблъсква със сложен проблем по служебен проект и намира решението, докато работи от вкъщи вечерта. Въпреки че работата е извършена извън работно време и място, тя е пряко свързана с изпълнението на служебните му задължения. Работодателят притежава правата.
• Сценарий 3: Несвързана длъжност. Счетоводител в IT компания, който в свободното си време се занимава с програмиране като хоби, създава полезен скрипт за автоматизиране на част от счетоводната работа. Тук ситуацията е спорна. Създаването на софтуер не е част от длъжностната му характеристика. Това е класически пример за ситуация, която може да доведе до правен спор.  

Тук се разкрива един по-дълбок правен механизъм, който свързва авторското право с трудовото законодателство. Обхватът на „служебните задължения“ не е статичен. Той може да бъде законово променен от работодателя, дори и без формално изменение на трудовия договор или длъжностната характеристика. Член 120 от Кодекса на труда дава право на работодателя при „производствена необходимост“ едностранно да възлага на служителя да извършва временно друга работа за срок до 45 дни в рамките на една календарна година.  

Връщайки се към Сценарий 3, ако управителят на компанията каже на счетоводителя: „Този скрипт е много полезен, имаме производствена необходимост от него, моля, довърши го и го интегрирай в системата ни“, тази устна инструкция може да се разглежда като временно и законово изменение на неговите трудови функции съгласно Кодекса на труда. В този момент скриптът, който може да е започнал като лична инициатива, вече официално се създава „в рамките на трудовото правоотношение“. В резултат на това авторските права се прехвърлят върху работодателя. Това показва колко е важно компаниите да имат ясни процедури за управление на проекти и документиране на възложените задачи, за да се избегнат подобни неясноти.

Сравнителен анализ – Трудов договор vs. Граждански договор (Freelance)

Много компании, особено в началния си етап, работят не само със служители на трудов договор, но и с външни изпълнители на граждански договор (договор за изработка/поръчка), известни като фрийлансъри. Неразбирането на коренно различния правен режим, който се прилага за тях, е една от най-често срещаните и скъпоструващи грешки.

Режимът за произведения, създадени по поръчка, е уреден в чл. 42 от ЗАПСП. Тук законовата презумпция е напълно обърната в сравнение с тази при трудовия договор за софтуер. По подразбиране, авторското право върху създаденото по поръчка произведение остава собственост на автора (фрийлансъра).  

Възложителят (компанията, която е поръчала софтуера) получава единствено правото да използва произведението само и единствено за целта, за която то е било поръчано, освен ако в договора изрично не е уговорено пълно и безусловно прехвърляне на авторските права.

Това създава огромен капан за компании, които използват стандартни или недобре изготвени договори за изработка. Ако в договора с фрийлансър липсва изрична и ясна клауза за прехвърляне на интелектуалната собственост, компанията може да плати десетки хиляди левове за софтуер, който всъщност не притежава. Тя ще има само ограничено право на ползване. В такава ситуация фрийлансърът би могъл напълно законно да продаде същия или подобен код на пряк конкурент.

За максимална яснота, разликите между режимите са обобщени в следната таблица:

Таблица 1: Сравнение на авторскоправните режими при създаване на софтуер

Практически съвети и финални препоръки

Въз основа на направения анализ, ето няколко ключови практически препоръки за страните в процеса.

Чеклист за Работодатели:

• Договори със служители: Винаги включвайте изрична, детайлно формулирана клауза за интелектуална собственост във всички трудови договори. Тя трябва да потвърждава, че съгласно чл. 14 от ЗАПСП, всички имуществени авторски права върху създадения софтуер, код, документация и други материали преминават върху компанията.
• Длъжностни характеристики: Поддържайте длъжностните характеристики актуални. В тях трябва ясно да са дефинирани задълженията, свързани със създаването на интелектуална собственост.
• Договори с фрийлансъри: Никога не използвайте универсални договори. За всеки фрийлансър или подизпълнител използвайте специализиран договор за изработка, който съдържа недвусмислена клауза за пълно и окончателно прехвърляне на всички имуществени авторски права върху компанията. Никога не разчитайте на устни договорки, имейли или само на издадена фактура като доказателство за собственост.
• Документация: Водете вътрешна документация (протоколи, възлагателни писма, задачи в проджект мениджмънт системи), която да доказва, че конкретен софтуерен продукт е създаден в изпълнение на служебни задължения или по конкретна поръчка.

Наръчник за Софтуерни разработчици:

• Четете договора си: Преди да подпишете трудов договор, прочетете го внимателно и обърнете специално внимание на клаузите за интелектуална собственост. Разберете какви права прехвърляте.
• Разграничавайте работата от личните проекти: Ясно отделяйте работата по лични проекти от служебните си задължения. Избягвайте да използвате служебен хардуер (лаптоп), софтуерни лицензи или фирмени ресурси за свои лични проекти, тъй като това може да създаде предпоставки за правен спор.
• Преговаряйте, когато е възможно: Ако притежавате уникални умения или създавате технология с потенциал, който надхвърля непосредствените нужди на компанията, не се страхувайте да обсъдите възможността за по-различно уреждане на правата.
• Помнете моралните си права: Макар компанията да притежава икономическите права върху кода, вие оставате негов автор. Имате пълното право да го посочвате като част от своя професионален опит и портфолио, освен ако не сте подписали специфично споразумение за конфиденциалност (NDA), което да ограничава това.

Прецизният договор е най-добрата защита

Връщайки се към първоначалния въпрос – за кого са правата – българският закон дава ясен, но нюансиран отговор. По подразбиране, при софтуер, създаден по трудов договор, всички икономически права принадлежат на работодателя. При софтуер, създаден по граждански договор (поръчка), всички права по подразбиране остават за изпълнителя (фрийлансъра). И в двата случая законът позволява страните да уговорят друго.

Неяснотите в договорите, разчитането на устни договорки или използването на стандартни шаблони не спестяват средства. Напротив, те създават огромни бъдещи рискове, които могат да костват на една компания най-ценния й актив. В динамичния свят на технологиите правната сигурност не е лукс, а абсолютна необходимост. Защитата на вашите интелектуални активи започва и завършва с прецизно изготвени договори и навременен експертен правен съвет.

Ако разработвате софтуер, управлявате IT екип или искате да сте сигурни, че вашата компания е пълноправен собственик на своя код, свържете се с екипа на адвокатска кантора Астакова. Ние можем да извършим одит на съществуващите ви договори, да изготвим нови, съобразени с вашите нужди, и да ви предоставим цялостна консултация за защита на вашата интелектуална собственост.

Запазете час за консултация в нашата кантора в София още днес и превърнете правния риск в конкурентно предимство.