(Слыщенков В. А., Левин А. Е.) («Правовые вопросы связи», 2009, N 1)
ВОПРОСЫ ЛИЦЕНЗИРОВАНИЯ ОТКРЫТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В. А. СЛЫЩЕНКОВ, А. Е. ЛЕВИН
Слыщенков В. А., старший юрист.
Левин А. Е., юрист ООО «Балтийское Юридическое Бюро».
В последнее время в России высок интерес к открытому и свободному программному обеспечению. Между тем юридические аспекты использования открытых (свободных) программ еще не прояснены окончательно. Следует отметить различие между свободным ПО, с одной стороны, и открытым ПО — с другой. Если сторонники свободных программ (free software) делают акцент на этической стороне вопроса, ставят свободу распространения и использования ПО в один ряд со свободой слова <1>, то движение открытого программного обеспечения (open software или open source software), напротив, подчеркивает коммерческий аспект и экономическую выгоду <2>. Однако в практических вопросах распространения и лицензирования программ оба направления придерживаются в основном одних и тех же подходов. Соответственно, говоря в дальнейшем о лицензировании открытых программ, мы имеем в виду как открытое, так и свободное программное обеспечение. ——————————— <1> URL: http://www. gnu. org/philosophy. См.: интервью Р. Столлмана в журнале CNEWS. 2008. N 4(34). С. 86 — 89. <2> URL: www. opensource. org. См.: Слыщенков В. А., Левин А. Е. Охрана программ для ЭВМ: в поисках эффективных правовых решений // Юрист. 2008. N 8. С. 14 — 15.
Лицензирование открытого программного обеспечения: основные моменты
Открытые программы завоевывают отдельные сегменты рынка, с выгодой пользуясь преимуществами, которые дает свобода обращения с исходным кодом программы, та свобода, которой лишены пользователи обычных, собственнических программных продуктов, в полной мере защищенных авторским правом (а иногда и патентным законодательством). Но указанная свобода не является абсолютной; в каждом конкретном случае объем свободы устанавливается лицензией, по которой распространяется программа. Выбор лицензионных условий имеет большое значение в контексте дальнейшего усовершенствования и распространения программного продукта. Как и обычные лицензии, ориентированные на защиту авторских прав, которые существуют во множестве вариантов (отличающихся друг от друга иногда существенно, но порой лишь в частностях), так и лицензии на открытое ПО могут быть составлены вполне произвольным образом. Однако имеются ограничения: во-первых, лицензионные условия должны быть такими, чтобы распространяемая программа могла быть определена как открытая программа, но не собственническое (т. е. в полной мере защищенное авторским правом) программное обеспечение; во-вторых, Инициатива открытого кода (Open Source Initiative) ведет список лицензий, которые эта авторитетная организация признает лицензиями на открытое ПО <3>. ——————————— <3> URL: http://www. opensource. org/licenses. Отметим, что такой список поддерживает и Фонд свободного программного обеспечения (URL: http://www. fsf. org/licensing/licenses), а также иные организации в области свободного и открытого ПО.
Лицензия на открытую программу, или открытая лицензия <4>, должна соответствовать следующим обязательным критериям: (1) не ограничивать в свободном распространении программы, в том числе нельзя запретить распространение вместе с какими-либо иными программами и нельзя требовать уплаты платежей в зависимости от распространения (роялти); (2) обеспечивать доступ к исходному коду; (3) разрешать изменения и производные продукты, а также их распространение на условиях лицензии на первоначальную программу; (4) запрещать изменения исходного кода лишь при условии, что разрешается распространять файлы с исправлениями совместно с данным исходным кодом для его изменения в определенный момент, а также разрешается распространять программное обеспечение, полученное в результате такого изменения; (5) исключать дискриминацию каких-либо лиц или групп лиц; (6) не запрещать использование программного продукта в каких-либо областях человеческой деятельности; (7) применение лицензионных условий не должно быть ограничено какими-либо дополнительными соглашениями; (8) права на программу не должны зависеть от того, является ли программа частью определенного иного программного обеспечения или сборника программ, разрешается выделять программу и распространять ее отдельно; (9) лицензия не должна накладывать ограничения на другие программы, распространяемые совместно с открытой программой, в том числе не должна требовать, чтобы такие другие программы также относились к открытому программному обеспечению; (10) лицензия должна быть технологически нейтральной, т. е. распространение и использование программы не должны быть привязаны к определенной технологии или интерфейсу <5>. ——————————— <4> Российское законодательство знает механизм «открытой лицензии» применительно к лицензированию промышленной собственности (ст. 1368 ГК), где он имеет сходное практическое значение. <5> URL: http://www. opensource. org/docs/osd; http://www. open-source. org/docs/definition. php; http://citkit. ru/articles/272
Как видно из вышесказанного, понятие «открытое программного обеспечение» относится не к программам как к таковым, а к способу и границам их использования и распространения (лицензирования). Если законодательство, в том числе российское, традиционно направлено на защиту авторских прав <6>, то для движения открытого (и свободного) ПО авторские права, напротив, не являются основной ценностью. Согласно Р. Столлману авторское право на программы ведет к монополии, с которой нужно бороться <7>; равным образом Инициатива открытого кода, унаследовав это негативное отношение, отрицает безусловную защиту авторских прав на программное обеспечение. «Авторское лево» (copyleft) — шуточный термин, но при этом вполне серьезная юридическая конструкция — предполагает, что в процессе дальнейшего распространения как программа, так и ее модификация должны оставаться (не в меньшей степени) открытым (или свободным) программным обеспечением. Хотя ни Фонд свободного программного обеспечения, ни Инициатива открытого кода не требуют, чтобы программы всегда лицензировались с позиции авторского лева, тем не менее оба движения в той или иной степени опираются на этот юридический механизм и способствуют его развитию <8>. ——————————— <6> Ср. известную оговорку в уведомлениях об авторских правах: «Все права сохранены» (all rights reserved). См.: п. 1 ст. 1235 ГК: «Право использования результата интеллектуальной деятельности или средства индивидуализации, прямо не указанное в лицензионном договоре, не считается предоставленным лицензиату». <7> См.: CNEWS. 2008. N 4(34). С. 87. <8> URL: http://www. gnu. org/copyleft/copyleft. html; на русском языке: http://www. gnu. org/copyleft/copyleft. ru. html.
Многообразие лицензий на открытое программное обеспечение
Так как, несомненно, каждый может составить особую лицензию на собственную открытую программу, появилось большое количество лицензий, отличающихся друг от друга, несмотря на то обстоятельство, что все они соответствуют вышеназванным критериям лицензирования открытых программ. И поскольку любая лицензия может установить, что в ходе дальнейшего распространения не допускается подчинять использование программы никаким дополнительным ограничениям или две лицензии просто содержат противоречащие положения, постольку возникает проблема совместимости (compatibility) лицензий. Лицензии совместимы, если одну можно заменить на другую, т. е. если тот же или модифицированный продукт можно распространять далее по какой-либо другой лицензии, не той, по которой был получен оригинальный продукт. Проблема совместимости проявляется при дальнейшем распространении измененной (модифицированной <9>) пользователем программы, которая получена им по лицензии от третьих лиц, в том числе при создании некой новой программы на основе исходного кода нескольких программ. Так, по объяснению Р. Столлмана, две разные авторско-левые (copyleft) лицензии в принципе не являются совместимыми друг с другом, так как каждая из них требует, чтобы лицензирование измененной программы подчинялось тем же условиям, которые зафиксированы в лицензии, по которой была получена исходная программа <10>. Соответственно программный продукт, полученный в результате модификации из двух или более открытых программ (лицензированных по разным авторско-левым лицензиям), нельзя лицензировать ни по одной из лицензий. Он же приводит еще один пример (его можно считать курьезным), когда лицензия несовместима сама с собой. Пункт 8 раздела «Условия распространения и изменения» (Conditions on Distribution and Modification) лицензии The LaTeX Project Public License (LPPL Version 1.2 1999-09-03) <11> устанавливает, в частности, что модифицированная программа должна распространяться таким образом: исходная программа совместно с отдельным файлом, содержащим изменения. Таким образом, если новая программа создана на основе двух или более программ, каждая из которых получена по отдельной лицензии LPPL Version 1.2, ее вообще нельзя лицензировать (без нарушения этого лицензионного условия). Исходная программа не может распространяться как файл с изменениями (к другой программе), только в виде неизмененной копии, но очевидно, что лишь одна программа (из всех использованных при модификации программ) может в дальнейшем распространяться в такой форме, а все остальные становятся файлами с изменениями. ——————————— <9> См. о понятии «модификация»: подп. 9 п. 2 ст. 1270 ГК. <10> URL: http://fsfeurope. org/projects/gplv3/fisl-rms-transcript#license-compatibility <11> URL: http://www. latex-project. org/lppl/lppl-1-2.txt
В классе лицензий на открытое ПО различие между авторско-левыми <12> и простыми разрешительными (permissive) лицензиями (т. е. лицензиями, которые предоставляют пользователям соответствующие свободы, но не требуют дальнейшего распространения исходной или измененной программы на тех же условиях <13>) является лишь одним из различий, значимым в контексте вопроса о многообразии и совместимости лицензий. Помимо указанного надлежит отметить ряд других существенных моментов, по отношению к которым лицензии на открытое ПО могут отличаться друг от друга. ——————————— <12> Лицензии GNU General Public License (GPL) version 3 (GPLv3), GNU Lesser General Public License (LGPL) version 3 (LGPLv3) и др. <13> Например, лицензия Apache License 2.0, лицензии BSD.
Авторское лево может быть сильным или слабым. Так, сильная авторско-левая лицензия GNU General Public License (GPL), версия 3, устанавливает в разделах 4 — 6, что исходная программа и любые ее модификации должны распространяться лицензиатом только на условиях этой же лицензии GPLv3 <14>. Слабая авторско-левая лицензия GNU Lesser General Public License (LGPL), версия 3, допускает, что программный продукт может распространяться по лицензии LGPLv3 в одной программной библиотеке совместно с продуктами, распространяемыми по других лицензиям, в том числе собственническими (разделы 3 — 5) <15>. Таким образом, слабое авторское лево требует распространять с позиции авторского лева только собственно исходную программу и ее изменения (см. раздел 2 лицензии LGPLv3), но не программный продукт, полученный по другим лицензиям и совмещенный с открытой авторско-левой программой. Вероятно, к классу слабого авторского лева также можно отнести лицензию, требующую сохранять все вышеуказанные свободы пользователя при распространении только исходной программы, но не ее изменений (в определенной степени). ——————————— <14> URL: http://www. fsf. org/licensing/licenses/gpl. html <15> URL: http://www. fsf. org/licensing/licenses/lgpl. html
Полное авторское лево следует отличать от частичного авторского лева: если при полном авторском леве свободам пользователя подчинены все компоненты программы, то частичное авторское лево выводит из-под действия свобод определенные части программы. Система лицензирования открытого ПО (в частности, авторское лево) должна быть отграничена от лицензий, созданных в рамках некоммерческого проекта Creative Commons. Последний предлагает на выбор ряд лицензий, отличающихся с точки зрения объема пользовательских свобод <16>. Соответственно, только некоторые лицензии Creative Commons отнесены Фондом свободного программного обеспечения к свободным лицензиям <17>. В Creative Commons используется подобная авторскому леву конструкция «share-alike», что можно перевести как «распространяй таким же образом». ——————————— <16> URL: http://creativecommons. org/about/licenses/ <17> URL: http://www. fsf. org/licensing/licenses/
Хотя вопрос о совместимости лицензий освещался выше применительно к открытым программам, этот же вопрос может возникать и в области собственнических программ. Например, лицензия на собственническую программу (полученную в виде исходного кода) может запрещать лицензирование измененной программы в форме открытого ПО, таким образом, данная собственническая лицензия и любая из открытых лицензий оказываются несовместимыми; и наоборот, любая авторско-левая открытая лицензия несовместима с собственнической лицензией. Однако именно внутри области открытого ПО проблема несовместимости лицензий приобрела острое звучание, поскольку несовместимость лицензий на практике подрывает те пользовательские свободы, которые являются сутью и основой движения за открытые и свободные программы. Если автор программы, использовавший в своей работе две или более открытые программы, не может распространять свой продукт ни по одной из лицензий ввиду несовместимости лицензий, то это является существенным минусом юридической модели в целом. Существует несколько способов преодоления этой проблемы. Одним из них является так называемое двойное лицензирование (dual licensing), когда один и тот же продукт лицензируется по нескольким лицензиям одновременно; пользователь вправе выбрать любую лицензию для целей изменения и дальнейшего распространения программы. Помимо этого, и Фонд свободного программного обеспечения, и Инициатива открытого кода предприняли меры, направленные против чрезмерного увеличения количества лицензий. Как уже указывалось выше, Фонд свободного программного обеспечения ведет перечень одобренных свободных лицензий; кроме того, призывает разработчиков использовать GPL лицензии. Процедура рассмотрения и одобрения лицензий существует и в рамках Инициативы открытого кода, и одной из ее целей указано «противодействие создаваемым из тщеславия (vanity) и дублирующим лицензиям» <18>. ——————————— <18> URL: http://www. opensource. org/approval; см. также: http://www. opensource. org/proliferation-report.
Еще одним вариантом преодоления проблемы несовместимости лицензий является допущения изменений (в определенных пределах) лицензии, по которой получен исходный программный продукт. Разработчики могут частично менять лицензию в своих интересах вместо того, чтобы использовать другую лицензию. Этот способ реализован, например, в лицензии GPLv3 (раздел 7 <19>). Аналогичным образом лицензия может прямо допускать дальнейшее распространение по другим лицензиям, которые указаны в данной лицензии как совместимые с ней <20>. ——————————— <19> URL: http://www. fsf. org/licensing/licenses/gpl. html <20> Например, лицензия Creative Commons Attribution-ShareA-like 3.0 Unported, п. 4(b) // URL: http://creativecommons. org/li-censes/by-sa/3.0/legalcode.
Многообразие лицензий на открытое ПО, создавшее проблему несовместимости лицензий, является одним из существенных вопросов, которые нужно учитывать юристу, работающему с лицензиями на открытые программные продукты. Другие вопросы, на которые следует обратить особое внимание, связаны с юридическим эффектом открытой лицензии, а именно: насколько эффективна данная лицензия в предоставлении пользователям определенных свобод и насколько лицензия законна или подлежит судебной защите.
Юридический эффект открытой лицензии
Цель открытой лицензии, в особенности авторско-левой открытой лицензии, состоит в безусловной передаче пользователям ряда свобод, но практическое достижений этой цели зависит от формулировок лицензии и от того обстоятельства, насколько полно лицензия предусмотрела и исключила разнообразные риски ограничения этих свобод. Хорошей иллюстрацией служит третья версия лицензии GPL, которая включает ряд новых положений, направленных на борьбу с ограничениями пользовательских свобод <21>. Составители указали на следующие новые риски: тивоизация (tivoization), управление цифровыми правами (Digital Rights Management, DRM <22>), патенты на программные решения <23>. ——————————— <21> URL: http://www. ifso. ie/documents/gplv3-launch-2006-01-16.html#em-warranty <22> В связи с критическим отношением к этому явлению в Фонде свободного программного обеспечения появился новый термин (с сохранением аббревиатуры): Digital Restrictions Mismanagement (неправильное управление цифровыми ограничениями). <23> URL: http://www. fsf. org/licensing/licenses/quick-guide-gplv3.html#neutralizing-laws-that-prohibit-free-software-but-not-forbidding-drm; http://www. fsf. org/licensing/licenses/gpl. html
Термин «тивоизация» (по названию компании TiVo Inc.) обозначает запрет, реализованный посредством таких технических способов, как криптографические методы защиты, запускать на данном оборудовании измененную программу. Таким образом, хотя бы компьютер или иное оборудование было поставлено с предустановленной открытой программой (соответственно предоставлен исходный код), модификацию этой программы не удастся запустить на том же оборудовании. Фонд свободного программного обеспечения рассматривает подобную практику как нарушение свобод пользователя. Лицензия GPLv3 включила требования о предоставлении всей информации для инсталляции модифицированной программы (раздел 6); при нарушении этого требования (как и в случае любых иных нарушений) лицензия (на исходный продукт) прекращается в отношении допустившего нарушение лицензиата (раздел 8). Под управлением цифровыми правами (DRM) понимаются разнообразные технические приемы и способы, посредством которых достигается контроль за использованием программы или иного объекта авторских прав на том или ином оборудовании. К DRM не относится, например, индивидуальный цифровой ключ для запуска программы, но относится такой известный прием, как коды DVD-дисков, обеспечивающие условие, что видеодиск, предназначенный для продажи (и проданный) в определенном регионе мира, не будет воспроизводиться DVD-проигрывателем, проданным в другом регионе мира. GPLv3 не запрещает создание и распространение программ с DRM (как сугубо техническим методом контроля). Однако лицензия исключает программу, распространяемую по GPLv3, из числа «эффективных технологических мер» (effective technological measures) в смысле ст. 11 Договора ВОИС по авторскому праву от 20 декабря 1996 г. Эта статья требует от национальных законодательств ввести запрет на обход эффективных технологических мер и направлена в том числе на запрет обхода DRM. Поэтому преодоление DRM, инкорпорированного в программу, распространяемую по GPLv3, по замыслу составителей лицензии, не может быть юридически наказуемо. Более того, раздел 3 прямо говорит, что лицензиар не запрещает обход эффективных технологических мер, заранее отказывается от всех средств правовой защиты и требований в случае создания лицензиатом программы, позволяющей преодолеть эффективные технологические меры. Патентная охрана реализованных в компьютерных программах технических решений, или программных решений, широко предоставляется в США; то же относится и к Европейскому союзу: несмотря на определенное общественное противодействие, Европейское патентное ведомство выдает патенты на программные решения <24>. Российское законодательство также позволяет патентовать программные решения, поскольку, подобно ст. 52 Европейской патентной конвенции, устанавливает, что программы для ЭВМ не патентуются в качестве изобретений только как таковые (п. 5 ст. 1350 ГК); кроме того, ст. 1351 ГК не запрещает патентование программы как части полезной модели, т. е. «технического решения, относящегося к устройству». Таким образом, если заявитель докажет, что программа подлежит защите не сама по себе, но как элемент определенного технического решения, ее патентование в России возможно. И действительно, уже сейчас имеются примеры выданных Роспатентом патентов на программные решения <25>. Между тем практика патентования программных решений представляет угрозу для движения открытого ПО. Патенты представляют собой особый способ защиты интеллектуальной собственности; открытая лицензия (составленная по правилам законодательства об авторских правах) и сопутствующее раскрытие исходного кода не могут защитить лицензиата от обвинений в нарушении патента. Чтобы обезопасить себя от таких исков, по общему правилу пользователь должен получить дополнительную (помимо авторской лицензии на программу) лицензию на использование изобретения или полезной модели. ——————————— <24> См.: Слыщенков В. А., Левин А. Е. Указ. соч. С. 12 — 13. <25> Подробнее о патентовании программных решений в России см.: Ревинский О. Еще раз вокруг колеса // Компьютерра. 2003. 9 дек. N 47; URL: http://offline. computerra. ru/offline/2003/522/31161/index. html.
Ответом на риск патентного ограничения свобод пользователя стал раздел 11 GPLv3, согласно которому «вкладчик» (contributor) предоставляет лицензиату по GPLv3 «неисключительную, всемирную, не предусматривающую периодических платежей или платежей, зависящих от использования (роялти), патентную лицензию, в рамках существенных патентных притязаний вкладчика, на воспроизведение (make), использование, продажу, предложение на продажу, импорт и использование иным образом, изменение и распространение содержания версии вкладчика» <26>. Возможно, вкладчик (лицензиар по GPLv3) не вправе выдавать сублицензии в рамках существенных патентных притязаний; тогда вкладчик должен обеспечить, что лицензиат получит (от правообладателя) аналогичную лицензию на использование защищаемого патентом программного решения. Если при лицензировании программы по GPLv3 вкладчик предоставил патентную лицензию на программное решение, то эта лицензия (или сублицензия) автоматически распространяется на всех последующих сублицензиатов по GPLv3. ——————————— <26> Согласно тому же разделу лицензии вкладчиком (contributor) является правообладатель (защищаемого патентом исключительного права) или лицензиат от правообладателя, который лицензировал по лицензии GPLv3 программу или работу, на которой программа, лицензируемая по GPLv3, основана; существенные патентные притязания (essential patent claims) — это (определяемый формулой изобретения или полезной модели) объем охраны по любым патентам, которые принадлежат вкладчику или контролируются им (т. е. им могут выдаваться сублицензии на условиях, не противоречащих GPLv3) и которые были бы нарушены использованием, допускаемым GPLv3, а именно воспроизведением, использованием, продажей версии вкладчика, исключая патенты, которые могут быть нарушены в результате модификации версии вкладчика. Под «версией вкладчика» понимается программа, лицензируемая по GPLv3, а также работа, на которой такая программа основана.
Юридический эффект лицензии на открытую программу может быть ограничен действующим законодательством, когда лицензия в целом или какие-либо отдельные положения лицензии вступают в противоречие с нормами закона. Например, согласно ст. 1369 ГК лицензионный договор о предоставлении права использования изобретения или полезной модели подлежит регистрации в Роспатенте, в противном случае в соответствии с п. 2 ст. 1235 ГК договор недействителен. Если GPLv3 подчиняется российскому праву, то положение этой лицензии о предоставлении прав на защищенное патентом программное решение является недействительным ввиду отсутствия регистрации. Даже если GPLv3 подчиняется иностранному праву, тем не менее установленное ст. 1369 ГК правило о регистрации относится, очевидно, к императивным нормам в смысле п. 1 ст. 1192 ГК, а значит, и в этом случае российский суд должен прийти к выводу о недействительности соответствующего положения GPLv3 по причине отсутствия регистрации. Пример выше показывает, что при работе с открытыми лицензиями необходимо принимать во внимание особенности национального законодательства. Отметим, что юридический эффект и законность открытой лицензии в целом, а не только ее отдельного положения, может быть поставлен под сомнение. Тем не менее до настоящего времени, как представляется, открытые лицензии успешно избегают этой опасности. Хорошей иллюстрацией является дело Jacobsen v Katzer, рассмотренное Федеральным апелляционным судом США в 2008 г. <27>. ——————————— <27> URL: http://www. cafc. uscourts. gov/opinions/08-1001.pdf
Истец в данном деле утверждал, что нарушение ответчиком Artistic License (одной из распространенных открытых лицензий) стало нарушением исключительных прав лицензиара; ответчик, напротив, заявлял, что нарушение лицензии, которое действительно имело место, является нарушением лишь договорного обязательства <28>. Ответчик не выполнил ряд правил, которыми данная лицензия обусловливает свободное изменение и распространение программного продукта, в частности, не указал имена авторов исходной программы <29>. В случае если это нарушение не признается нарушением исключительных прав, а только нарушением договорных условий, то средства правовой защиты истца и объем ответственности ответчика иные (в частности, лицензиар не может требовать судебного запрета нарушающих лицензию действий ответчика). В основе аргументации ответчика лежало утверждение, что лицензиар не имеет никакой экономической выгоды от соблюдения своих исключительных прав, так как исходный код программы доступен любому желающему бесплатно. Этот момент имеет важное значение, поскольку авторское право в США ориентировано на защиту имущественных прав, нарушение которых влечет убыток для правообладателя <30>. ——————————— <28> В случае неисполнения лицензионного договора лицензиар обычно не может предъявить к лицензиату иск о нарушении исключительных прав, только о нарушении договорных обязательств; но если лицензия ограничивает объем использования объекта исключительных прав и лицензиат вышел за пределы этого ограничения, то лицензиар может предъявить иск о нарушении исключительных прав. См.: Ibid. <29> См.: Ibid. <30> См.: Ibid.
Нетрудно увидеть, что спор касается основ лицензирования открытого программного обеспечения, а именно вопроса о доступности для лицензиара по открытой лицензии всех без исключения средств правовой защиты, которые предоставляет авторское право США. Отрицательный ответ может поставить лицензиара в невыгодное положение по сравнению с тем, которым пользуются правообладатели собственнического программного обеспечения. В экономических терминах система открытого ПО основывается на идее сотрудничества нескольких программистов. Когда один из разработчиков предоставляет исходный код своей программы, он рассчитывает на то, что его коллега, посредством изменений и дополнений исходной программы, обогатит разработку. Таким образом, общая цель — работающая и качественная программа — достигается совместными усилиями с соответствующим распределением расходов между всеми вовлеченными программистами <31>. ——————————— <31> См.: Lindberg V. Intellectual Property and Open Source. Sebas-topol: O’Reilly, 2008. P. 170 — 171.
В деле Jacobsen v Katzer суд детально исследовал экономическое содержание и мотивы действий правообладателей в сфере открытого лицензирования объектов авторского права <32>. Вывод, к которому пришел суд, был благоприятным для истца, а следовательно, для всей системы открытого лицензирования в США; нарушение лицензии было истолковано как нарушение исключительных прав в полном смысле этого слова. ——————————— <32> URL: http://www. cafc. uscourts. gov/opinions/08-1001.pdf. Суд, в частности, отметил следующее: «Традиционно обладатели авторского права продают защищенный авторским правом материал за деньги. Однако отсутствие перехода денежных средств из рук в руки в сфере открытого лицензирования не означает, что нет никакого экономического встречного предоставления. Имеются существенные выгоды, в том числе экономические выгоды, отличающиеся от традиционного периодического вознаграждения (роялти), для создания и распространения защищенных авторским правом работ по открытым лицензиям. Например, программист может создать рыночную нишу для своей программы, распространяя определенные ее компоненты бесплатно. Подобным образом программист либо компания могут улучшить свою национальную или международную репутацию, развивая проекты в рамках открытого кода. Улучшения продукта могут прийти быстро и бесплатно от какого-либо эксперта, который даже неизвестен правообладателю… [Суд в другом деле] признал, что экономические мотивы присутствуют в открытых лицензиях, даже если прибыль не возникает в ближайшей перспективе».
Заключение
Открытое лицензирование программ основывается на идеях, которые остаются в целом чуждыми действующему законодательству, ориентированному на строгую защиту интеллектуальных прав. Поэтому неудивительно, что открытые программы встречаются с рядом трудностей и проблем правового характера. Но следует учесть, что открытое ПО продолжает доказывать свою нужность и актуальность в определенных областях экономики. Юристу, работающему с открытым ПО в России, следует учитывать сложность этого юридического механизма, а также отсутствие соответствующих судебных решений. Знание практики и тенденций развития открытого ПО в других странах представляется необходимым для успешной работы в этой области, для правильного применения открытых лицензий на программы в российском правовом поле. Представляется, что основные трудности связаны, во-первых, с многообразием и различиями между лицензиями на открытые программы, что создает проблему несовместимости лицензий, во-вторых, с неэффективностью определенной лицензии, которая может либо не устранить всех рисков для свобод пользователя (т. е. остаться в какой-то мере декларацией) либо противоречить законодательству, что ведет к недействительности положений лицензии.
