Чий е кодът и акаунтите, когато наемете разработчик

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

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

#Чий е кодът по подразбиране

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

Договорът за разработка трябва да казва ясно:

• Какво се прехвърля: изходният код, дизайнът, документацията, структурата на базата данни и всички други материали, създадени за проекта.
• Кога се прехвърля: при плащане на всеки етап или при окончателното плащане. Прехвърлянето по етапи ви пази, ако отношенията приключат по средата.
• Какво остава у разработчика: общи инструменти, библиотеки и ноу-хау, създадени преди вашия проект и използвани за различни клиенти. Нормално е разработчикът да ги запази и да ви даде безсрочен лиценз да ги ползвате в продукта си. Договорът трябва да ги изброява или описва, за да няма спорове по-късно.
• Чужди компоненти: кои open source и платени компоненти се използват и под какви лицензи.
• Поверителност: как се третират бизнес данните и достъпите ви по време на проекта и след него.

#Акаунтите са на ваше име от първия ден

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

Акаунт	Какво да проверите
Хранилище за код (GitHub, GitLab, Bitbucket)	Организацията или работното пространство е ваше и вие имате ролята на собственик.
Регистратор на домейна	Домейнът е регистриран на вашата фирма като титуляр и можете да влезете в акаунта при регистратора.
Хостинг или облак	Договорът и плащанията са на ваше име и имате пълен администраторски достъп.
Apple Developer и Google Play Console	Приложенията са публикувани във вашия акаунт за разработчици и имате ролята на администратор или титуляр на акаунта.
Плащания, имейл, карти, статистика, проследяване на грешки	Всяка услуга е регистрирана на вас, а API ключовете са издадени от вашия акаунт.

Домейните изискват специално внимание, защото законен титуляр на домейна е този, който е записан в регистрацията, каквото и да е било уговорено устно. Регистрацията и прехвърлянето на домейни са описани подробно в статията какво е домейн и как работи DNS. При мобилните приложения капанът е подобен: прехвърлянето на приложение между акаунти за разработчици е възможно, но е по-бавно и по-неудобно от публикуването във ваш собствен акаунт още от първата версия.

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

#Open source лицензи във вашия проект

Почти всяко съвременно приложение е изградено върху open source framework-ове и библиотеки. Това е нормално и спестява много работа, но всеки компонент идва с лиценз и лицензът определя правилата.

• Разрешителните лицензи като MIT, BSD и Apache 2.0 ви позволяват да използвате, променяте и продавате софтуер с този компонент, стига да запазите бележките за авторски права и лиценз. Apache 2.0 съдържа и условия за патенти.
• Copyleft лицензите като GPL изискват, ако разпространявате софтуер, изграден върху компонента, да предоставите изходния код под същия лиценз. AGPL разширява това и към софтуер, който потребителите достъпват по мрежата.

Copyleft компонентите не са забранени и много фирми ги използват съзнателно. Рискът е да попаднат в продукт, който сте планирали да остане затворен, без да знаете. Поискайте от разработчика списък на зависимостите с техните лицензи, който мениджърите на пакети могат да генерират, и го помолете да ви предупреждава за всеки copyleft компонент, преди да го добави. Платените теми, плъгини и шрифтове също имат лицензи; проверете, че всеки е купен на ваше име и позволява вашия начин на използване.

#Достъпи и документация при предаването

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

Достъпи

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

Документация

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

#Какво да проверите преди подписване

• Договорът прехвърля на вас интелектуалната собственост върху работата и казва кога.
• Инструментите, които разработчикът запазва, са описани и получавате безсрочен лиценз за тях.
• Всички акаунти ще бъдат открити на ваше име или прехвърлени на вас на посочена дата.
• Кодът ще е в хранилище, което е ваше, с пълна история от началото на проекта.
• Open source лицензите ще бъдат изброени, а copyleft компонентите отбелязани.
• Документацията е част от резултата и се поддържа актуална по време на проекта.
• Договорът урежда какво става, ако някоя от страните го прекрати по-рано, включително какво получавате.

#Какво да проверите при предаването

• Вие сте собственик на всеки акаунт от таблицата по-горе и можете да влезете без помощта на разработчика.
• Хранилището съдържа цялата история, всички клонове и всичко нужно за изграждане на продукта.
• Продуктът се изгражда и публикува от хранилището по писмените инструкции.
• Всеки достъп е във вашия мениджър на пароли, а тези, които разработчикът е знаел, са сменени.
• Имате скорошен архив и някой го е възстановил успешно поне веднъж.
• Имате списъка с лицензи, а платените компоненти са регистрирани на вас.

Ако нещо от това липсва, поискайте го преди окончателното плащане. Много по-лесно е да се поправи, докато проектът още тече.

#Как може да помогне PN Scripts

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