И ещё несколько слов о защите разработок...

Для 1С 8.х (7.7 не рассматриваем как устаревший продукт) есть следующие пути закрытия кода:

  1) Штатными средствами - т.е. поставка без исходных текстов, т.е. скомпилированный . Эта защита являлась действенной (для меня по крайней мере) до тех пор, пока не понадобилось изменить защищенный таким образом код. Взлом защиты в этом случае состоит из двух этапов - получение из базы (структура ее не документирована) необходимых модулей и декомпиляция их. На данный момент существует как минимум две методики получения необходимых модулей. Создание качественного декомпилятора занимает у специалиста (у меня ) неделю. На просторах интернета в свободном доступе можно найти несколько версий декомпилятора. В связи с этим, защита данным методом считается защитой очень слабой. Тем не менее, некоторые разработчики систем защиты (например АЗК http://www.ailant-distribution.ru/goods/protect/ ) считают, что защита действенна.

  2) Портирование кода на другие языки. Надежность защиты в этом случае зависит от возможности восстановления исходных текстов (или логики) и возможности модификации для удаления защиты. С учетом того, что восстановление текста на С++ (например) задача не тривиальная (как минимум для подавляющего числа людей хорошо знакомых с 1С), защиту можно считать надежной. Однако такой же не тривиальной задачей является портирование кода с 1С на С++. Поэтому данный вариант применяется очень редко.
Тиражных решений, которые позволяют использовать этот вариант для защиты конфигураций я не знаю (если не считать таким вариантом СЗК).

3) Вынесение кода внешних обработок (т.е. модулей, которые не являются частью конфигурации, и хранятся в отдельных файлах) в какое-либо зашифрованное хранилище. В этом случае создание объекта такого модуля возможно только при использовании внешней компоненты, которая проверяет возможность работы с таким модулем. Примером такой системы защиты могут служить комплексы СЗК (http://www.1c.ru/news/info.jsp?id=3046), СЛК (ссылку найти не удалось, может кто подскажет?), Интелис: Защита Конфигураций в.1 (http://www.intelis-it.ru/software/intelis/safety.html ). Однако с учетом логики работы 1С с внешними обработками (например, 1С хочет расшифрованный файл на диске как минимум на время создания объекта, ...), есть возможность получить эту обработку как файл и далее взлом защиты сводится к декомпиляции кода (как правило, защищаемые обработки поставляются без исходного текста). Замечу, что такой возможности при использовании системы ИЗК нет — обработка не появляется в расшифрованном виде на диске никогда. 

  4) Исполнение зашифрованных исходных текстов 1С во внешней компоненте. Для этого могут использоваться как собственные компиляторы / интерпретаторы (например, в СЗК), так и особенности 1С (возможность, доступная только при особой интерпретации документации 1С, используется в Интелис: Защита Конфигураций в.1 и в КЗ (http://keyprotect.ru/ )). Надежность данного метода можно считать высокой, т.к. исполняемый текст появляется только в памяти и только на время выполнения этого текста. Недостатком является сложность отладки такого кода и необходимость обработки конфигурации перед созданием поставки. Таким образом, этот метод стоит использовать для защиты текстов запросов и алгоритмов построения текстов, т.е. объемных, но не сложных по структуре алгоритмов, для создания которых наличие отладчика не обязательно.
Хотя я и сказал, что "надежность данного метода можно считать высокой", это не совсем так. Точнее это зависит от реализации. Методику применненную в СЗК я особо не исследовал, т.к. не нашел реальных примеров. Реализация используемая в КЗ не представляет особых сложностей для взлома. Реализация ИЗК 1 чуть лучше, но со временем я нашел и в ней дыры.

  5) Прочие мало применяемые на практике механизмы – например сохранение и выполнение зашифрованных текстов запросов (например это используется в КЗ и в GoldenKey - отдельного сайта я не нашел, пример применения: //infostart.ru/public/78661/ ). Однако, с учетом того, что подавляющее большинство запросов, которые имеет смысл защищать, строятся в результате работы какого-либо алгоритма, данный способ мало применим. Так же в зависимости от реализации этот способ может быть надежным, а может быть только видимостью защиты (как в КЗ и в GoldenKey ) (см. http://forum.infostart.ru/forum24/topic61383/message675325/#message675325 и несколько постов ниже)
Есть и другие варинты - обфускация текстов, ...

  6) Обфускация п-кода скомпилированного модуля 1С (т.е. изменение п-кода, таким образом, чтобы 1С могла работать с этим кодом, а декомпилятор не смог бы восстановить исходный текст). Этот метод на данный момент мало распространен, хотя защита в этом случае достаточно высока, по крайней мере до тех пор, пока не будут созданы декомпиляторы, которые умеют работать с таким п-кодом.
С другой стороны, широкое использование данного метода приведет к появлению инструментов, которые будут позволять изменять непосредственно п-код для достижения требуемой задачи (например отвязка от ключа или изменение функционала). Этот медод защиты наиболее трудоемок для взлома на данный момент, поэтому я считаю его наиболее надежным.
На момент написания этих строк, существует единственное тиражное решение использущее эту методику: Интелис: Защита Конфигураций в.2 (http://www.v8-zk.ru , http://www.intelis-it.ru/software/intelis/safety.html , //infostart.ru/public/68368/ ) и не существует инструментов, позволяющих получить исходный текст защищенного модуля. 
Принцип обфускации кода для защиты от декомпиляции основан на том, что при компиляции конструкции языка 1С транслируются в определенные последовательности команд исполняющей машины. Конкретные конструкции в конкретные последовательности. На этом строится алгоритм декомпиляции. Если же заменить эти последовательности команд на идентичные по логике но отличные по составу команд - декомпилятор не может распознать исходную конструкцию. Если же новая последовательность будет к тому же случайной по составу команд (но не по общей логике) то задача декомпиляции еще усложнится.