Недавно я опубликовал статью по теме code escrow – депонированию исходного кода, как страховке для заказчиков. Исходная статья короткая, если вы не читали, то проще быстро пройтись по ней. Но вкратце, code escrow — это процесс размещения исходного кода вашего приложения в стороннем репозитории, к которому заказчик имеет доступ при определенном условии. Обычно это нужно если компания-разработчик уходит с рынка. И это является своеобразной страховкой клиентов.
Эту тему я обсудил не только в комментариях на Хабре, но и вне его. И было несколько интересных вопросов, которые считаю полезным опубликовать вместе с ответами.
Практика обычно такая. Устанавливается периодичность загрузки исходников в репозиторий. Например, только мажорные версии. Как только выпускается версия 2, то её исходники тоже загружаются. То есть публикация не по факту продажи, а по факту релиза. Частотность зависит от продукта.
Какая версия доступна клиентам, определяется соглашением с ними. Это может быть всегда последний релиз. Тогда нужно хранить только его. Или же все сборки.
При публикации надо хранить не только исходники, но и очень детальное описание: ОС, IDE, фреймворки и их версии. Как развернуть окружение.
Обычно речь идёт о ситуациях, когда продукт используется, но по определённым причинам компания больше не может его сопровождать. То есть это не код 10-летней давности. Максимум несколько лет. И на самом деле даже старый код можно собрать.
Это правильный подход. Однако распространение образов может быть лицензионно ограничено. Например, нельзя распространять MS Windows и Visual Studio. Если вы используете ПО и утилиты без подобных ограничений, то образы сильно помогут.
Под термином «исчезает» скрывается несколько типов случаев, которые не такие и редкие. Помимо банкротства, компания может потерять исходники, например после атаки вируса-шифровальщика и бездарном отношении к бэкапам. А также компания разработчик может попасть под санкции. При появлении санкций клиент (как правило, зарубежный) теряет возможность общаться с вендором. В этом случае к репозиторию сохраняется доступ.
Тут как с эскроу счетами. Гарантией служит только то, насколько вы доверяете репозиторию. Однако подумайте, кому на самом деле нужен ваш код. Мой коллега сказал, что он бы и копейки не дал за то, чтобы получить доступ к коду конкурентов. С учетом того, что все алгоритмы и так известны, а разбираться в чужих исходниках удовольствие сомнительное, то ценность стороннего кода невелика. А с учетом того, что это в явном виде неправомерный доступ и имеет последствия, то ценность такого доступа еще ниже.
Если вы не пользовались таким процессом раньше, готовы ли вы начать? Интересно мнение как со стороны разработчика, так и клиента.
Эту тему я обсудил не только в комментариях на Хабре, но и вне его. И было несколько интересных вопросов, которые считаю полезным опубликовать вместе с ответами.
Какая версия должна храниться в репозитории?
Практика обычно такая. Устанавливается периодичность загрузки исходников в репозиторий. Например, только мажорные версии. Как только выпускается версия 2, то её исходники тоже загружаются. То есть публикация не по факту продажи, а по факту релиза. Частотность зависит от продукта.
Какая версия доступна клиентам, определяется соглашением с ними. Это может быть всегда последний релиз. Тогда нужно хранить только его. Или же все сборки.
Код устаревает, не факт, что он спустя N лет будет компилироваться при помощи актуальных версий компиляторов/IDE. Что вообще можно реально сделать с кодом 10-15 летней давности?
При публикации надо хранить не только исходники, но и очень детальное описание: ОС, IDE, фреймворки и их версии. Как развернуть окружение.
Обычно речь идёт о ситуациях, когда продукт используется, но по определённым причинам компания больше не может его сопровождать. То есть это не код 10-летней давности. Максимум несколько лет. И на самом деле даже старый код можно собрать.
Почему бы не хранить образ виртуальной машины, на которой будет все необходимое для сборки?
Это правильный подход. Однако распространение образов может быть лицензионно ограничено. Например, нельзя распространять MS Windows и Visual Studio. Если вы используете ПО и утилиты без подобных ограничений, то образы сильно помогут.
Не слишком ли эта редкая ситуация, когда компания внезапно исчезает?
Под термином «исчезает» скрывается несколько типов случаев, которые не такие и редкие. Помимо банкротства, компания может потерять исходники, например после атаки вируса-шифровальщика и бездарном отношении к бэкапам. А также компания разработчик может попасть под санкции. При появлении санкций клиент (как правило, зарубежный) теряет возможность общаться с вендором. В этом случае к репозиторию сохраняется доступ.
И последний, самый провокационный вопрос. Какие у меня гарантии что мой код не утечет на сторону?
Тут как с эскроу счетами. Гарантией служит только то, насколько вы доверяете репозиторию. Однако подумайте, кому на самом деле нужен ваш код. Мой коллега сказал, что он бы и копейки не дал за то, чтобы получить доступ к коду конкурентов. С учетом того, что все алгоритмы и так известны, а разбираться в чужих исходниках удовольствие сомнительное, то ценность стороннего кода невелика. А с учетом того, что это в явном виде неправомерный доступ и имеет последствия, то ценность такого доступа еще ниже.
Если вы не пользовались таким процессом раньше, готовы ли вы начать? Интересно мнение как со стороны разработчика, так и клиента.
aamonster
Последний вопрос забавен в отрыве от необходимости аудита исходников (что из них действительно собирается целевое приложение) со стороны депозитория. Без этого нечего опасаться, что исходники утекут: в депозитории может, к примеру, храниться ключ от зашифрованного архива (копеечная услуга). Ну и возможность, что разработчик вместо актуальных исходников подсунет устаревшие или мусор, тоже не исключается.
Вероятно, можно даже построить схему так, чтобы депозиторий проверил исходники (на изолированном компе), заинтересованные стороны подписали бы архив, а незашифрованные данные были бы затёрты. Но это для случая совсем уж серьёзного недоверия разработчика депозиторию :-)
MikhailZakharov Автор
Аудит важная вещь. Некоторые предоставляют его при определенном уровне (вот тут, например, есть список https://www.escrowtech.com/technical-verification.php). От простой проверки читаемости, до сборки кода.
Скажу, что идея с архивом и ключом мне нравится. Будет работать при определенных условиях.
Вижу несколько моментов. При использовании архива обязанность за сохранность кода переходит к клиенту. Не каждый готов ее брать на себя, с учетом того, что сервис аудита уже оплачен. Плюс надо назначить ответственного за хранение и новых версий тоже. Средства шифрования должны быть разрешены к использованию в стране, и должны быть инструменты для шифровки дешифровки.
aamonster
Ну, можно наоборот: ключ у клиента, архив у депозитария. Всё равно место на диске (или вообще на лентах, это архив с крайне редким извлечением) много дешевле, чем сопутствующие услуги. Или (чтобы предусмотреть ситуацию «клиент потерял ключ») ещё как разделить (в голову приходят всякие схемы восстановления ключа – типа части ключа хранятся у пяти людей так, что любые трое могут его восстановить – не помню, как алгоритм называется, так что найти не могу, но на поржать – www.problems.ru/view_problem_details_new.php?id=60384 )