При использовании программ для ЭВМ у сторон лицензионного договора возникает масса вопросов. Это в равной степени касается как правообладателей, так и лицензиатов. И одним из таких вопросов является возможность изменения программного продукта в процессе его использования. Законодательно программы для ЭВМ приравнены с литературными произведениями, но то, что касается возможности изменения программного продукта, несомненно, имеет свою специфику.
Давайте попробуем разобраться, что же понимается под изменением, или «переработкой» программы?
По самой сути программный продукт, в отличии от литературного произведения подвержен гораздо более частым изменениям. В отличии от литературного произведения, в случае, например, когда сценарист берет его в основу создаваемого сценария, то даже рядовому пользователю понятно, что неукоснительно должны соблюдаться нормы о «неприкосновенности» исходного литературного произведения. Но так ли происходит с программой для ЭВМ?
Согласно подпункта 9, пункта 2 ст. 1270 ГК РФ: «Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения, в том числе перевод такой программы или такой базы данных с одного языка на другой язык, за исключением адаптации, то есть внесения изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя». [1]
Модифицированный «Куб». Подробный обзор прошедшего месяца
Таким образом, четко становится понятно, что любые действия Лицензиата, которые направлены на возможность подключения, запуска и установки программы, право на которую предоставлено по договору, а также действия для возможности ее беспроблемного взаимодействия с существующим оборудованием, разрешены и будут являться адаптацией Программы.
Зачастую, Лицензиар, он же Правообладатель программы предоставляя право пользования, самостоятельно осуществляет дальнейшие доработки для решения тех или иных задач Лицензиата, для оптимизации определенных бизнес-процессов деятельности его компании. Также, нередко сам Правообладатель осуществляет же и дальнейшую техническую поддержку. Но если все же программа предоставляется Лицензиату в полное его распоряжения для решения тех или иных вопросов, а необходимость доработок неизбежна?
Если объем предоставленного по договору права определен не точно, значит ли это, что Лицензиат имеет возможность используя размытые формулировки, чувствовать себя более спокойно в отношении используемой программы, либо же нет и данное использование четко регламентировано императивными нормами, не взирая на оплошность автора договора?
Как правило, при предоставлении права и определении объема предоставленных прав, договор содержит примерно следующие формулировки:
« право на установку, воспроизведение, хранение в памяти ЭВМ, активацию и запуск исключительно для организации (открытия) и функционирования предприятия, и только в пределах Территории .»
Это достаточно стандартная формулировка, которая и означает, что никакое изменение и модификация не предполагается. Однако, как уже отмечала выше, программа для ЭВМ крайне редко может являть собой статичный продукт, все чаще, возникает необходимость ее изменений для решения конкретной задачи, а иногда это изменение столь значительно, что возникает на ее основе новый программный продукт.
Согласно п. 87 Постановления Пленума Верховного суда от 23.04.19 № 10 «О применении части четвертой Гражданского кодекса Российской Федерации»:
«Переработка произведения предполагает создание нового (производного) произведения на основе уже существующего. Право на переработку произведения является одним из способов использования результата интеллектуальной деятельности и как таковое принадлежит правообладателю, в том числе не являющемуся автором первоначального произведения, который вправе перерабатывать произведение (в частности, модифицировать программу для ЭВМ или базу данных) и осуществлять последующее использование нового (производного) произведения независимо от автора первоначального произведения. Право на переработку произведения может быть передано в числе иных правомочий в рамках передачи исключительного права по договору об отчуждении исключительного права в полном объеме (статья 1234 ГК РФ) либо предоставлено по лицензионному договору (статья 1235 ГК РФ), а также может перейти по установленным в законе основаниям без заключения договора с правообладателем (статья 1241 ГК РФ).» [2]
Таким образом, при заключении лицензионного договора необходимо четко определить каким образом предполагается использование программы – являет ли собой программный продукт окончательный необходимый вариант для решения тех или иных задач, например, для ведения учета при осуществлении розничной продажи, расчета остатков и необходимых поставок. Либо изначально предполагается, что программа будет модифицироваться посредством оказания услуг самим правообладателем, либо же силами программистов компании-Лицензиата.
В данной связи, обеим сторонам договора необходимо четко понимать правовую принадлежность в отношении всех созданных модификаций. Надо отметить, что зачастую дальнейшие усовершенствования программы на руку как Лицензиату, так и самому Правообладателю. Ничто не стоит на месте, и ничто так стремительно не развивается, как рынок цифровых технологий. Поэтому, если различные версии программы будут создаваться, усовершенствую ту, или иную отрасль бизнеса, в том числе и посредством компании, которая использует данный программный продукт по лицензионному договору, это крайне не плохо, однако, дабы не нарушить исключительное право автора и владельца имущественного права, необходима правовая определенность в отношении всех созданных модификаций.
Если в самом лицензионном договоре, либо дополнительно заключенном с ним договором оказания услуг, либо договором «внедрения» отражены нормы, что правообладатель оказывает дополнительные услуги по модификации, доработке и техническому обслуживанию программы, то в абсолютном большинстве случаев правообладатель и будет являться таковым в отношении всех новых программных версий. Если же предполагается, что далее сам Лицензиат посредством своих технических специалистов будет разрабатывать новые версии для используемой программы, то данному аспекту необходимо уделить особое внимание.
Ведь в некоторых случаях, правообладатель не уделив должного внимания данным условиям договора, предоставляет право пользования, но далее получает очень некрасивую историю, когда недобросовестный Лицензиат, на основе предоставленного исходного кода и переданных материалов по программе, осуществил разработку новых версий, тем самым создав новые объекты авторского права, зарегистрировал одну, или несколько программных продуктов на себя, а далее введя их в гражданский оборот, создает всяческие препятствия самому правообладателю. В результате, необходимо доказывать, что в основе созданной программы был использован объект авторского права, который принадлежал ему. Не все так плохо, и это возможно, но долго, трудозатратно, и не всегда однозначно.
Поэтому, мы часто обращаем на это внимание, перед заключением договора, когда дальнейшее сотрудничество кажется безоблачным «бриллиантовым дымом», смоделируйте самую худшую ситуацию и судебное разбирательство по данным основаниям. И может быть тогда это заставит более тщательно продумать все изложенные формулировки, либо обратиться к юристу за профессиональной помощью по подготовке, либо анализу предложенного к подписанию договора.
Источник: zuykov.com
Модификация программы и что лучше менять: исполняемый код или AST программы?
Принципы в заметке общие для почти любого языка программирования и системы исполнения, но акцент будет на jvm. Рассмотрим два основных подхода по модификации программы:
- манипуляции с исполняемым кодом программы после компиляции или во время загрузки кода;
- изменение исходного кода перед компиляцией.
Метафора, связанная с изображением в заметке: программа — это основное здание, а результат трансформации программы — вспомогательная конструкция.
Зачем модифицировать?
Начнем с вопроса зачем программе модифицировать другую программу. Метапрограммирование помогает уменьшить объем boilerplate кода в проекте и концентрироваться на главном, улучшить читаемость кода и решить задачи которые сложно решить другим способом.
Простейший пример в java — JavaBeans и get/set методы для доступа к полям класса, также примером может служить создание билдеров для класса, автореализации equals/hash в IDE и т.п.
Следующий пример — это логирование, автоматическое управление транзакциями. Все к чему привыкли при использовании Spring Framework и редко задумываемся как это реализовано. Но даже Spring создал сложности с конфигурацией и инициализацией фреймворка для новичков, что послужило причиной появления «магического» Spring Boot/Spring Roo. Но это отдельная тема, мы же вернемся к теме модификации программы.
Обфускация и минимизация кода, инструментирующие профилировщики и мир DevOps третий пример для чего нужно модифицировать программу. Думаю, что пропустил другие важные примеры, вы можете дополнить в комментариях.
Итак, зачем модифицировать программу мы определились, теперь рассмотрим, как это обычно делают.
Модификация исполняемых инструкций программы
Можно модифицировать байт-код программы и это самый распространенный способ. Делать это можно как сразу после компиляции, но перед сборкой jar, так и при загрузке класса. В первом случае это будет плагин системы сборки проекта, во втором специальный загрузчик классов или java агент, либо механизм hotswap в jvm. Подход с агентами и загрузчиками классов очень похож на самомодифицирующиеся программы в машинном коде и полиморфные вирусы.
Байт-код файла, который загружает jvm имеет структуру, описанную в официальной документации о формате класса
Приложение javap позволяет просматривать байт-код скомпилированного класса
Пример из официальной документации
Исходный текст класса:
import java.awt.*; import java.applet.*; public class DocFooter extends Applet < String date; String email; public void init() < resize(500,100); date = getParameter(«LAST_UPDATED»); email = getParameter(«EMAIL»); >public void paint(Graphics g) < g.drawString(date + » by «,100, 15); g.drawString(email,290,15); >>
Вывод javap на консоль для байт-кода этого класса:
Compiled from «DocFooter.java» public class DocFooter extends java.applet.Applet < java.lang.String date; java.lang.String email; public DocFooter(); Code: 0: aload_0 1: invokespecial #1 // Method java/applet/Applet.»»:()V 4: return public void init(); Code: 0: aload_0 1: sipush 500 4: bipush 100 6: invokevirtual #2 // Method resize:(II)V 9: aload_0 10: aload_0 11: ldc #3 // String LAST_UPDATED 13: invokevirtual #4 // Method getParameter:(Ljava/lang/String;)Ljava/lang/String; 16: putfield #5 // Field date:Ljava/lang/String; 19: aload_0 20: aload_0 21: ldc #6 // String EMAIL 23: invokevirtual #4 // Method getParameter:(Ljava/lang/String;)Ljava/lang/String; 26: putfield #7 // Field email:Ljava/lang/String; 29: return public void paint(java.awt.Graphics); Code: 0: aload_1 1: new #8 // class java/lang/StringBuilder 4: dup 5: invokespecial #9 // Method java/lang/StringBuilder.»»:()V 8: aload_0 9: getfield #5 // Field date:Ljava/lang/String; 12: invokevirtual #10 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 15: ldc #11 // String by 17: invokevirtual #10 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 20: invokevirtual #12 // Method java/lang/StringBuilder.toString:()Ljava/lang/String; 23: bipush 100 25: bipush 15 27: invokevirtual #13 // Method java/awt/Graphics.drawString:(Ljava/lang/String;II)V 30: aload_1 31: aload_0 32: getfield #7 // Field email:Ljava/lang/String; 35: sipush 290 38: bipush 15 40: invokevirtual #13 // Method java/awt/Graphics.drawString:(Ljava/lang/String;II)V 43: return >
Но модифицировать байт-код вручную имеет смысл только в учебных целях или если вы ниндзя, который любит создавать и преодолевать сложности. The Java Virtual Machine Specification отвечает на большинство вопросов на этом этапе.
В промышленном программировании работу с байт-кодом упрощают библиотеки ASM, javassist, BCEL, CGLIB. После парсинга байт кода, тот же ASM позволяет программисту работать с байт кодом как через Tree API, так и в событийной модели, используя шаблон visitor. Кроме анализа, возможна и модификация, добавление новых инструкций, полей, методов и т.п. В природе существуют и другие библиотеки работы с байт кодом, но их используют реже.
Пример использования API ASM для
анализа байт-кода
Аспектно-ориентированный подход можно считать высокоуровневым способом модификации программы. В реализации AspectJ на уровне агента, загрузчика классов или плагина вся «магия» АОП превращается в манипуляции с байт-кодом классов. Но как это видит программист при разработке отличается от того как модифицируется байт код «под капотом» с помощью того же ASM и BCEL. Если интересно, что фактически добавляет AspectJ в классы вашего приложения, можно включить дамп модифицированных классов и по локоть влезть в этот код, например, с помощью Java Decompiler.
В AspectJ разработчик определяет действия в виде классов, аннотируя их как аспекты и указывая в каких точках программы(Pointcut) их следует вызывать. Синтаксис определения pointcut выражений также достаточно высокоуровневый. Такой подход к модификации байт-кода более прост в использовании для программиста.
Подробнее показывал и рассказывал на примерах в цикле публикаций на хабре
- Диагностируем причину, выживаем в JAR hell: не дышим серой и не варимся в котле
- Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash
- Протоколирование JDBC запросов и их параметров в существующем приложении
- Хабр шелл: встраиваем кросплатформенный ssh server в java приложение
- Внедрение веб консолей в jvm процесс на примере SonarQube
- Доклад: «Аспектно-ориентированное программирование в распределенных системах для java разработчиков и QA»
- Напильники бывают разные или повествование про «напильник» для java программ
Трансформация программы за счет модификации байт-кода имеет свои сильные и слабые стороны:
| подход работает при отсутствии исходных текстов программы | сложность анализа и модификации, при нетривиальных трансформациях |
| независимость от компилятора | отсутствие информации, доступной только в исходном коде |
Трансформация AST исходного кода, метапрограммирование
Теория и практика трансформации исходного кода давно применяется в метапрограммировании, Prolog, Lisp, макросах и препроцессорах языков программирования.
При данном подходе исходный текст программы трансформируется либо дополняется другой программой перед компиляцией, а затем компилируется. Работать удобнее не с самим текстом программы, а с абстрактным синтаксическим деревом построенным из него (abstract syntax tree, AST).
Опять же, удобство метапрограммирования зависит от поддержки его в самом языке программирования. Существует шутка
В Лиспе, если охота аспектно-ориентированного программирования, нужно лишь настругать немного макросов, и готово. В Java, нужен Грегор Кичалес, создающий новую фирму, и месяцы и годы попыток заставить всё работать.
Поэтому в jvm чуть сложнее, хоть механизм reflection и является частью языка и платформа может динамически загружать и исполнять байт-код. Сразу на ум приходят две технологии, которые используют кодогенерацию — JPA static metamodel generator и jaxb code generation. Другой пример — project Lombok, который позволяет автоматически реализовать, то что раньше генерировалось IDE или писалось вручную и поддерживалось разработчиками.
Аннотации проекта Lombok
Реализовано в Lombok это с помощью модификации AST пользовательской программы и кодогенерации.
Схожая функциональность, со своими ограничениями, есть и в java для аннотаций с областью видимости compile time — Annotation Processing Tool.
В случае с парсингом java исходного кода, лучше чем javac и eclipse java compiller вряд ли кто справится. Есть альтернативы, такие как Spoon и JTransformer, но насколько полно они поддерживают спецификацию и сложные классы, даже нет желания проверять.
Раз уж речь идет о jvm, то трансформация исходного текста программы на Groovy является частью самого языка, подобные возможности есть и в языке Scala.
Итак, в модификации исходного кода программы есть слабые и сильные стороны:
| большее количество информации, чем в байт-коде | этап компиляции или интерпретации (память, время) |
| возможности, подобные рефакторингу в IDE | требование к наличию исходных текстов, способа автоматически найти их для заданного класса/jar |
Трансформация AST кода и рекомпиляция во время выполнения
Самая хардкорная часть этой заметки — мысли про перекомпиляцию в рантайм. Модификация и компиляция AST java кода в момент выполнения может быть нужна, если требуются костыли: проект либо полный капролит, либо делать и поддерживать десятки форков разных версий очень трудоемко, либо если его менеджмент и разработчики считают его идеальным и не позволяют никому его модификацию, но при этом исходный текст есть в enterprise maven репозитарии. И этот подход нужен только если задачу невозможно или неудобно решать двумя ранее описанными классами трансформации программы.
С компиляцией все относительно просто. JavaCompiler API позволяет скомпилировать программу из исходного кода в момент выполнения, предоставляя интерфейс независимый от реализации. При изучении манифеста и исходных текстов eclipse EJC компилятора, обнаружил что и он поддерживает JavaCompiler API.
Но при анализе текста программы все равно нет публичного и универсального API для работы с AST. Т.е. придется работать либо с com.sun.source.tree.* либо org.eclipse.jdt.core.dom.*
Задача с поиском исходного текста класса легко решается, если проект публиковался в maven репозитарий вместе с артефактом типа source и в jar с классами есть файлы pom.properties или pom.xml, либо есть некий словарь соответствия названия/хеша артефакта исходному коду соответствующего jar файла и способ получить эти исходники во время работы программы.
Плюсы — для трансформации доступно больше информации, чем есть в байт-коде, применение не требует пересборки проекта и почти так же удобно как и применение AspectJ агента, но при этом трансформацию невозможно было выполнить средствами преобразования байт-кода, либо очень трудоемко.
Минусы такие же, как и у прошлого подхода: память, время, требование к наличию исходного текста программы и способа его найти для данного класса.
Примеры вышесказанного в виде кода ejc+maven будут в ближайшие месяцы, да и задача выбрана вполне жизненная. Сталкивались ли вы с подобным? Какие задачи из вашей практики можно было бы элегантно решить только с помощью трансформации java кода и рекомпиляции во время выполнения?
Кстати, возможности компилятора TinyCC и его размер доказывают, что такой подход возможен и для C программ.
В заметке мы рассмотрели несколько подходов по модификации программы, их сильные и слабые стороны. Модификация исполняемого кода более распространена, но не все задачи можно решить без наличия исходного кода программы и его последующей трансформации.
Источник: habr.com
Как понять модифицированный?
Генети́чески модифици́рованный органи́зм (ГМО) — организм, генотип которого был искусственно изменён при помощи методов генной инженерии. . Основным видом генетической модификации в настоящее время является использование трансгенов для создания трансгенных организмов.
Что такое гмо в продуктах питания?
ГМО — генетически модифицированные организмы — это организмы, в ДНК которых были целенаправленно внесены изменения при помощи методов генной инженерии.
Как получают генно модифицированные продукты?
Генетически модифицированные организмы получают методом трансформации при помощи одного из способов: агробактериальный перенос, баллистическая трансформация, электропорация или вирусная трансформация.
Что такое модифицированное растительное масло?
Это жиры с заданными свойствами— консистенцией, твердостью, температурой плавления, получаемые в процессе гидрогенизации, переэтерификации и гидропереэтерификации.
Что такое гмо и чем оно опасно?
Что такое ГМО и чем ОНО опасно? Сразу ответим без интриг – ничем гмо не опасны, тем более это не «оно», а «он» или «они». ГМО – генетически модифицированный организм, то есть организм с внесенными изменениями в ДНК.
Какие продукты могут быть Генномодифицированы?
Какие продукты чаще всего являются генетически измененными и где их производят? Основными ГМП являются соя, кукуруза, хлопчатник, масличный рапс, картофель, тыква, пшеница, свекла, клубника, папайя, кофе. В числе стран мировых лидеров по созданию и использованию ГМИ — США, Аргентина, Канада, Бразилия, Китай и ЮАР.
Чем вредны продукты с ГМО?
Но не очень точно представляют почему ГМО так вредно. Эксперты выделяют следующие главные опасности употребления в пищу генетически модифицированных продуктов: — подавление иммунитета, аллергия и метаболические расстройства, в итоге прямого воздействия трансгенных белков.
Кто создал ГМО?
Кто и когда создал ГМ организмы (ГМО)?
Первые Трансгенные продукты были разработаны фирмой «Монсанто» (США). Первые посадки трансгенных злаков были сделаны в 1988 г., а в 1993 г. первые продукты с ГМ компонентами появились в продаже.
Что такое ГМО простыми словами?
ГМО (генетически модифицированный организм) — организм, у которого искусственно изменили набор генов. Большинство ГМО — разные виды растений, которые используются в сельском хозяйстве и пищевой промышленности. Когда из таких организмов изготавливают продукты питания, то их называют генетически модифицированной пищей.
Как расшифровать без ГМО?
Маркировку «без ГМО» сегодня можно найти на самых неожиданных продуктах, в этот список входят даже овощи, фрукты, молоко и хлеб. Она свидетельствует о том, что при их производстве не применялись генно-модифицированные организмы, которые внушают страх многих приверженцам здорового питания.
Где не может быть ГМО?
Тем не менее, число противников употребления продуктов, содержащих ГМО, во всем мире растет. Поэтому многие страны отказываются от использования ГМ продуктов. Среди них: Австрия, Венгрия, Греция, Польша, Швейцария. Продукцию этих стран можно употреблять без опаски.
В чем польза ГМО?
Генетически модифицированные продукты имеют свои преимущества. Что касается растений, в них накапливается меньшее количество химикатов, чем в природных аналогах. Сорта с измененными генами устойчивы к различным вирусам, болезням и погоде, они значительно быстрее созревают, а хранятся дольше.
Источник: fortune-project.ru