У вас есть стратегия для этого? Если я продаю веб-систему клиенту и в соответствии с юридическим соглашением, клиент не может продать его другим, как я могу быть уверен, что он этого не сделает?
Моя первая идея – это какой-то ключ, который должен находиться в корневом каталоге, и этот файл действителен только для этого конкретного домена.
Другие идеи?
ОБНОВЛЕНИЕ 1 Я согласен, что это в основном юридическая проблема. Но факты таковы: у меня есть клиент, который покупает эту систему у меня, чтобы продать ее другим. И он хочет, чтобы эта система функционировала, поэтому ему легко получить прибыль. Возможность упаковывать веб-сервер и продавать его является частью спецификации.
ОБНОВЛЕНИЕ 2 Еще одна точка зрения – это . В этом случае трудно доказать, сколько из перепрограммированного программного обеспечения исходит из моей исходной системы.
ОБНОВЛЕНИЕ 3 Обфускация – это не вариант для меня, это очень ненавистно.
Некоторые используют обфускатор, как Zend Guard, но, честно говоря, я считаю, что технические решения для такого рода проблем обречены на то, что DRM предназначен для аудио и видео контента. Принципиально то, что вы даете им, предназначено для работы, поэтому это просто техническая проблема, чтобы заставить ее работать так, как вы этого не хотите.
Ваши ресурсы здесь (imho) юридически не технические. У вас есть контракт с клиентом, который определяет, что они могут и чего не могут сделать. У вас есть хороший проект адвоката этого контракта. Если они не соблюдают его, то вам в значительной степени придется отнести их к суду.
Не рассчитывайте на какую-либо форму обфускации или защиту от копирования как на любую гарантию.
Это особенно проблема для языков сценариев, потому что (несмотря на то, что Zend), они являются основополагающими методами распространения открытого текста. Java и .Net и другие компилируемые языки байт-кода имеют немного большую защиту, но их можно также дизассемблировать в промежуточный код (но обфускация здесь более полезна). Поистине скомпилированные языки (например, c, C ++) обладают наибольшей защитой от всех, так как разбор 50 мегабайта в код ассемблера обычно не так полезен.
Даже тогда нет никаких гарантий. Если вам это не нравится, тогда вам нужно тщательно выбирать своих клиентов, жить с потенциальным нарушением контракта (и возможным принуждением, которое может заставить вас продолжать) или найти другую работу.
Я считаю, что единственный способ убедиться, что вы предлагаете свой продукт в качестве размещенного решения, чтобы клиент никогда не имел доступа к коду. Если вы построите это с учетом этой цели, вы все равно можете иметь реселлеров и позволить им скрыть систему, чтобы она выглядела как собственный продукт.
Это хорошо работает, когда я работаю, теоретически клиенты могут лицензировать код для работы на своей собственной инфраструктуре, но он оценивается на таком уровне, который готовы платить только крупные компании, а крупные компании в целом больше заинтересованы в юридических тонкостях так что с меньшей вероятностью просто сбежать с вашей работой.
Люди очень готовы с радостью пойти с размещенными решениями, если цена правильная, и она может принести пользу всем. Клиенту не нужно беспокоиться о том, чтобы все было настроено, и у них также есть безопасность, зная, что если что-то нуждается в настройке, мы (разработчики) должны это сделать.
Это социальная проблема, а не техническая. У вас есть закон об авторском праве на вашей стороне; больше не нужно. (Все технические решения будут эквивалентны DRM, который по своей сути неэффективен.)
Что касается вашего обновления: так что в основном вы становитесь поставщиком DRM для этого вашего клиента. Итак: понимает ли клиент, что DRM неэффективен? Попробуйте обучить их, прежде чем тратить время на реализацию.
Если клиент остается непреклонным, я бы очень долго смотрел на то, что делают нынешние поставщики DRM. Например, много рук, какая-то обфускация, и … э … я не знаю … что еще они делают? В любом случае, вы можете быть уверены, что любое решение, которое вы реализуете, будет отменено менее чем в 10% случаев, когда вам понадобилось его реализовать, поэтому потратьте на это короткое время, так как вы можете уйти. (Прежде чем он был отредактирован, вы написали «Это в спецификации» о «уверенности в том, что система не продается»: это может означать, что вы согласились построить что-то технически невозможное (вы никогда не сможете быть уверены ) , и потребовал бы, чтобы вы тратили бесконечное количество времени на создание чего-то, что приближается …)
Вы можете исследовать связь приложения с каким-либо центральным реестром при первом запуске (с встроенным отпечатком пальца, который отличается для каждой продажи, поэтому вы знаете, кто передал их код). Таким образом, ваш клиент может узнать, где выполняется приложение, и имеет возможность связаться с теми, кто использует его без разрешения. (Потенциально превращая их в новых платежных клиентов.) Может быть, дать указанному центральному репозиторию возможность отправить сигнал об увольнении? Тем не менее, это очень страшно, и проблемы ответственности будут огромными; избегайте, если это вообще возможно.
Обфускание источника – это больше проблем, чем это стоит, по моему опыту, если вы не пытаетесь сохранить секретный алгоритм.
Я бы предложил сделать следующее:
Если вы действительно волнуетесь, и это не приложение только для интрасети, вы можете расширить его (3) и вставить уникальный скрытый текст на страницы, которые просматривает Google, но не пользователи.
Ничто из этого не остановит решительного вора, но поможет сдержать и обнаружить «случайные» кражи.
Правильный способ запретить перепродажу вашего программного обеспечения – это юридические ограничения, а не технические. Попросите вашего клиента подписать контракт, в котором они соглашаются не перепродавать.
Технические профилактические меры повсеместно делают продукт хуже, также в техническом смысле и снижают ценность для клиентов. Чем сильнее техническая защита, тем больше неприятностей.
Например, предположим, что клиент правомерно хочет изменить свое доменное имя. Должны ли они покупать новую копию? Думаю, нет. Если вы сообщите им, как изменить ключевой файл в соответствии с их новым доменом, они могут затем использовать эту информацию, чтобы позволить им перепродавать. Однако правовая защита применяется независимо от технических приемов, которые они придумывают.
Но проблема заключается в том, что вы не боитесь, что клиент перепродает то, что вы сделали, из коробки, которое можно отслеживать юристами. Проблема может заключаться в том, что клиент реорганизует его. Я имею в виду взять много часов работы и изменить пару вещей и назвать его своим … Продать его за небольшую сумму дешевле и выиграть бизнес …
Вот почему я рассматриваю технические решения для защиты своей работы. Это также, возможно, поможет мне свести счет-фактуру от юристов до минимума, что является существенным изменением от того, чтобы он / она защищал мою работу.
Как я могу быть уверен, что он этого не сделает?
Вы не можете предотвратить это … период. Если у кого-то есть источник, нет способа остановить их … вы можете только затем прибегнуть к наказанию за них, если они это сделают.
Возможно, ваш контракт, помимо того, что он запрещает им перепродавать его, имеет цену, связанную с их перепродажей, то есть примерно 10x или 20x, что вы обычно платите, плюс судебные издержки, если требуется, чтобы заставить их заплатить … таким образом, если они предпочитают делать это в любом случае, у вас есть хороший лист бумаги, с их подписью на нем, у которого уже есть приятная толстая цена, которую они должны заплатить, если они пойдут вперед и продадут ее.
Я не видел упоминания о Ioncube, и поэтому было интересно, есть ли причина не использовать его?
Да, это стоит денег для настройки, и да, для этого требуется установка серверной библиотеки (я полагаю, что большинство хостов в данный момент уже запущено), но это позволяет ограничить доступ к домену, а также ограничения по времени.
Может быть, вы могли бы использовать его вместе с PHPAudit?