Как защитить свой код на PHP от стороннего использования?

Данный вопрос актуален не только для PHP, но и для остальных интерпретируемых языков или скриптов, которые лежат на хостинге в открытой форме.

Обращаю ваше внимание на то, что вопрос относится не только к защите кода от хакеров, взломавших хостинг и получивших доступ к исходникам, но и от самого хостера и/или бывших коллег по проекту, которые из него уже выбыли.

К тому же в любом хоть немного уважающем своих клиентов сервисе предусмотрена система бэкапов, SVN и т.п. системы сохраняющие исходники не только в единственном экземпляре в папке вебсервера. И соответственно «нажать F6» тут не вариант.

Статей по данной тематике немало, но в данном вопросе акцент на некомпилируемые программные продукты.

К тому же надо учесть, что банальная вставка своих копирайтов в исходный код в каждой странице в ремарках(к примеру) легко убрать при желании, стиль программирования тоже редактируется. В общем нужно какое то более надежное решение.

Быть может кто-то подскажет более надежный способ или сервис, который выполняет функцию подобную патентной защите, но относящуюся к защите исходников от использования без согласования с автором. Эдакий общедоступный реестр авторских прав разработчиков с указанием прав использования.
  • Вопрос задан
  • 5428 просмотров
Пригласить эксперта
Ответы на вопрос 9
tampere
@tampere
Скрывать код от коллег — бесполезное и бессмысленное занятие. Это означает, что вы им не доверяете, или они вам. В крупных компаниях принят принцип внутренней открытости. В яндексе любой разработчик может прочитать и использовать код внутренних серверов, в микрософте можно счекаутить windows (кроме коммерчески значимых участков кода типа bitlocker и алгоритмов ранжирования в рекламе и в поиске).
Защитить право на код очень просто — сделать его открытым. Тогда все точно будут знать, что это ваш проект, а не чей-то ещё.
Ответ написан
sevka_fedoroff
@sevka_fedoroff
По поводу SVN и бывших коллег по работе. В SVN тоже зашифрованный код хранить что ли? И программистов сразу заставлять писать обфускейченый код?
Ответ написан
zizop
@zizop
Код защифрованный через IonCube или Zend Encoder расшифровываются через установку специального php расширения. Как вариант можно обфусцировать код, а потом уже через IonCube зашифровать. Тогда после первичной расшифровки, всё равно будет нечитабельная абракадабра.
Ответ написан
Комментировать
Dennion
@Dennion
Разработчик PHPShop CMS.
Написать свой кодировщик или делать кусок вашего приложения как SaaS. Какой бы не был кодировщик — это защита от дурака, если кому нужно посмотреть код, то уже ничто не поможет.

Сделайте wiki и phpdoc раздел по коду и если будут трения всегда можно сослаться, что вы раньше разместили свой код и отсудить. Ну а так подумайте хорошо — кому он нужен кроме вас и что в нем такого интересного, что не знают другие. Обычно закрывают код проверки лицензии, остальное все открыто для редактирования. Гляньте в эту сторону.
Ответ написан
От коллег, имеющих доступ хотя бы на чтение к центральному репозиторию ничего не спасёт (если как указали выше не выкладывать туда уже зашифрованный код). От хостера, имеющего физический доступ к дискам, тоже. От праздного любопытства сотрудников хостера может помочь использование шифрованных ФС, от целенаправленного уже нет.

В общем, имхо, технические средства защиты кода (тем более для интерпретируемых ЯП) могут использоваться лишь для усложнения нелегального использования, от целенаправленной атаки они не спасут. Основная защита должна быть юридическая — для начала Государственная регистрация программы для ЭВМ или базы данных
Ответ написан
@Ofigenen
Я, возможно, буду слишком категоричен, но в вашей ситуации… никак. Код хранится незашифрованным, доступ к нему имеете не только Вы, а это значит, что стопроцентной гарантии не дадут никакие меры предосторожности.
Вообще, от коллег обычно помогает NDA, в которое у нас, например, был включен запрет на личное использование любых совместных разработок. Я не юрист, а потому не знаю, сколь серьезны могут быть (ну, хотя бы теоретически) последствия нарушения этого соглашения, но проверять почему-то не хотел никогда.
Ответ написан
@Jazzist
1. Работать с теми, кому доверяете. Это относится и к коллегам, и к провайдеру.
2. Пересмотреть подход к работе. Если сложно это сделать сейчас — не переживайте, придет с опытом. Возможно, имеет смысл просто более углубиться в работу — тогда будет меньше риторических вопросов (ответы на которых не имеют смысла), и будет больше практически эффективных решений — действий, которые принесут вам реальную пользу, а не будут только отнимать время.
Ответ написан
@private_tm
JAVA dev
IonCube
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы