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

После этих слов я просто проверял Google на Python obsfucation и не поднимал многое из чего-либо. В.Net решении obsfucation был бы первым подходом к Вашей проблеме на платформе окон, но я не уверен, есть ли у кого-либо решения на Linux та работа с Моно.

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

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

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

Лучшее, которое можно сделать с Python, должно затенить вещи.

• Полоса весь docstrings
• Распределяют только скомпилированные файлы .pyc.
• замораживание это
• Затеняет Ваши константы в классе/модуле так, чтобы справка (конфигурация) не показывала все

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

Ни одно из этого не будет мешать решительному взломщику демонтировать байт-код или рыть через Ваш API со справкой, dir, и т.д.

Необходимо смотреть на то, как парни по getdropbox.com делают это для своего клиентского программного обеспечения, включая Linux. Это довольно хитро для взламывания и требует, чтобы некоторое довольно творческое дизассемблирование закончило механизмы защиты.

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

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

Дополнительный можно использовать Python obfuscator как этот (просто погуглил его).

Завися в том, кто клиент, простой механизм защиты, объединенный с разумным лицензионным соглашением, будет далек более эффективный, чем какая-либо сложная система лицензирования/шифрования/путаницы.

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

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

Концентрат при создании Вашего кода, максимально хорошего использовать - наличие счастливых клиентов сделает Вашу компанию намного большим количеством денег, чем предотвращение некоторого теоретического пиратства..

"Есть ли хороший способ решить эту проблему?" Нет. Ничто не может быть защищено от инженерного анализа. Даже встроенное микропрограммное обеспечение на машинах DVD было перепроектировано и представленный Ключ шифрования AACS. И это несмотря на создание DMCA что уголовное преступление.

, Так как никакой технический метод не может мешать Вашим клиентам читать Ваш код, необходимо применить обычные коммерческие методы.

1. Лицензии. Контракты.Условия. Это все еще работает, даже когда люди могут считать код. Обратите внимание, что некоторые Ваши основанные на Python компоненты могут потребовать, чтобы Вы платили взносы перед продажей программного обеспечения с помощью тех компонентов. Кроме того, некоторые лицензии с открытым исходным кодом мешают Вам скрывать источник или источники того компонента.

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

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

4. настройка Предложения на уровнях, столь привлекательных, что они заплатили бы, Вы действительно создаете и поддерживаете улучшения.

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

6. Предложение это как веб-сервис. SaaS не включает загрузок клиентам.

Я понимаю, что Вы хотите, чтобы Ваши клиенты использовали питание Python, но не хотите, представляют исходный код.

Вот мои предложения:

(a) Запись критические части кода как C или библиотеки C++ и затем используют SIP или большой глоток для представления API C/C++ пространству имен Python.

(b) Использование цитон вместо Python

(c) И в (a) и в (b), должно быть возможно распределить библиотеки как лицензируемый двоичный файл с интерфейсом Python.

Действительно ли Ваш работодатель знает, что может "украсть" назад какие-либо идеи, что другие люди добираются от Вашего кода? Я имею в виду, если они могут считать Вашу работу, так можете Вы их. Возможно, взгляд на то, как можно извлечь выгоду из ситуации, привел бы к лучшему возврату инвестиций, чем боязнь, сколько Вы могли потерять.

[РЕДАКТИРОВАНИЕ] Ответ на комментарий Nick's:

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

Теперь, если клиент продает программное обеспечение, они должны изменить уведомление об авторском праве (который недопустим, таким образом, Вы можете предъявить иск и победите-> простой случай).

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

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

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

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

Тот путь, проверки лицензий могут быть выполнены в безопасности Вашей собственной серверной.

Не полагайтесь на путаницу. Как Вы правильно пришли к заключению, это предлагает очень ограниченную защиту. ОБНОВЛЕНИЕ: Вот ссылка на бумагу , который перепроектировал запутываемый код Python в Dropbox. Подход - переотображение кода операции является хорошим барьером, но ясно это может быть побеждено.

Вместо этого как много плакатов упомянули, делают его:

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

, С другой стороны, поскольку задница удара Python IDE WingIDE делает: Открывают код . Правильно, отдайте код и сделайте, чтобы люди возвратились для обновлений и поддержки.

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

Хотя нет никакого идеального решения, следующее может быть сделано:

1. Передвигают некоторую критическую фигуру кода запуска в собственную библиотеку.
2. Осуществляют проверку лицензий в собственной библиотеке.

, Если бы вызов к собственному коду должен был быть удален, программа не запустилась бы так или иначе. Если это не будет удалено тогда, то лицензия будет осуществлена.

, Хотя это не межплатформенное или решение чистого Python, оно будет работать.

Python не является инструментом, в котором Вы нуждаетесь

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

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

Путаница действительно трудна

, Даже скомпилированные программы могут быть перепроектированы, так не думайте, что можно полностью защитить любой код. Можно проанализировать запутываемый PHP, повредить ключ шифрования флэш-памяти и т.д. Более новые версии Windows взламываются каждый раз.

Наличие законного требования является хорошим способом пойти

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

защита Кода переоценена

В наше время, бизнес-модели имеют тенденцию идти для продажи услуг вместо продуктов. Вы не можете скопировать сервис, пирата, ни украсть его. Возможно, пора рассмотреть для движения с потоком...

Поставка .pyc файлы имеет свои проблемы - они не совместимы ни с какой другой версией Python, чем версия Python, с которой они были созданы, что означает, что необходимо знать, какая версия Python работает на системах, на которых будет работать продукт. Это - очень ограничивающий фактор.

Еще одна попытка усложнить кражу вашего кода - использовать jython, а затем использовать java obfuscator .

Это должно работать очень хорошо, поскольку jythonc переводит код Python в Java, а затем Java компилируется в байт-код. Так что, если вы запутаете классы, будет очень трудно понять, что происходит после декомпиляции, не говоря уже о восстановлении реального кода.

Единственная проблема с jython заключается в том, что вы не можете использовать модули Python, написанные на C.

Идея иметь лицензию с ограничением по времени и проверять ее в локально установленной программе не работает. Даже при идеальной обфускации проверку лицензии можно убрать. Однако, если вы проверите лицензию в удаленной системе и запустите значительную часть программы в своей закрытой удаленной системе, вы сможете защитить свой IP.

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

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

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

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

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