Долго думали втроём, но так и не пришли к решению следующей проблемы:
Есть CMS. Необходимо реализовать систему лицензионных ключей / обновлений системы. Должно быть так: человек покупает систему и получает от нас лицензионный ключ на одну копию системы. тот ключ используется при загрузке обновлений системы. Проблема стоит вот в чём: как остледить, используется ли этот ключ только на одном сайте или на нескольких? Может человек установил себе вторую копию системы на поддомен и хочет нахаляву загружать обновления. Соединение с сервером обновлений будет осуществляться, как мы решили, по сокетам, куда будут писаться необходимые данные, а в ответ получать обновления.

Есть у кого мысли?

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

Спасибо, мысль достаточно интересная, надо подумать.

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

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

На одном IP может быть дофига сайтов. Может просто проZendить всё это и не париться?

Вариант первый - обфускация кода.
Вариант второй - открытое ПО с donate системой, как мне кажется больше получишь.
Вариант третий - с ключами. НО ключ привязывается к каким лмбо персональным данным, которые люди не желательно будут распространять. К примеру фамилия. При это варианте все равно будет работать варежная система для своих.

А чем твой первый вариант мешает использованию системы на другом сайте???

Если в conf.php будет какая-ть конфигарция привязывающая скрипт к одному серверу, то запустить его на другом - проблематично.

Mal Hack, Вариант с персональными данными очень понравился. А donate-система это как?

Это как mozilla.org. За ПО не платишь, а если хочешь спонсируешь по мере сил и возможностей.

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

Поподробней, пожалуйста.

Да, мне тоже интересно.

Добавлено @ 02:46 
Как я понял, IonCube - такой шифровальщик. А чем ZendEncoder не устраивает? Ведь он более распространён на хостингах.

Да ничего бороть не надо.
Если дело конечно только в обновлении.
После установки генерируется ключ. Абсолютно любой. И регистрируется в системе обновлений.
При обновлении система проверяет ключ и если он совпадает выдает новое обновление. После чего генерирует новый ключ. Передает его копии программы и регистрирует у себя.

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

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