(Слыщенков В. А., Левин А. Е.) («Журнал российского права», 2009, N 10)
НЕКОТОРЫЕ ОСОБЕННОСТИ ЛИЦЕНЗИРОВАНИЯ ОТКРЫТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В. А. СЛЫЩЕНКОВ, А. Е. ЛЕВИН
Слыщенков Владимир Александрович — старший юрист, кандидат юридических наук.
Левин Антон Евгеньевич — юрист, кандидат юридических наук, ООО «Балтийское Юридическое Бюро».
В последнее время коммерческие организации, а также органы власти проявляют интерес к вопросам и перспективам развития и распространения в России открытого и свободного программного обеспечения <1>. Понятия «открытое программное обеспечение» и «свободное программное обеспечение» имеют различный смысл <2>, но ввиду того, что с практической стороны два указанных вида программного обеспечения едва ли отличаются друг от друга, в настоящей статье рассматриваются лицензии на открытые программы, при том что под открытым программным обеспечением понимаются (если прямо не указано иное) также свободные программы. ——————————— <1> Подтверждением такого интереса в государственном секторе является подготовленная (но пока не одобренная) в Мининформсвязи РФ Концепция развития, разработки и использования свободного программного обеспечения в Российской Федерации (2008 г.). <2> Для сторонников свободного ПО важна свобода распространения ПО как таковая, рассматриваемая ими как ценность одного порядка со свободой слова, собраний или иными основополагающими правами и свободами человека. Напротив, в движении открытого ПО этот общеправовой и гуманитарный компонент отходит на второй план, уступая место соображениям практической экономической выгоды, которую можно получить от работы с открытым кодом (см. об этом: http://www. gnu. org/philosophy/; интервью Р. Столлмана в журнале CNEWS. 2008. N 4(34). С. 86 — 89; http://www. opensource. org; Слыщенков В. А., Левин А. Е. Охрана программ для ЭВМ: в поисках эффективных правовых решений // Юрист. 2008. N 8. С. 14 — 15). Об открытом и свободном программном обеспечении см. также: Кондрушенко А. Открытое программное обеспечение // Патенты и лицензии. 2006. N 7. С. 14 — 20; Кондрушенко А. Свободное и открытое программное обеспечение в контексте авторского права // Материалы первой Всероссийской научно-практической конференции «Актуальные проблемы интеллектуальной собственности», 19 — 20 октября 2006 г.: В 3 т. М., 2006. Т. 2. С. 141 — 148.
Общая характеристика открытых лицензий
Открытое программное обеспечение (программное обеспечение с открытым кодом) (далее — ПО или программное обеспечение) представляет собой не некий особенный вид программ как таковых, а особую юридическую конструкцию распространения любых программ. Иными словами, одна и та же программа для ЭВМ может быть как открытой, так и собственнической. Граница между открытым ПО, с одной стороны, и собственническим ПО — с другой, проведена именно в юридической области. Лицензирование (передача по лицензии) программ с открытым кодом направлено на передачу лицензиату (пользователю) ряда широких прав. Напротив, передача по лицензии собственнического ПО предполагает сохранение и защиту в максимальном объеме прав лицензиара (правообладателя интеллектуальных прав на программу). Организация «Инициатива открытого кода» (Open Source Initiative), занимающаяся поддержкой и популяризацией программ с открытым кодом, выработала ряд критериев, которым должна соответствовать любая открытая программа (чтобы быть признанной в качестве таковой) в части юридических возможностей и границ ее использования и распространения <3>. По сути, речь идет о требованиях к положениям лицензии на открытую программу (открытой лицензии). Такая лицензия должна предусматривать среди прочего право лицензиата на использование по назначению, на дальнейшее распространение программы без уплаты отчислений (royalties), на доступ к исходному коду, на изменение программы и распространение измененной программы; при этом лицензия на открытую программу не обязательно предоставляется бесплатно (хотя случаи бесплатного распространения открытого программного обеспечения очень распространены). Таким образом, юридическая модель открытого ПО направлена на создание некого множества общего (как в плане доступа, так и в смысле допущения изменений и свободного распространения) программного обеспечения <4>. Совсем иной подход, а именно стремление защитить правообладателя, предотвратить любое прямо не разрешенное правообладателем распространение и использование произведения, присущ действующему авторскому законодательству и составленным (и составляемым) в соответствии с ним собственническим лицензионным договорам <5>. ——————————— <3> См.: http://www. opensource. org/docs/osd; http://www. opensource. org/docs/definition. php; см. на русском языке: http://citkit. ru/articles/272/; см. также: Слыщенков В. А., Левин А. Вопросы лицензирования открытого программного обеспечения // Правовые вопросы связи. 2009. N 1. С. 7. <4> Фонд свободного программного обеспечения (Free Software Foundation) указывает, что лучшим способом сделать программу «свободной» (free) был бы переход этой программы в общественное достояние (public domain), см.: http://www. gnu. org/copyleft/copyleft. html (о переходе в общественное достояние по российскому праву см. ст. 1282 ГК РФ). Этот вариант не очень хорош тем, что любое третье лицо, немного изменив перешедшую в общественное достояние программу, может вернуть программу (с изменениями) в класс (охраняемого авторским правом) собственнического ПО, действуя уже в своих интересах (см.: http://www. gnu. org/copyleft/copyleft. html). Отметим также, что законодательство не позволяет правообладателю передавать программу в общественное достояние (в смысле ст. 1282 ГК РФ): произведение переходит в общественное достояние по истечении срока действия исключительного права (ст. 1282 ГК РФ), т. е. по истечении 70 лет после смерти автора (ст. 1281 ГК РФ); в целом так же регулируется этот вопрос в американском праве (см.: Rosen L. Open Software Licensing. Software Freedom and Intellectual Property Law. New Jersey: Prentice Hall PTR, 2005. P. 36 — 37). Разумеется, правообладатель (обычно автор программы) может «фактически» сделать произведение общим, например, разместив свою программу для ЭВМ в Интернете и позволив любому третьему лицу скачивать программу, изменять ее и проч. Хотя последствия могут быть теми же, как если бы программа перешла в общественное достояние, тем не менее здесь нет перехода в общественное достояние в юридическом смысле (ст. 1282 ГК РФ). См. также: Кондрушенко А. С. Общественное достояние и свободное программное обеспечение // Патенты и лицензии. 2007. N 9. С. 24 — 27. <5> См.: абз. 2 п. 1 ст. 1235 ГК РФ: «Лицензиат может использовать результат интеллектуальной деятельности или средство индивидуализации только в пределах тех прав и теми способами, которые предусмотрены лицензионным договором. Право использования результата интеллектуальной деятельности или средства индивидуализации, прямо не указанное в лицензионном договоре, не считается предоставленным лицензиату».
Открытые лицензии на программы для ЭВМ могут быть либо авторско-левыми (copyleft), либо простыми разрешительными <6>. Первые запрещают любые ограничения прав на программу в ходе ее дальнейшего распространения по сравнению с правами, закрепленными в лицензии, полученной от правообладателя программы. Например, если лицензиат заключает сублицензионный договор на передачу третьему лицу оригинальной программы, то такой договор не должен включать никаких дополнительных ограничений свобод пользователя (сублицензиата), которых не было в первоначальном лицензионном договоре. В большинстве случаев это означает, что сублицензия будет полностью идентична лицензии и повторит ее слово в слово <7>. ——————————— <6> См. также: Слыщенков В. А., Левин А. Е. Вопросы лицензирования открытого программного обеспечения. С. 8. <7> Отметим, что лицензия может не допускать выдачу сублицензий, предполагая при этом, что третье лицо (новый лицензиат) вступит в лицензионные отношения непосредственно с лицензиаром. Несублицензируемые, заново заключаемые с каждым новым лицензиатом лицензии распространены в американском праве (см.: Rosen L. Op. cit. P. 87 — 89). Эта конструкция возможна и по российскому праву. Речь идет не о праве на уступку лицензии (о передаче прав и обязанностей по лицензионному договору по правилам о перемене лиц в обязательстве, см. ст. 382 — 392 ГК РФ), а о юридическом механизме, в рамках которого, с одной стороны, лицензия выдается лицензиаром любому третьему лицу, заинтересованному в получении таковой, а с другой — предшествующий по времени лицензиат лицензирует такому третьему лицу свои улучшения и изменения программы на условиях, отвечающих требованиям первоначальной лицензии. В этом случае авторско-левая лицензия предполагает, что любой лицензиат получает одинаковый объем прав без всяких ограничений по сравнению с объемом прав предшествующего по времени лицензиата (который вовлек нового лицензиата в лицензионные отношения с лицензиаром).
Авторское лево может быть сильным или слабым. В общих чертах сильное авторское лево предполагает, что дополнительные ограничения недопустимы не только при дальнейшем распространении оригинальной программы, но и при распространении программы, полученной путем внесения изменений в оригинальную программу модифицированной программы. Нетрудно увидеть, что юридическая конструкция авторского лева имеет целью не допустить вывода оригинальной или модифицированной программы из класса открытого программного обеспечения, воспрепятствовать превращению программы в собственническую в интересах какого-либо третьего лица (не первоначального правообладателя). В отличие от авторско-левых простые разрешительные лицензии (иначе называемые академическими) ограничиваются предоставлением пользователю (лицензиату) традиционных свобод (прав использования, изменения, дальнейшего распространения и проч.), не требуя сохранения этих свобод при дальнейшем распространении. Такие лицензии часто применяются к программам, созданным в университетской среде, для участников которых (преподавателей и студентов) бывает гораздо существеннее просто опубликовать и популяризовать свои идеи и разработки, чем заработать на последних. Следовательно, лицензиат, получивший программу по простой разрешительной лицензии, может распространять эту же или модифицированную программу далее на иных лицензионных условиях, даже по собственнической лицензии <8>. ——————————— <8> См. о простых разрешительных лицензиях: Rosen L. Op. cit. P. 73 — 77.
Каждое заинтересованное лицо может составить свою, особую открытую лицензию — либо авторско-левую, либо простую разрешительную. Между тем многообразие лицензий создало проблему их совместимости <9>. Лицензии совместимы, если в ходе дальнейшего распространения программы одна лицензия может быть заменена на другую. Иными словами, если лицензии совместимы, то пользователь (лицензиат) какой-либо открытой программы может сублицензировать (лицензировать далее) эту программу (ее модификацию) на условиях другой лицензии, отличающейся от лицензии, по которой оригинальная программа была получена данным пользователем. Несовместимость же лицензий ведет к ограничению свободы распространения ПО, т. е. подрывает основную цель движения за открытые программы. Например, две авторско-левые лицензии несовместимы друг с другом, так как каждая из них устанавливает, что любые модификации программы могут распространяться далее на условиях только той лицензии, по которой разработчик, осуществивший модификацию, получил оригинальную программу <10>. ——————————— <9> См. также: Слыщенков В. А., Левин А. Е. Вопросы лицензирования открытого программного обеспечения. С. 7 — 9. <10> См.: http://fsfeurope. org/projects/gplv3/fisl-rms-transcript#license-compatibilit.
Предположим, что некий разработчик создал новую программу путем совмещения двух открытых программ, полученных по разным авторско-левым лицензиям. Такая новая программа рассматривается как модификация каждой из двух положенных в ее основу оригинальных программ <11>. В качестве такой модификации новая программа должна распространяться на условиях первоначальной авторско-левой лицензии, но в данном случае первоначальными являются две различные лицензии. Следовательно, новая программа не может быть передана по лицензии вообще, а если такая программа будет передана по одной из (двух первоначальных) лицензий, тогда другая лицензия будет нарушена (со всеми негативными юридическими последствиями для нарушителя, которые обычно связаны с неисполнением лицензионных договоров). Из вышесказанного видно, что авторско-левая лицензия и простая разрешительная лицензия могут быть совместимы только в одном направлении, т. е. простую разрешительную лицензию можно заменить на авторско-левую, если разрешительная лицензия не содержит никаких специальных положений, которые не могут быть учтены в данной авторско-левой лицензии, но не наоборот. А вот разрешительные лицензии являются взаимно совместимыми, опять же, если их отдельные условия прямо не противоречат друг другу <12>. ——————————— <11> Пункт 9 ч. 2 ст. 1270 ГК РФ гласит: «Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения…» <12> Подробнее об этом см.: Rosen L. Op. cit. P. 241 — 251.
Потенциальная несовместимость лицензий разделила мир открытого программного обеспечения на сообщества программистов, каждое из которых объединено вокруг какой-либо одной открытой лицензии и распространяет (как внутри сообщества, так и вовне) создаваемые программные продукты именно по данной лицензии <13>. ——————————— <13> См.: Ibid. P. 43 — 49.
Рассмотрим в общих чертах некоторые из наиболее распространенных и известных открытых лицензий. Лицензия BSD (Berkley Software Distribution). Это простая разрешительная (во всех ее версиях) лицензия, созданная в Университете Беркли (США, Калифорния), для распространения операционной системы BSD. Лицензия достаточно краткая, ограничивается положением о предоставлении лицензиату прав: «Дальнейшее распространение и использование в виде как исходного, так и машинного кода, с или без изменений, разрешается…», при этом добавляет несколько обязанностей лицензиата, отказ от гарантии качества и от ответственности лицензиара за любые убытки, которые могут возникнуть в связи с использованием лицензируемой программы. Особенностью лицензии BSD, вызвавшей большую общественную критику, было правило об упоминании Университета Беркли (как создателя исходного программного продукта) во всех рекламных материалах, выпущенных любым лицензиатом для рекламы как исходного, так и модифицированного продукта. В 1999 г. это положение было исключено из лицензии BSD. Из-за указанного рекламного положения Фонд свободного программного обеспечения считает первоначальную лицензию BSD несовместимой с лицензией GNU GPL — самой распространенной на сегодняшний день открытой лицензией <14>. ——————————— <14> См.: http://www. fsf. org/licensing/licen ses/index_html.
Лицензия MIT (Massachusetts Institute of Technology), обозначается так же, как лицензия X11. Эта простая разрешительная лицензия создана на основе лицензии BSD. Будучи весьма краткой, эта лицензия тем не менее содержит более подробное описание прав лицензиата: «Настоящим дается разрешение, бесплатно, любому лицу, получающему копию данного программного обеспечения и связанных с ним файлов документов («Программное обеспечение»), распоряжаться программным обеспечением без ограничений, включая неограниченные права использовать, копировать, изменять, совмещать, публиковать, распространять, сублицензировать и (или) продавать копии программного обеспечения, а равно разрешать лицам, которым передано программное обеспечение, делать указанное…» В этом положении обращает на себя внимание слово «бесплатно». Речь идет не о том, что за программу не может взиматься никакая плата, даже разовый платеж (сравните указание на право «продавать» далее в приведенной цитате), а о том, что не взимаются отчисления (royalties), т. е. периодическая плата, привязанная к каждому отдельному случаю распространения или использования программы лицензиатом <15>. Преимуществом лицензии MIT, по сравнению с лицензией BSD, является прямое указание на право сублицензировать. Далее в лицензии MIT говорится об отсутствии гарантии качества и об отказе от ответственности за любые убытки, связанные с использованием лицензируемой программы. В отличие от лицензии BSD лицензия MIT прямо устанавливает, что лицензиар не дает никакой гарантии ненарушения интеллектуальных прав третьих лиц («the software is provided… without warranty of… noninfringement»). В заключение отметим, что Фонд свободного программного обеспечения считает лицензию MIT совместимой с лицензией GNU GPL <16>. ——————————— <15> См.: Rosen L. Op. cit. P. 86 — 87. <16> См.: http://www. fsf. org/licensing/licenses/index_html. Напомним, что совместимость здесь не означает взаимную совместимость: лицензия GNU GPL несовместима с лицензией MIT в том смысле, что первую нельзя заменить на вторую при дальнейшем распространении (полученной по лицензии GNU GPL программы).
Лицензия MPL (Mozilla Public License) создана в конце 1990-х гг. для цели распространения популярного интернет-проводника Netscape Communicator как открытой программы, когда стало ясно, что Netscape проигрывает конкуренцию Internet Explorer <17>. Эта лицензия стала затем влиятельной типовой лицензией во многом благодаря тому, что она написана на высоком профессиональном уровне, отличается четким и подробным изложением условий лицензирования <18>. MPL относится к авторско-левым лицензиям, т. е. лицензиаты должны распространять далее полученный по MPL оригинальный код или производный от него код по той же лицензии MPL <19>. При этом авторское лево ограничено так, что эту лицензию можно отнести к слабым авторско-левым лицензиям <20>. Более конкретно сказанное означает следующее. Как было отмечено выше, лицензия устанавливает, что первоначальный программный продукт, оригинальный код (Original Code) и изменения к нему (Modifications) должны распространяться по условиям MPL (ст. 3.1). Но в статье 1.9 лицензия признает, что комбинация оригинального программного продукта и изменений так называемого охватываемого кода (Covered Code) может представлять из себя набор файлов (MPL оставляет термин «файл» без определения). В этом случае изменением является любой новый файл, который содержит часть оригинального кода или предыдущего изменения (ст. 1.9.B). Следовательно, если в состав программы, основанной в целом на ранее полученном охватываемом коде, входит файл, который ни в какой степени не включает ни оригинальный код, ни предыдущее изменение, такой файл может лицензироваться на условиях любой иной лицензии, в том числе собственнической. Эта ситуация нашла отражение в ст. 3.7 MPL, где вводится понятие «большая работа» (Larger Work), в состав которой входит как охватываемый код, так и иной код и которая представляет из себя единый программный продукт; здесь лишь охватываемый код должен лицензироваться по условиям MPL. Существенное обстоятельство состоит в том, что большая работа в целом может представлять из себя как производное произведение, так и составное произведение <21>. Получается, что большая работа как производное произведение не должна лицензироваться далее только по лицензии MPL. Именно по этой причине эту лицензию можно назвать слабой авторско-левой лицензией <22>. ——————————— <17> См.: Rosen L. Op. cit. P. 141. <18> Ibid. P. 142. <19> Лицензия говорит о распространении кода и файлов, но не программы. Передаче «исполняемой версии» (кода) посвящена отдельная ст. 3.6 MPL. <20> См. оценку MPL на сайте Фонда свободного программного обеспечения: http://www. fsf. org/licensing/licenses/. <21> Различие между производным и составным произведениями в российском праве приведено в п. 2 ст. 1259 ГК РФ. <22> См.: Rosen L. Op. cit. P. 145 — 147.
Составители лицензии уделили существенное внимание патентным вопросам: во-первых, лицензированию патентных прав, необходимых для использования и распространения программы; во-вторых, защите от патентных исков, т. е. исков в связи с нарушением патентных прав. Подробный обзор этих вопросов — на примере лицензии MPL — содержится ниже в настоящей статье, в разделе, посвященном особенностям лицензионных условий открытых лицензий. Фонд свободного программного обеспечения рассматривает лицензию MPL как несовместимую с лицензией GNU GPL в связи с рядом правил и ограничений, содержащихся в MPL, но не присутствующих в GNU GPL <23>. Отметим, что эта несовместимость, очевидно, взаимна, т. е. охватываемый код, распространяемый по MPL, не может на каком-то этапе распространяться далее по GNU GPL: лицензию MPL нельзя в целях дальнейшего распространения программы заменить на лицензию GNU GPL, не нарушив лицензию MPL. Ввиду того что несовместимость взаимна, обратное также верно. Практически это ведет к тому, что нельзя передать заинтересованным лицам — ни по лицензии GNU GPL, ни по лицензии MPL — код, созданный разработчиком на основе двух продуктов: кода, полученного по GNU GPL, и кода, полученного по MPL. Лицензия MPL, впрочем, предусматривает изящный выход из этого неприятного положения. Статья 13 MPL допускает множественное (двойное) лицензирование: один и тот же программный продукт одновременно может лицензироваться по нескольким лицензиям, по лицензии MPL и по любым иным лицензиям <24>. Если же продукт лицензируется одновременно по MPL и GPL, лицензиат вправе распространять далее этот же или измененный им продукт по любой из двух лицензий. Фонд Mozilla в полной мере воспользовался возможностью, предоставленной ст. 13 MPL, перейдя на тройное лицензирование — одновременно по лицензиям MPL, GNU GPL, LGPL — всего кода, который выпускается в свет разработчиками этого сообщества <25>. ——————————— <23> См. оценку лицензии на сайте Фонда: http://www. fsf. org/licensing/licenses/. <24> О множественном (двойном) лицензировании в контексте совместимости открытых лицензий см.: Слыщенков В. А., Левин А. Е. Вопросы лицензирования открытого программного обеспечения. С. 8. <25> См.: http://www-archive. mozilla. org/MPL/relicensing-faq. html.
Лицензия Apache, версия 2.0. Эта выпущенная в 2004 г. лицензия заменила предыдущую версию лицензии Apache 1.1 (2000 г.). Будучи более подробной и разработанной, чем ее предшественница, эта версия лицензии содержит все уже известные нам положения, обычные для открытых лицензий. Речь идет о передаче лицензиату широких авторских прав, передаче необходимых патентных прав, защите от патентных исков, отказе от ответственности, от гарантии качества и от гарантии ненарушения прав третьих лиц. Особенностью этой лицензии является специальное упоминание в ст. 6 о том, что лицензия не управомочивает на использование товарного знака лицензиара. Не вполне ясно, относится ли лицензия Apache к авторско-левым или простым разрешительным. Статья 4 (a) предусматривает: при воспроизведении и дальнейшем распространении работы (т. е. оригинальной программы) и производной работы «вы должны вручить любым получателям Работы и Производной работы копию настоящей Лицензии». На основании приведенного положения можно сделать вывод, что лицензия является авторско-левой, т. е. дальнейшее распространение как оригинальной программы, так и ее модификаций должно подчиняться условиям лицензии Apache. Иначе зачем нужно вручать каждому получателю программного продукта копию этой лицензии? Все же общее понимание этого вопроса в сообществе программистов, видимо, совсем иное. В разделе «Часто задаваемые вопросы» на сайте Фонда Apache прямо сказано, что производные произведения можно распространять по любой лицензии, не только лицензии Apache <26>. Равным образом Фонд свободного программного обеспечения характеризует эту лицензию как простую разрешительную <27>. Следует отметить, что предыдущая версия лицензии Apache была, безусловно, простой разрешительной. Приведенная несообразность и неясность текста лицензии Apache служит, с нашей точки зрения, хорошей иллюстрацией до сих пор встречающихся в открытых лицензиях путаницы и неточности юридических выражений <28>. В конце концов только суд и устойчивая юридическая практика (даже не толкование авторов лицензии в виде ответов на часто задаваемые вопросы, хотя такое толкование может быть принято во внимание судом), способны окончательно разъяснить этот и другие подобные туманные моменты. ——————————— <26> См.: http://www. apache. org/foundation/licence5FAQ. html#Distribute5changes. <27> См.: http://www. fsf. org/licensing/licenses/. <28> Некоторые открытые лицензии написаны программистами без участия юристов или с поверхностным содействием последних. Мы не относим это прямо к лицензии Apache, которая имеет высокий уровень: в каждой лицензии, независимо от объема усилий, которые профессионалы приложили для ее разработки, могут встретиться неточности и ошибки. Тем не менее сказанное остается верным как характеристика открытого лицензирования в целом. Л. Роузен (Op. cit. P. 98) ярко высказывается по этому поводу: «Те же самые программисты, которые негодуют, когда юрист пытается создать высококачественное программное обеспечение, не испытывают никаких сомнений, когда намереваются написать свои собственные открытые лицензии. Их цель, как оказывается, состоит в том, чтобы произвести нечто, что выглядит как лицензия, чтобы оформить свободу программного обеспечения на разумных условиях, а затем ждать, пока сообщество примет эту лицензию и будет распространять программное обеспечение по ее условиям. Этот подход иногда работает. Некоторые члены сообщества открытого кода больше озабочены провозглашением философских лозунгов, распространением свободного программного обеспечения по миру и предоставляют самой лицензии когда-нибудь в будущем позаботиться об исполнении ее собственных условий. Указанное может быть похвальной целью, но с точки зрения юриста это по-любительски и рискованно».
Помимо типовой лицензии, которая обсуждалась выше, Фонд программного обеспечения Apache использует лицензионное соглашение вкладчика (Contributor License Agreement) <29>. Это соглашение предназначено для подписания разработчиками — частными лицами или компаниями, создающими программы в рамках какого-либо из проектов Фонда. Разработчик (вкладчик) предоставляет Фонду неисключительную и безотзывную, бесплатную и действующую по всему миру, не ограниченную по времени лицензию на использование и распространение вклада (Contribution) этого разработчика. В результате Фонд становится полномочным распорядителем всего программного обеспечения, составляющего проекты Apache. Тем самым достигается большая степень определенности юридического положения Фонда как лицензиара в отношениях с третьими лицами. Кроме того, указанный юридический механизм позволяет Фонду легко, без необходимости получения согласия автора вклада, перелицензировать программное обеспечение, распространяемое Фондом, т. е. переходить на другую лицензию, на двойное или на множественное лицензирование. ——————————— <29> См.: http://www. apache. org/licenses/icla. txt; http://www. apache. org/licenses/clacorporate. txt.
Лицензия GNU GPL или GPL (GNU General Public License) является наиболее известной и популярной на сегодняшний день открытой лицензией. Новая, третья версия лицензии была выпущена Фондом свободного программного обеспечения 29 июня 2007 г. Новая версия была разработана, в частности, с целью противостоять недавно появившимся угрозам для свободы ПО: патенты на программное обеспечение, тивоизация, цифровое управление правами <30>. ——————————— <30> Подробнее об этом см.: Слыщенков В. А., Левин А. Е. Вопросы лицензирования открытого программного обеспечения. С. 9 — 10.
Эту лицензию отличает трепетное отношение к принципам свободного программного обеспечения — иного, наверное, нельзя было бы ожидать от авторов лицензии, в числе которых находится и Р. Столлман, основатель движения свободного ПО. GPL открывается преамбулой, которая говорит о целях лицензии и ее основных положениях: «Лицензия GNU General Public License направлена на то, чтобы гарантировать вашу свободу распространять и менять все версии программы, — ради того, чтобы обеспечить, что данная программа останется свободной для всех ее пользователей» <31>. ——————————— <31> См.: http://www. fsf. org/licensing/licenses/gpl. html.
GNU GPL является сильной авторско-левой лицензией (ст. 5)
Интересный момент, свидетельствующий о крайне отрицательном отношении составителей к любым формам ограничения свободы ПО, связан с правилом «свобода или смерть» (liberty or death clause) <32>. Статья 12 гласит: «Если на вас наложены ограничения (по решению ли суда, по соглашению или иным образом), которые противоречат условиям настоящей Лицензии, это не освобождает вас от следования условиям настоящей Лицензии. Если вы не можете передавать охватываемую работу (covered work) так, чтобы одновременно соблюсти ваши обязательства по настоящей Лицензии и любые иные распространяющиеся на вас обязательства, то, следовательно, вы не можете передавать ее вообще. Например, если вы соглашаетесь с условиями, которые обязывают вас собирать отчисления (royalty) с тех лиц, которым вы передаете Программу, тогда единственный способ одновременно соблюсти как такие условия, так и настоящую Лицензию — это полностью воздержаться от передачи Программы». Эта норма лицензии направлена на то, чтобы ПО всегда оставалось «незапятнанным» с точки зрения свобод его использования и распространения. Так, согласно приведенному примеру, передача программы не должна быть обусловлена обязанностью по выплате отчислений по патентной лицензии: один из принципов свободного и открытого ПО — право лицензиата на дальнейшее распространение программы без уплаты каких бы то ни было отчислений <33>. ——————————— <32> См.: http://www. fsfe. org/projects/gplv3/fisl-rms-transcript. en. html#liberty-or-death. <33> Л. Роузен (Op. cit. P. 134 — 136) считает ст. 12 GPL максималистской, соответственно, неуместной в общем контексте открытого лицензирования. По его мнению, здесь не учитывается различие между прямым запретом (например, наложенным судом) распространять открытую программу (так как она нарушает патент), с одной стороны, и обязанностью выплачивать определенную денежную сумму (отчисления) при распространении — с другой. Если владелец патента потребовал выплаты отчислений, все же нарушение соответствующего при нципа открытого ПО будет иметь место только в том случае, если сумма отчислений будет переложена на получателей программы, вынужденных выплачивать соответствующую сумму. Напротив, если распространитель будет делать лицензионные отчисления владельцу патента за свой счет, тогда нет оснований говорить о превращении данной программы в несвободную. В этом рассуждении Л. Роузена, как представляется, не учтено, что патентные отчисления — это не только экономические потери, но также ограничение декларируемого (в принципах открытого ПО) безусловного права на распространение открытой программы. Статья 12 лицензии GPL защищает именно это право, а не столько экономический интерес не терять деньги по причине уплаты отчислений.
Любопытной чертой лицензии является недопущение сублицензий (последний абз. ст. 2). Это связано с тем, что любой последующий лицензиат получает лицензию непосредственно от первоначального лицензиара (первый абз. ст. 10) <34>. ——————————— <34> Этот юридический механизм обсуждался выше в настоящей статье.
Итак, рассмотрев в основных чертах несколько наиболее известных лицензий, перейдем к более подробному анализу специфических лицензионных условий, которые присущи открытым лицензиям.
Особенности условий открытой лицензии
Специфика лицензий на открытое программное обеспечение определяется целью системы открытого лицензирования как таковой, а именно созданием множества общего ПО. Эта цель вынуждает включать в открытые лицензии ряд особенных положений, которые делают открытые лицензии непохожими на собственнические лицензии, и мы сейчас переходим к их рассмотрению. Открытые программы доступны для изменений, дальнейшего распространения, предоставляются без обязанности выплаты отчислений, более того, обычно (но не всегда) распространяются совершенно бесплатно, т. е. без выплаты даже платежа за копию программы. Разработчик открытой программы желает познакомить сообщество со своим произведением, лежащей в его основе оригинальной идеей; помимо этого, разработчик рассчитывает, что некоторые программисты по всему миру, которые каким-либо образом получили доступ к его программе, выпустят улучшения и изменения. Таким образом, общими усилиями с распределением затрат между многими вовлеченными разработчиками будет получена законченная и качественно работающая программа. С экономической, коммерческой точки зрения именно на отмеченном моменте, как представляется, основывается система открытого лицензирования ПО <35>. ——————————— <35> См.: Lindberg V. Intellectual Property and Open Source. Sebastopol: O’Reilly, 2008. P. 170 — 171. Кроме того, отметим, что получение прибыли в сфере открытого ПО связано со следующими тремя видами деятельности: разработка программ для конкретного заказчика, которые максимально полно соответствуют его потребностям; платная техническая поддержка и доработка; обучение и консультирование специалистов заказчика. Конкурентное преимущество фирм-разработчиков открытого ПО состоит в том, что при выполнении заказов они могут опираться на значительное количество уже существующих открытых программ.
Итак, помимо (а) указания на обширные права лицензиата, открытая лицензия может среди прочего содержать: (б) отказ от предоставления гарантий, от ответственности за убытки, (в) регулирование патентных вопросов, (г) юридическую конструкцию авторского лева, (д) положения о совместимости данной лицензии с другими лицензиями, (е) регулирование авторского права на текст открытой лицензии, (ж) положения о применимом праве и компетентном суде. Права лицензиата. Именно объем прав лицензиата является решающим моментом, позволяющим отнести лицензию к классу открытых лицензий. Фонд свободного программного обеспечения и Инициатива открытого кода имеют в общем одинаковое понимание объема прав лицензиатов, хотя и используют разные формулировки для определения свободного и открытого ПО <36>. С юридической точки зрения эти определения не являются достаточно ясными, и некоторые авторы предлагают свой собственный набор принципов <37>. Общее понимание открытого (свободного) ПО в достаточной мере устоялось и определилось. Однако в любом случае права (и обязанности) сторон окончательно устанавливает лишь та открытая лицензия, которая использована в данном конкретном случае. Различные открытые лицензии предусматривают разные права и обязанности. ——————————— <36> См.: http://www. fsf. org/licensing/essays/free-sw. html; http://www. opensource. org/docs/osd. <37> См.: Rosen L. Op. cit. P. 1 — 11.
Фонд свободного программного обеспечения и Инициатива открытого кода регулярно обновляют собственные перечни лицензий, которые эти организации считают свободными и открытыми, соответственно <38>. Лицензия, не упомянутая в этих перечнях, даже если она названа открытой или свободной (или имеет иное привлекательное наименование), вполне может не соответствовать принципам открытого ПО. Соответственно, лицензиат по такой лицензии не получает всех тех прав, на которые он мог бы рассчитывать при работе по открытой лицензии. ——————————— <38> См.: http://www. fsf. org/licensing/licenses/; http://www. opensource. org/licenses.
С этой точки зрения важно отграничить открытое ПО от других моделей лицензирования. Речь идет не столько о собственнических лицензиях (так как в каждом конкретном случае, видимо, достаточно легко понять, относится ли данная лицензия к собственническим), сколько о юридических моделях, находящихся где-либо между крайними вариантами открытого ПО, с одной стороны, и собственнического ПО — с другой. Следует отметить такие модели, как «распространяемый исходный код» (shared source) и «общественный исходный код» (public source). Первая из указанных конструкций поддерживается Майкрософтом; ее назначение состоит в том, чтобы предоставить доступ к некоторому исходному коду для цели его изучения (но не копирования), что, в свою очередь, должно помочь в разработке программного обеспечения, способного взаимодействовать с программами Майкрософт. Вторая модель идет несколько дальше, не только открывая исходный код, но также допуская копирование, создание и распространение производных программ. В этой модели осуществление прав лицензиата ограничено некоммерческими целями; коммерческое же использование исходного кода или лицензируемой программы либо запрещено, либо обусловлено уплатой отчислений. Таким образом, ни та ни другая модель не относятся к открытому лицензированию <39>. ——————————— <39> Подробнее об этом см.: Rosen L. Op. cit. P. 255 — 261.
Гарантии и убытки. Открытые лицензии обычно включают положения об отказе лицензиара от предоставления гарантий и об отказе от ответственности за убытки. Отметим, что отказ от гарантии качества программы может дополняться отказом от гарантии ненарушения интеллектуальных прав третьих лиц. Лицензия EPL (Eclipse Public License) содержит, с нашей точки зрения, хорошие примеры обоих отказов <40>. Отказ от гарантий формулируется следующим образом: «Если иное прямо не предусмотрено в настоящем Договоре, Программа предоставляется «как есть», без гарантий или условий любого рода, не важно, явных или подразумеваемых, включая, среди прочего, любые гарантии или условия в части прав, ненарушения прав третьих лиц, годности для перепродажи или для конкретной цели. Любой Получатель сам ответствен за определение уместности использования и распространения Программы и принимает на себя все риски, связанные с осуществлением им прав по настоящему Договору, включая, среди прочего, риски и расходы в связи с программными ошибками, соблюдением применимого права, ущербом или потерей данных, программ или оборудования, а равно невозможностью или прерыванием операций» (ст. 5). В следующей статье содержится положение об отказе от ответственности: «Если иное прямо не предусмотрено в настоящем Договоре, ни Получатель, ни Вкладчики не несут никакой ответственности за любые прямые, косвенные, случайные, специальные, штрафные, побочные убытки (включая среди прочего упущенную выгоду), каким бы образом они ни были причинены, а равно по любому основанию ответственности, либо по договору, или в рамках независящей от вины ответственности, либо в связи с правонарушением (включая по неосторожности или иначе), возникшие либо в связи с использованием или распространением Программы, или в связи с осуществлением любых прав, предоставленных по настоящему документу, даже в случае, если причинителю убытков было сообщено о возможности убытков». ——————————— <40> См.: http://www. eclipse. org/legal/eplv10.html.
Отказ от предоставления гарантий иногда обоснуется ссылкой на бесплатность открытого ПО. Так, лицензия GNU GPL, версия 2 (1991 г.), прямо говорит в ст. 11, что гарантия качества не предоставляется, так как «программа лицензируется бесплатно». Действительно, неуместно ожидать, что лицензиар бесплатно даст гарантию качества в дополнение к бесплатной программе. Между тем отказ от дачи гарантий распространен не только по той причине, что открытое ПО иногда является бесплатным. Следует отметить, что бесплатность не является целью этого подхода; случается, что открытое ПО продается. Помимо бесплатности, определенное значение имеет также то обстоятельство, что открытое ПО — это лежит в основе данной системы как таковой — создается благодаря сотрудничеству нескольких программистов, дополняющих и изменяющих программный продукт (ведь исходный код всегда доступен). Пользователь же имеет дело непосредственно лишь с одним из разработчиков или даже с посторонним лицом, от которого получает лицензию и которое становится лицензиаром в отношениях с данным пользователем. Соответственно дать гарантию в отношении программы означает для лицензиара гарантировать качество и отсутствие нарушений интеллектуальных прав произведения, созданного другим программистом, не лицензиаром <41>. Если такая гарантия выдается, то, видимо, как особая услуга, плату за которую надлежит рассчитывать отдельно даже в тех случаях, когда сама открытая программа распространяется за деньги <42>. ——————————— <41> С этой точки зрения понятно правило ст. 9 лицензии Apache (вер. 2), которое подчеркивает, что любые гарантии и дополнительная ответственность, которые могут быть приняты на себя лицензиаром, не имеют силы в отношении других разработчиков: «При вторичном распространении Работы или Производных работ вы можете предложить, и взимать за это плату, поддержку, гарантию, возмещение убытков либо иные обязательства по ответственности и/или права, совместимые с настоящей Лицензией. Однако при принятии на себя таких обязательств вы можете действовать только от вашего собственного имени и только под вашу ответственность, не от имени любого другого Вкладчика, а также лишь при условии, что вы согласны возместить убытки, защитить и обезопасить любого Вкладчика от любой ответственности такого Вкладчика либо от требований к нему, вызванных тем, что вы приняли на себя любую гарантию или дополнительную ответственность». <42> См.: ст. 4 лицензии GNU GPL (версия 3): «Вы вправе взимать цену или не взимать никакой цены за каждую копию, которую вы передаете, и вы также можете предоставлять поддержку или гарантию за плату».
Независимо от наличия или отсутствия гарантий отдельным вопросом является отказ от ответственности. Его смысл состоит в том, чтобы обезопасить лицензиара от любых требований о возмещении убытков в связи с использованием программы, которые может предъявить лицензиат либо третье лицо. Иногда — например, в лицензии EPL, как видно из цитированного выше положения, — отказ от ответственности защищает обе стороны, как лицензиара, так и лицензиата. Отметим, что, даже если предоставлена гарантия в отношении программы, но при этом сохранен отказ от ответственности, лицензиар не будет нести по гарантии ответственность в виде компенсации убытков <43>. Поскольку гарантийные требования заключаются не в денежной компенсации, а в исправлении ошибок программы и прочих подобных действиях, действие гарантии, несомненно, не затрагивается отказом от ответственности. ——————————— <43> См.: Rosen L. Op. cit. P. 204.
В определенных обстоятельствах отказ от гарантий или отказ от ответственности (или оба отказа) может быть недействительным, например в интересах защиты прав потребителей, по факту умышленного нарушения <44>, в некоторых других ситуациях <45>. ——————————— <44> См.: п. 4 ст. 401 ГК РФ: «Заключенное заранее соглашение об устранении или ограничении ответственности за умышленное нарушение обязательства ничтожно». <45> Это соображение верно и для американского права, несмотря на то что (учитывая американские корни всех популярных открытых лицензий) широкие формулировки отказов от гарантий и от ответственности были сформулированы для использования именно в американской правовой системе (см.: Rosen L. Op. cit. P. 202 — 205).
Патенты. В США и Европейском союзе, а также в России получила распространение практика патентования программных решений, т. е. изобретений или полезных моделей, работающих с помощью программ для ЭВМ <46>. Очевидно, что третье лицо, обладающее патентом на использованное в открытой программе техническое решение, может остановить свободное распространение такой программы. Открытые лицензии на ПО стремятся противостоять этой угрозе. Это достигается двумя средствами: (1) включением в лицензию положения о лицензировании удостоверенных патентами прав, (2) регулированием последствий возникновения патентных исков, т. е. исков, предъявляемых обладателем патента к нарушителю патента. Рассмотрим эти положения на примере лицензии MPL. ——————————— <46> Пункт 5 ст. 1350 ГК РФ устанавливает, что программы не являются патентоспособными «как таковые»; соответственно, если заявитель покажет, что патентная защита испрашивается для программы не «как таковой», но как компонента более широкого технического решения, патентование программы как изобретения возможно. Касательно вопроса о патентной защите программы как полезной модели отметим, что ст. 1351 ГК РФ не запрещает такое патентование (см. об этом: Ревинский О. Еще раз вокруг колеса // Компьютерра. 2003. 9 дек.; http://offline. computerra. ru/offline/2003/522/31161/index. html).
По первому вопросу ст. 2.1 (b) и ст. 2.2 (b) MPL прямо устанавливают, что лицензиар предоставляет лицензиату патентные права (patent claims), как существующие в настоящее время, так и те, которые могут возникнуть в будущем <47>, необходимые для использования предоставленного лицензиаром кода. Известно, что патентообладатель может установить любые пределы использования лицензиатом лицензируемых исключительных патентных прав <48>. Передаваемые по MPL патентные права ограничены рамками работы с кодом. По ст. 2.1 (d) для случая передачи оригинального кода патентные права не покрывают изменения, которыми лицензиат может дополнить оригинальный код <49>, а также не распространяются на создание какой-либо комбинации оригинального кода с другим ПО или аппаратными средствами. По ст. 2.2 (d) для случая передачи изменения патентные права не покрывают комбинацию изменения и другого ПО, равным образом не покрывают работу с оригинальным кодом при отсутствии данного изменения. В связи с указанными ограничениями объема лицензируемых патентных прав — эти ограничения присущи не только MPL, но также многим другим открытым лицензиям — надлежит отметить определенное несовпадение между принципами открытого (свободного) программного обеспечения и подобными ограничениями. Одним из принципов свободного программного обеспечения является свобода «улучшать программу и выпускать в свет… улучшения (и измененные версии в целом)» <50>. Открытое ПО основывается среди прочего на принципе, что «лицензия должна допускать изменения и производные произведения, а также должна разрешать распространять их на тех же условиях, на которых лицензировано исходное программное обеспечение» <51>. В этом контексте видно, что ограничение объема лицензируемых патентных прав, а именно, как это часто встречается, запрещение использовать запатентованное техническое решение в модификациях открытой программы, вступает в противоречие с декларируемой свободой разрабатывать и распространять модификации программы. Л. Роузен, в целом не оспаривая такой подход <52>, отмечает: «Свобода создавать производные произведения не является абсолютной» <53>. Свободы разработчиков и пользователей программного обеспечения, декларируемые движением открытого (свободного) программного обеспечения, ориентированы на применение в рамках авторского права, не выходят за его пределы, не действуют непосредственно в области патентного права. ——————————— <47> См. определение патентных прав (или патентных притязаний, англ.: patent claims) в ст. 1.10.1 MPL. <48> См.: ст. 1367 ГК РФ. <49> Таким образом, использование запатентованного технического решения, выраженного в оригинальном коде (соответственно, лицензированного согласно MPL), в написанной лицензиатом программе, являющейся производной от оригинального кода, будет нарушением патента (см.: Rosen L. Op. cit. P. 149 — 150). <50> См.: http://www. fsf. org/licensing/essays/free-sw. html. <51> См.: http://www. opensource. org/docs/osd. Кроме того, другой принцип (Там же) гласит, что «права, связанные с программой, применяются ко всем, кому программа передается, без необходимости подписания какой-либо дополнительной лицензии этими лицами». <52> См.: Rosen L. Op. cit. P. 153. <53> Ibid. P. 167.
По второму вопросу — защите от исков патентообладателя в связи с действительным или предполагаемым нарушением патента на программное решение (т. е. выраженное в программе для ЭВМ защищенное патентом техническое решение) — лицензия MPL предусматривает в ст. 8.2 следующее. Если лицензиат предъявит к лицензиару иск о нарушении патента, принадлежащего лицензиату, продуктом, лицензированным по данной MPL, то этот лицензиат теряет все предоставленные ему по MPL (авторские и патентные) права. Если же лицензиат предъявит иск к лицензиару в связи с нарушением лицензиаром патентных прав лицензиата в какой-либо иной области, не связанной с лицензированной по MPL программой, то прекращаются все патентные (кроме авторских) права, предоставленные лицензиату. MPL стала одной из первых лицензий, включившей положения о защите от патентных исков; эти положения оказали определенное влияние на составителей других лицензий <54>. ——————————— <54> Ibid. P. 156.
Отметим, что положение о защите от патентных исков в открытых лицензиях по существу сводится к тому, что лицензиат, предъявивший патентный иск, теряет предоставленные ему по данной лицензии права. Это положение может быть сформулировано или очень широко, или достаточно узко. Например, можно наказать лицензиата (за предъявление им патентного иска) прекращением всех прав, как авторских, так и патентных, полученных им по данной лицензии, либо, напротив, ограничиться прекращением только патентных прав. Кроме того, в силу нормы о защите от патентных исков наказание может последовать за предъявлением любого патентного иска, как относящегося к данной программе, так и относящегося к любым иным техническим решениям, либо, напротив, эта норма может предусматривать только патентные иски в отношении данной программы, допустив патентные иски по другим предметам. Авторское лево. Термин «авторское лево» представляет собой буквальный перевод шуточного английского слова «copyleft» <55>. Несмотря на легкость, несерьезность названия, обозначаемая им юридическая конструкция стала одной из самых узнаваемых характеристик открытого программного обеспечения — и это несмотря на то, что открытые лицензии не обязательно должны быть авторско-левыми. Этот юридический механизм появился в первой версии лицензии GNU GPL (1989 г.). Горячие споры между сторонниками и противниками авторского лева по поводу его целесообразности и уместности, по поводу пределов авторского лева не утихают по сей день. ——————————— <55> В англоязычной литературе и документах иногда употребляется термин «взаимность» (reciprocity), «взаимный» (reciprocal) для обозначения такой же юридической конструкции (см.: Rosen L. Ibid. P. 105 — 107).
Авторское лево — «самая значительная идея в лицензии GPL» <56> — блестящий пример появления новой, ранее неизвестной юридической конструкции, которой удалось схватить суть дела, в концентрированном виде выразить цели и интересы сторонников свободных и открытых программ. Переходя от одного пользователя или разработчика к другому, открытая (свободная) программа не должна перестать быть таковой. В дополнение к уже сказанному об авторском леве выше в настоящей статье повторим, что авторское лево требует от лицензиата не создавать каких-либо ограничений при дальнейшем распространении программного продукта, сохранять в неприкосновенности все свободы, которые были гарантированы самому лицензиату условиями авторско-левой лицензии. Авторское лево может быть сильным или слабым, причем возможны разные варианты того и другого. Сильное авторское лево обычно выражается в требовании никак не ограничивать установленные авторско-левой лицензией свободы как при дальнейшем распространении оригинального продукта, так и при распространении его изменений. В большинстве случаев практически это означает, что дальнейшее распространение оригинального или измененного программного продукта должно подчиняться условиям той же самой авторско-левой лицензии, по которой оригинальная программа была получена лицензиатом. Слабое авторское лево предполагает, что все свободы ПО обязательно сохраняются при дальнейшем распространении лицензиатом только оригинального продукта в том виде, в каком он был им получен. ——————————— <56> Rosen L. Ibid. P. 104.
Подчеркнем, что авторское лево представляет собой условие, требование именно к распространению (передаче по лицензии) программного продукта, но не к самому по себе использованию по назначению лицензиатом полученной по авторско-левой лицензии программы или к изменению этой программы. Например, производная программа не становится открытым программным обеспечением лишь в силу того факта, что она основана на полученной по авторско-левой лицензии программе. Иными словами, у разработчика такой производной программы нет никакой обязанности предоставлять заинтересованным третьим лицам производную программу (ее исходный код); производная программа может использоваться для собственных нужд разработчика, а ее исходный код — держаться в секрете. Если какое-либо третье лицо попросит разработчика передать ему эту производную программу по лицензии, то разработчик может отказаться. Однако если разработчик все же согласится, то единственная лицензия, на условиях которой производная программа может быть передана третьему лицу, — это та самая авторско-левая лицензия, по которой разработчик получил оригинальную программу, или совместимая с ней лицензия. Одним из самых сложных вопросов в сфере пределов авторского лева — подчинение условиям авторско-левой лицензии составного произведения, в состав которого включен открытый (авторско-левый) программный продукт. Составные произведения определяются следующим образом: «Произведения, представляющие собой по подбору или расположению материалов результат творческого труда» (подп. 2 п. 2 ст. 1259 ГК РФ). Примерами составного произведения являются энциклопедия, база данных, в сфере программ для ЭВМ — программные библиотеки. Обладатель исключительного права на часть составного произведения может использовать эту часть независимо от составного произведения (п. 5 ст. 1260 ГК РФ). Подобно энциклопедии, одни статьи которой могут ссылаться на другие статьи, так и части составной программы для ЭВМ — будь то программная библиотека или сложные программные комплексы (сведенные вместе для каких-либо целей операционные системы, драйверы, базы данных, приложения и проч., представленные как единый продукт) — ссылаются (link) друг на друга и взаимодействуют друг с другом ради выполнения общих задач. Составную программу следует отличать от производной программы. Производное произведение в сфере программ для ЭВМ — программа, полученная путем любых изменений, переработки оригинальной программы (п. 9 ч. 2 ст. 1270 ГК РФ); такая программа представляет собой полное единство оригинала и изменений к нему. По смыслу принципов свободного (открытого) ПО составную программу нельзя считать открытой (свободной), если хотя бы одна ее часть остается собственнической. Между тем работа с компонентами составной программы не должна нарушать условий лицензий, по которым такие компоненты были получены. Допустим, составная программа включает собственническое ПО, приобретенное автором составной программы от какого-либо третьего разработчика. В этой ситуации автор составной программы обычно не может сублицензировать такое собственническое ПО (как часть составной программы) на условиях открытой авторско-левой лицензии. Тем не менее в лицензии GPL авторское лево используется для контроля за распространением составного продукта, а не только оригинальной и производной программы <57>. Согласно толкованию составителей применение авторского лева к составному произведению зависит от того, насколько тесно взаимодействует программа, распространяемая по GNU GPL, с другими программами в составе составного произведения <58>. ——————————— <57> Лицензия определяет термин «измененная версия» (modified version) как результат копирования (кроме буквального копирования) или адаптации каким-либо образом, требующим по общему правилу разрешения со стороны правообладателя исключительных прав (см. определение термина «modify»). В этом смысле составная программа является «измененной версией» по отношению к оригинальной программе, являющейся ее компонентом, — для использования программы как части составного произведения требуется разрешение правообладателя исключительных прав на эту программу. Кроме того, из нормы посл. абз. ст. 5 GPL, как представляется, следует, что так называемая большая работа, полученная соединением «отдельных и независимых работ» с лицензированной по GNU GPL программой, должна распространяться по лицензии GPL. <58> См.: ответы в разделе «Часто задаваемые вопросы» (ответ на вопрос «Can I release a non-free program that’s designed to load a GPL-covered plug-in?» и др.) // http://www. fsf. org/licensing/licenses/gpl-faq. html. Отметим, что лицензия прямо разрешает дальнейшее распространение программы, подчиняющейся лицензии GNU GPL, на одном носителе (CD-ROM и проч.) с другим программным обеспечением, не важно, по каким лицензиям оно распространяется: по GPL, другим открытым лицензиям или по собственническим лицензиям (посл. абз. ст. 5 GPL). См. девятый принцип открытого ПО (http://www. opensource. org/docs/osd): «Лицензия не должна ограничивать другое программное обеспечение. Лицензия не должна налагать ограничения на другое программное обеспечение, которое распространяется вместе с лицензируемым программным обеспечением. Например, лицензия не должна требовать, чтобы все иные программы, распространяемые на том же носителе, относились к открытому программному обеспечению».
Применение правила об авторском леве к составному произведению и его частям ведет к невозможности распространять открытый авторско-левый продукт в одном составном произведении с другими программами, не подчиненными той же самой авторско-левой лицензии (или совместимым с ней лицензиям). Совместимость лицензий. Совместимость лицензий означает, что одну лицензию (лицензию, по которой получена программа) можно заменить на другую для цели дальнейшего распространения программы. Если этого сделать нельзя, т. е. такая замена нарушает положения лицензии, по которой была получена оригинальная программа, лицензии не являются совместимыми. Вопрос несовместимости лицензий актуален для авторско-левых лицензий: две авторско-левые лицензии обычно несовместимы друг с другом, так как каждая из них требует, чтобы оригинальный и (или) измененный продукт распространялся получателем оригинальной программы далее на условиях лицензии, по которой получатель получил оригинальную программу; также авторско-левая лицензия несовместима с простой разрешительной лицензией, т. е. авторско-левую лицензию нельзя заменить на простую разрешительную. Несовместимость лицензий препятствует свободному распространению программ. Изложение вопроса совместимости открытых лицензий ограничено кратким обзором условий открытой лицензии, направленных на преодоление проблемы. Следует отметить два вида таких условий. Во-первых, сама лицензия может прямо устанавливать, что оригинальная и (или) измененная программа может распространяться далее не только по той лицензии, на условиях которой был получен оригинальный программный продукт, но и по лицензиям, которые с ней совместимы. Этот механизм реализован, например, в ст. 4 (b)(iv) лицензии Creative Commons Attribution-ShareAlike 3.0 Unported, в ст. недавно появившейся европейской лицензии European Union Public License <59>. Во-вторых, чтобы устранить или уменьшить привлекательность перелицензирования, т. е. замены лицензии, лицензия может разрешать изменение некоторых своих положений в ходе дальнейшего распространения программы. Так, ст. 7 лицензии GPL предусматривает, что при дальнейшем распространении программного продукта, который добавлен к полученной на условиях лицензии GPL программе, в отношении такого добавления возможно иным образом сформулировать отказ от предоставления гарантий, ограничения ответственности, включить какие-либо уведомления юридического характера или ссылки на авторов и потребовать их сохранения в дальнейшем, ограничить использование имен авторов в рекламных целях, предусмотреть некоторые другие ограничения и требования. ——————————— <59> См.: http://creativecommons. org/licenses/by5sa/3.0/legalcode; http://www. osor. eu/eupl/eupl5v1.1/en/EUPL%20v.1.1%205%20Licence. pdf.
Авторское право на текст лицензии. Этот любопытный аспект открытой лицензии появился благодаря тому обстоятельству, что открытые лицензии часто используются в качестве шаблона при лицензировании третьими лицами каких-либо своих программ. Разумеется, положение об авторском праве на текст лицензии не обязательно должно содержаться в открытой лицензии, впрочем, при отсутствии этого положения действующее авторское законодательство по умолчанию защищает текст лицензии. Если такая норма включена в лицензию, в ней указывается лицо, управомоченное менять лицензию, выпускать новые версии, а также запрещается изменение лицензии другими лицами. Таким путем сохраняется идентичность данной лицензии. Приведем в качестве примера положение, содержащееся в ст. 7 лицензии EPL: «Любому лицу разрешается копировать и распространять копии настоящего Соглашения, но во избежание противоречий настоящее Соглашение защищается авторским правом и может меняться только следующим образом. Распорядитель Соглашения (the Agreement Steward) сохраняет за собой право время от времени публиковать новые версии (включая поправки) настоящего Соглашения. Никто иной кроме Распорядителя Соглашения не имеет права менять настоящее Соглашение. Фонд Eclipse является первоначальным Распорядителем Соглашения». Применимое право и компетентный суд. Своеобразие юридической модели, противоречия между принципами открытого ПО и основами авторского права в их традиционном понимании — иными словами, все особенности открытого лицензирования ПО в совокупности делают очень важным вопрос о применимом праве и подсудности. Лицензия должна регулироваться законодательством, дающим достаточный простор для формулирования и применения лицензионных условий согласно принципам открытого ПО, а споры должны рассматриваться судом, готовым защитить права и законные интересы сторон, несмотря на необычность лицензии. Некоторые лицензии прямо указывают, праву какой страны подчиняется лицензия и какой суд может рассматривать споры. Но многие лицензии не касаются вопроса о применимом праве и компетентном суде. В этом случае, если лицензионный договор заключен с иностранным гражданином или юридическим лицом, право определяется на основании коллизионных норм. Так, в соответствии с п. 19 ч. 3 ст. 1211 ГК РФ российский суд определит, что правом, регулирующим лицензионный договор, является право страны, в которой находится место жительства или основное место деятельности лицензиара. Таким образом, можно сказать, что открытое программное обеспечение использует действующее авторское право в противоречии с целями последнего, как они традиционно понимаются. Действительно, защита исключительных прав не является ценностью в системе открытого лицензирования ПО. Используя в формулировках открытых лицензий общепринятые понятия авторского права, открытое ПО выходит за пределы последнего. Возникают новые юридические конструкции (авторское лево) и новые юридические проблемы (защита от патентных исков и другие). Однако, несмотря на все своеобразие, все особенности открытого лицензирования, оно заслуживает пристального внимания и усилий юристов, направленных на создание для открытого ПО хорошо работающего правового режима в контексте национального законодательства. Целесообразно взглянуть на открытое программное обеспечение не как на чудачество, чужеродное вторжение в стройную, проверенную десятилетиями систему авторского законодательства, а как на общественное движение, высвечивающее новую сторону авторского права, по-новому раскрывающее его регулятивный потенциал. Автор программы может ограничить распространение программы, защищать ее всеми средствами, которые предусмотрены законодательством; но автор может поступить иначе — способствовать распространению программы, предоставлять любому заинтересованному лицу по лицензии все необходимые права. Авторское законодательство также уважает такой выбор. Законы об интеллектуальной собственности не должны мешать прогрессу в области программного обеспечения, созданию и распространению оригинальных программ для ЭВМ. Открытое ПО предлагает свое решение этой задачи.
