Преминаване към съдържанието
Назад към статиите
Operations

Собственост върху код и данни при custom software

Какво трябва да предвижда договорът за source code, данни, библиотеки, достъп, предаване и продължаване на custom software проект.

6.09.2026 г.5 минути четене

От Η ομάδα της Argonstack, TechIns Group

Собственост върху код и данни при custom software

Фразата „софтуерът ще бъде наш" не е достатъчна. При custom проект трябва да се разграничат изходният код, данните, дизайнът, документацията, съществуващите преди това библиотеки, лицензите на трети страни, инфраструктурата и правото за продължаване на разработката от друг екип.

Ако тези неща не бъдат определени преди началото на проекта, спорът обикновено се появява, когато клиентът поиска достъп до repository, смяна на партньор или износ на данни. Въпросът не се решава от факта, че някой е платил за разработката. Решава се от договора и приложимото право.

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

Какво означава собственост върху изходния код

Изходният код е материалът, който разработчиците използват, за да създават и модифицират приложението. Достъпът до кода не се приравнява непременно на прехвърляне на всички права. Дадена компания може да разполага с копие на repository, но с ограничено право на ползване. Може също да разполага с изключителен лиценз за ползване, без да е придобила всеки елемент, който е бил използван.

Европейската Директива 2009/24/ЕО защитава компютърните програми чрез авторско право. Договорът трябва да определя точно кои права се прехвърлят, кога се прехвърлят, за коя територия и дали има ограничение на ползването или модификацията.

Четири категории код

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

Новият специфичен код може да бъде прехвърлен на клиента или лицензиран. Съществуващите преди това framework-и на доставчика обикновено остават негова собственост, с право на ползване в рамките на предаваемия продукт. Open source библиотеките следват собствените си лицензи. Услугите на трети страни, като cloud, карти, имейл или AI API-та, се уреждат от условията на съответните доставчици.

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

Данните на клиента

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

За личните данни е необходимо допълнително определяне на ролите съгласно GDPR и, когато доставчикът действа като обработващ лични данни, подходящо Споразумение за обработка на данни. „Собствеността върху данните" не заменя задълженията за защита на личните данни.

Какво трябва да бъде предадено

Реалната възможност за продължаване на един проект изисква повече от zip файл с source code. Необходими са достъп до repository, инструкции за инсталиране, environment variables без разкриване на непрехвърляеми тайни, database schema, API документация, списък на зависимостите, deployment процес, backup процес и списък на акаунтите на трети страни.

Трябва също да се определи кой контролира домейна, cloud акаунта, app store акаунтите, analytics, имейл услугите и signing keys. Където е възможно, критичните акаунти трябва да принадлежат на клиента, а доставчикът да получава контролиран достъп.

Кога се прехвърлят правата

Обичайна търговска логика е прехвърлянето на договорените права след пълно изплащане. Това трябва да бъде изрично уговорено. Успоредно с това трябва да се определи какво се случва, ако проектът бъде прекратен преди завършване, кои предавания са платени и какво право на ползване получава клиентът за вече предадената работа. Съответните търговски условия са описани в Общите условия на Argonstack.

Vendor lock-in и право на изход

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

Сериозният договор включва план за изход (exit plan). Той определя формата на износа, срока за предаване, преходния период, разхода за допълнителна поддръжка и изтриването на копията след изтичане на законовите задължения за съхранение.

Source code escrow

При критични системи може да се уговори source code escrow. Актуално копие на кода и документацията се съхранява от независима страна и се освобождава само при конкретни случаи, като прекратяване на дейността на доставчика или сериозна невъзможност за поддръжка.

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

Какво трябва да поиска клиентът преди да подпише

Клиентът трябва да поиска ясно определение на предаванията, правата върху специфичния код, изключенията, лицензите на трети страни, достъпа до repository, собствеността върху акаунтите, износа на данни, документацията, поддръжката и exit plan.

Argonstack организира всеки custom проект с ясен обхват (scope) и техническа архитектура. Условията за собственост и предаване трябва да бъдат отразени в конкретния договор на проекта и да отговарят на реалния модел на сътрудничество.

Следваща стъпка

Определете обхват, права, достъп и exit plan преди началото на разработката.

Често задавани въпроси

Ако платя разработката, ставам ли автоматично собственик на кода?

Не непременно. Плащането и прехвърлянето на права са различни въпроси. Договорът трябва да определя какво точно придобива клиентът.

Мога ли да притежавам open source библиотеки?

Не в смисъла на изключителна собственост. Те се използват съгласно собствените си лицензи. Доставчикът трябва да декларира критичните зависимости и съответните задължения.

Трябва ли cloud акаунтът да е на името на клиента?

За критична custom инфраструктура това често е по-сигурният избор, при условие че има правилно управление на достъпите. При SaaS продукт това обикновено не е приложимо, тъй като общата инфраструктура принадлежи на доставчика.

Кое е по-важно от фразата „кодът е мой"?

Реалната възможност за работа, износ на данни, поддръжка и преход. Без документация, акаунти и deployment процес, теоретичната собственост може да има малка практическа стойност.

Официален източник

Свързани статии

Всички статии