Съдържание:

София отдавна надхвърли ролята си на административната столица. През последното десетилетие градът не се трансформира в туптящото дигитално сърце на Югоизточна Европа. Екосистемата от технологични стартове, глобални R&D центрове и успешни аутсорсинг компании увеличиха значителна част от БВП на страната. Тук, в офисите около бул. „Цариградско шосе“ и в коуъркинг пространствата в центъра, се пишат кодове, които управляват всичко – от финтех приложения в Лондон до логистични вериги в САЩ.

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

В практиката на Адвокатска кантора Астакова (AdvokatSofia.com) все по-често ставаме свидетели на един и същи болезнен сценарий: брилянтна техническа идея и месеци усилен труд се сриват заради един липсващ параграф в договора. Спор за авторски права блокира продажбата на компанията; липсата на SLA (Service Level Agreement) води до загуба на ключови клиенти; неуредените отношения с фрийлансъри създават конкурентни продукти.

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

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

СБЛЪСЪКЪТ НА ДВА СВЯТА – AGILE СРЕЩУ ПРАВНАТА СИГУРНОСТ

Първият и най-фундаментален проблем при договорите за софтуер е разминаването във философията на работа.

Водопадът (Waterfall) и илюзията за предвидимост

Традиционното право обича модела „Waterfall“: Клиентът поръчва нещо конкретно (напр. „Уебсайт с 5 страници“), Изпълнителят го прави, Клиентът плаща. Този модел работи чудесно за строителство или доставка на мебели. В софтуера обаче, изискванията се променят с всяка седмица. Ако подпишете договор с „твърд обхват“ (Fixed Scope) за проект, който ще трае 6 месеца, вие гарантирате конфликт. Клиентът ще иска промени, защото пазарът се е променил, а Изпълнителят ще иска още пари за всяка запетая, която не е в първоначалния списък.

Гъвкавите методологии (Agile/Scrum) и правният вакуум

Повечето екипи в София работят по Agile. Те работят на „спринтове“ (Sprints), тестват хипотези и променят курса в движение. Как се пише договор за нещо, което още не е измислено? Тук е мястото на специализирания IT адвокат. Вместо стандартен договор за изработка, ние в кантора Астакова изготвяме хибридни структури:

Рамков договор (MSA – Master Services Agreement): Той урежда „големите правила“ – конфиденциалност, авторски права, отговорност, начини на плащане, прекратяване. Тези условия не се променят.
Заявки за работа (SOW – Statements of Work): Това са динамични приложения към договора за всеки отделен спринт или етап. Те дефинират конкретната задача за следващите 2 седмици или месец.

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

ВОЙНАТА ЗА КОДА – ИНТЕЛЕКТУАЛНА СОБСТВЕНОСТ (IP)

Това е „ядрената глава“ на всеки договор. Грешките тук са необратими и струват милиони.

Митът „Платих, значи е мое“

Това е най-опасната заблуда в бранша. Според българския Закон за авторското право и сродните му права (ЗАПСП), авторското право възниква за създателя (физическото лице програмист) в момента на написването на кода. Дори да сте фирма Възложител и да сте платили 100 000 лв. по фактура, ако в договора няма изрична клауза за прехвърляне на права, вие получавате само лицензия (право на ползване). Какво означава това на практика?

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

Source Code (Изходен код) срещу Object Code (Обектен код)

Много договори използват общото понятие „софтуер“. Това е юридически небрежно.

Обектен код: Това е компилираната програма, „черната кутия“, която крайният потребител вижда.
Изходен код: Това е „рецептата“ – четимият текст, написан от програмистите. Ако държите само правата върху обектния код, вие сте заложник на разработчика. Вие не можете да поправите бъг, не можете да добавите функция, не можете да мигрирате към друг доставчик. Вашият договор трябва задължително да изисква предаване на изходния код, заедно с пълна техническа документация, коментари в кода (code comments) и скриптове за инсталация.

Работа с фрийлансъри vs. Служители

Внимавайте с кого работите.

Ако програмистът е ваш служител (на трудов договор), законът казва, че правата върху създаденото по време на работа принадлежат на работодателя (освен ако не е уговорено друго).
Ако програмистът е фрийлансър (граждански договор), правата са негови, докато не ги прехвърли писмено.
Ако наемате софтуерна агенция (Dev Shop), уверете се, че те са уредили правата с техните програмисти. Изисквайте гаранция в договора, че агенцията притежава всички права, които ви прехвърля (Chain of Title).

SLA (SERVICE LEVEL AGREEMENT) – УПРАВЛЕНИЕ НА КАЧЕСТВОТО

SLA или Споразумението за ниво на обслужване превръща техническите обещания в правни задължения. То е критично не само за хостинг и поддръжка, но и при самата разработка.

Дефиниране на „Недостъпност“ и „Грешка“

Какво означава „софтуерът не работи“? За програмиста един бъг може да е „маловажен“, за бизнеса – да е катастрофален. Добрият SLA класифицира инцидентите:

Приоритет 1 (Blocker): Критичен проблем. Загуба на данни, пълна липса на достъп. (Реакция: 1 час; Решение: 4 часа).
Приоритет 2 (Major): Основна функция е счупена, но има заобиколен път (workaround).
Приоритет 3 (Minor): Козметични дефекти.

Санкции и „Service Credits“

SLA без наказания е просто пожелание. В AdvokatSofia.com съветваме клиентите да не залагат на абстрактни неустойки, а на механизма „Service Credits“. Ако доставчикът не спази гарантирания Uptime (напр. 99.9%) или времето за реакция, той „връща“ пари под формата на безплатни часове работа или отстъпка от следващата фактура. Това е работещ търговски механизъм, който запазва партньорските отношения, но дисциплинира изпълнителя.

МОДЕЛИ НА ПЛАЩАНЕ И ТЕХНИТЕ РИСКОВЕ

Изборът на ценови модел променя изцяло структурата на договора.

Fixed Price (Твърда цена)

Подходящ за малки, ясно дефинирани проекти.

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

Time & Material (Плащане на час/ден)

Стандартът за големи проекти.

Плюс: Гъвкавост и качество.
Риск: Бюджетът може да излезе извън контрол.
Юридически съвет: Изисквайте строга отчетност (Timesheets), право на одит и заложете „Cap“ (Таван) на месечния бюджет, който не може да се надвишава без писмено одобрение.

АНОНИМНИ КАЗУСИ ОТ ПРАКТИКАТА НА КАНТОРА „АСТАКОВА“

Теорията е важна, но реалните истории показват цената на грешките. Ето три случая от нашата практика в София.

Заложник на Open Source лиценз

Ситуацията: Български стартъп разработва иновативна платформа за видео анализи. Наемат външен програмист. Той използва библиотека с отворен код под лиценз GNU GPL v3, за да спести време. Проблемът: Лицензът GPL е „вирусен“ (copyleft). Той изисква, ако използвате такъв компонент, целият ви софтуер да бъде разпространяван безплатно и с отворен код. Когато стартъпът започна преговори с голям инвеститор, юридическият одит (due diligence) разкри проблема. Инвеститорът се оттегли, защото продуктът не можеше да се патентова или продава лицензионно. Решението: Трябваше да се пренапише 40% от кода наново, за да се премахне „заразения“ компонент. Загуба на време: 6 месеца. Поука: Винаги включвайте клауза за „IP Indemnification“, с която разработчикът гарантира, че не използва код с ограничаващи лицензи.

Кодът, който изчезна

Ситуацията: Собственик на онлайн магазин работи с фрийлансър без писмен договор, само с чат в Viber. Плаща на ръка или чрез Revolut. Проблемът: Скарат се за пари. Фрийлансърът, който е регистрирал хостинга и домейна на свое име, спира сайта в деня преди Черен петък. Решението: Тъй като нямаше писмен договор, доказването на собственост беше кошмарно. Наложи се да водим дело за неоснователно обогатяване и да сезираме прокуратурата за компютърно престъпление, за да върнем достъпа. Поука: Собствеността върху инфраструктурата (хостинг, домейни, AWS акаунти, GitHub репозиторита) трябва винаги да е на името на Клиента, а разработчикът да има само администраторски достъп, който може да бъде отнет.

Американската мечта и българската реалност

Ситуацията: Софийска IT фирма сключва договор с американски клиент. Клиентът изпраща техен договор (по правото на щата Делауеър), който включва клауза „Work for hire“. Проблемът: Концепцията „Work for hire“ (работодателят автоматично е автор) работи в САЩ, но противоречи на българския ЗАПСП при граждански договори. В България авторството е непрехвърлимо, прехвърлят се само имуществените права. Резултат: При съдебен спор в България, американският договор се оказа частично нищожен. Поука: Когато работите през граница, винаги адаптирайте договорите към локалното законодателство или избирайте приложимо право и арбитраж, които разбирате.

ПРИЕМАНЕ (UAT) И ГАРАНЦИИ

Моментът на предаване е най-рисковият. Разработчикът казва „Готово е“, Клиентът казва „Не работи“.

User Acceptance Testing (UAT)

Никога не подписвайте клауза за „автоматично приемане, ако няма възражения до 3 дни“. Софтуер не се тества за 3 дни. Изисквайте реалистичен период за тестове (14-30 дни). Договорете, че ако бъдат открити „блокиращи“ грешки, часовникът спира и периодът за тестване започва отначало след поправката им.

Гаранционен срок

След приемането започва гаранцията. Стандартът е 6 до 12 месеца. Важно е да се разграничи Гаранция (поправка на грешки в съществуващия код) от Поддръжка (адаптация към нови версии на браузъри/OS). Гаранцията трябва да е безплатна. Поддръжката се плаща.

ЗАЩИТА НА ТЪРГОВСКАТА ТАЙНА И NON-COMPETE

Вие давате достъп на разработчика до най-съкровените тайни на бизнеса си – клиентски бази данни, алгоритми, бизнес логика.

NDA (Споразумение за поверителност)

Стандартното NDA не е достатъчно. Трябва да дефинирате точно какво е „Поверителна информация“. Включете високи неустойки при изтичане на данни. Внимавайте: Информацията в кода (алгоритмите) също е тайна.

Non-Compete (Забрана за конкуренция) и Non-Solicit

Не искате програмистът, който е направил вашата уникална платформа, след месец да направи копие за конкурента ви. Клаузата за неконкуриране трябва да е разумна по време и територия, за да бъде валидна в съда. Още по-важна е клаузата Non-Solicit (Забрана за привличане). Тя защитава и двете страни – Клиентът не може да „открадне“ програмистите на Агенцията, а Агенцията не може да „открадне“ клиентите на Възложителя.

Ако вашият софтуер обработва лични данни (а почти всеки софтуер го прави), договорът за изработка е и договор за обработка на данни (DPA).

Разработчикът трябва да спазва принципа Privacy by Design (Защита на етапа на проектиране). Това означава, че архитектурата трябва да позволява лесно изтриване на данни („правото да бъдеш забравен“), криптиране и контрол на достъпа. Ако разработчикът остави „задна врата“ (backdoor) или несигурен код (напр. SQL Injection уязвимост), и стане теч на данни, КЗЛД ще глоби вас като Администратор. Вашият договор трябва да ви дава право на регресен иск срещу разработчика за размера на глобата.

ПРЕКРАТЯВАНЕ И EXIT STRATEGY (ИЗХОДНА СТРАТЕГИЯ)

Всяко партньорство има край. Добрият договор урежда „развода“ докато сте още влюбени.

Escrow на софтуер

За критични системи препоръчваме „Ескроу споразумение“. Сорс кодът се депозира при трета независима страна (нотариус или специализиран агент). Ако софтуерната фирма фалира или спре да поддържа продукта, третата страна ви предоставя кода. Това е вашата застраховка „Живот“ за бизнеса.

Задължение за съдействие (Handover)

При прекратяване на договора, старата фирма трябва да има задължението да съдейства на новия екип – да обясни архитектурата, да предаде достъпите и да направи трансфер на знание (Knowledge Transfer). Това съдействие трябва да има фиксирана цена или да е включено в последната вноска.

ЗАКЛЮЧЕНИЕ: ИНВЕСТИЦИЯТА В ПРАВНА СИГУРНОСТ СЕ ИЗПЛАЩА

В ерата на дигиталната икономика, кодът е новият петрол. Но за разлика от петрола, кодът може да бъде копиран, откраднат или изтрит с едно натискане на бутон.

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

Не разчитайте на късмета. В IT бизнеса в София оцеляват не само най-креативните, но и най-добре подготвените.

Защитете интелектуалната си собственост с професионален договор

Вашата идея заслужава повече от бланка, свалена от интернет. В Адвокатска кантора Астакова разбираме езика на технологиите – от GitHub до Blockchain. Ние знаем как да превърнем техническите рискове в правни гаранции.

Независимо дали сте стартъп, който търси защита на MVP-то си, или утвърдена компания, която сключва SLA за критична инфраструктура, нашият екип е готов да ви съдейства. Нека направим одит на вашите договори и да защитим това, което създавате.

Rate this post