Как защитить свой премиум WordPress-шаблон приложения от копирования?

Оставляя в стороне юридические аспекты, я обычно смотрю на это так: пиши хороший код и предлагай качественную поддержку, и люди к тебе потянутся. Существует множество премиум-тем с лицензией GPL, которые прекрасно себя чувствуют. Взгляните на WooThemes, Headway, StudioPress (Genesis) — это всего лишь несколько компаний, которые создают качественные, полностью GPL-темы и успешно зарабатывают на этом.

На мой взгляд, часть их успеха заключается в предоставлении качественной поддержки и установлении такой цены на свои темы, которая позволяет им жить, но остается доступной для покупателей.

Мне кажется, что идея «Если я сделаю свою тему GPL, кто-то украдет ее, и вся моя работа пойдет насмарку» неверна. Конечно, возможно, кто-то украдет ее и будет раздавать бесплатно. Но если вы предлагаете поддержку, люди все равно будут обращаться именно к вам. Не говоря уже о том, что они будут знать, что получают. Бесплатные/украденные премиум-темы (и даже некоторые не премиум) часто содержат шпионское ПО/вредоносные программы. Я предпочту заплатить за то, в чем уверен, чем потом разбираться с вирусом.

Последний пример (и, возможно, мой любимый) — это Theme Hybrid Джастина Тадлока. Он распространяет тему бесплатно под лицензией GPL, но берет $25 в год за поддержку. Плату, которую я с радостью вношу, потому что его поддержка просто потрясающая.

Суть в том, что если вы создадите доверительную среду, люди придут.

Еще одним решением может быть трехуровневая система: $X за продукт, $Y за поддержку, $Z за дополнительные модули.

P.S.: лично я не покупаю ничего для WordPress, что не является полностью GPL.

Если вы хотите применить юридические ограничения к своему продукту и оставаться в рамках практик GPL WordPress, лучшим вариантом будет разделенная лицензия:

• PHP-код под лицензией GPL;
• другие компоненты (такие как дизайн, изображения, CSS) под лицензией по вашему выбору.

В этой теме не были упомянуты такие аспекты, как Шифрование и Обфускация.

Шифрование кода с помощью IonCube или Zend Encoder — это два популярных метода защиты тем и/или плагинов, которые я встречал в использовании.

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

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

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

Однако сочетание шифрования и обфускации сделает кражу вашего проприетарного кода практически невозможной, если не абсолютно невозможной. Это не остановит людей от использования кода (если он работает), но предотвратит его модификацию или копирование функционала для создания аналогичного продукта.

Использование API-ключа, как упоминалось выше, — еще один отличный метод защиты ваших продуктов. Однако у него есть недостаток: если часть логики приложения хранится вне исходной темы или плагина, пользователю необходимо подключиться к вашему серверу, чтобы получить эту логику для корректной работы темы или плагина.

Это звучит как отличное решение, и в большинстве случаев так и есть. Но представьте, что произойдет, если ваш сервер окажется недоступен даже на час или два. Сделает ли это тему или плагин неработоспособными? Несомненно. Затем нужно задуматься, как это повлияет на конечного пользователя.

Этого можно избежать (насколько это возможно), используя резервные серверы для распространения API-логики, например, облачные сервисы надежных компаний, таких как Amazon, в дополнение к прямому доступу к логике с вашего сервера.

Затем вам нужно взвесить накладные расходы и целесообразность такого подхода. Стоит ли оно того? Думаю, это зависит от проекта, но учитывать такие моменты необходимо.

Суть в том, что большинство людей, которые будут пиратить или воровать ваш продукт, тему или плагин, скорее всего, никогда не купили бы их.

Часто считается, что в нашей среде существует три типа людей:

1. Тот, кто будет воровать и пиратить всегда.

2. Тот, кто попытается украсть или взломать продукт перед его покупкой.

3. Тот, кто просто купит ваш продукт, потому что это правильный и надежный способ гарантировать его работу, как описано.

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

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

Из-за частых обновлений с новыми функциями или исправлениями ошибок ранее пиратские версии часто становятся бесполезными или менее функциональными по сравнению с платными.

Как уже упоминалось, шифрование и обфускация кода в сочетании друг с другом, а также интеграция в стиле API — это методы, которые стоит изучить для максимально надежной защиты ваших продуктов, тем или плагинов.

Если вы продаёте его, то не обязательно распространять его под лицензией GPL, так как вы не можете продавать его на сайтах WordPress. Вы можете распространять его самостоятельно под любой лицензией, какую пожелаете. Ограничение GPL действует только для репозиториев Wordpress.org, и поскольку вы не можете продавать через Wordpress.org, вы можете использовать любую лицензию.