Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Закон и ПО с открытым исходным кодом

Шон Дохерти

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

Помните, как в 60-е годы прошлого века все неустанно твердили о необходимости обеспечить “свободу информации”? А вы знаете, как звучит этот лозунг сегодня? “Свободу программному обеспечению!” Но ни в Конституции, ни в Кодексе федеральных законов США вы не найдете ничего подобного. Тем не менее сторонники этой концепции готовы отстаивать ее, что называется, с пеной у рта. Однако “свободного” (читай — бесплатного) программного обеспечения, как и бесплатного угощения (free lunch), в реальной жизни нет и быть не может. Чтобы разрабатывать ПО, нужны инструментальные средства и время, а чтобы заниматься его маркетингом и распространением — людские и материальные ресурсы. Многие полагают, что должны иметь полную свободу действий при копировании, модификации и распространении ПО. Однако с приобретением бесплатно распространяемого ПО (freeware), условно-бесплатного ПО (shareware) или фирменного ПО (proprietary software) вы не получаете такой свободы — и все потому, что исходный код не прилагается к таким продуктам. Зато он прилагается к ПО с открытым исходным кодом (open-source software).

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

Права разработчиков и владельцев ПО защищены законом об авторском праве США (http:// www.loc.gov/copyright/title17/), а для контроля за их передачей служат лицензии. ПО защищается согласно этому закону, т. е. сразу же после его первоначального создания и записи на носители информации оно по праву принадлежит автору, независимо от того, каким образом авторство сохраняется за ним — посредством помещения на носитель охранного знака или путем регистрации его в Управлении охраны авторских прав США (U.S. Copyright Office). Закон об авторском праве защищает и охраняет права производителей ПО на его копирование, распространение и создание производных версий. Эти права и могут передаваться другому лицу или лицам путем лицензирования.

Будучи заинтересованными в максимизации прибыли на инвестируемый капитал, производители фирменного ПО запрещают модификацию своих продуктов, лимитируют число копий ПО, которые может сделать пользователь, и ограничивают их распространение. Производители ПО с открытым исходным кодом более щедры и позволяют предприятиям и организациям не только копировать свое детище, но и модифицировать его, а затем распространять на определенных условиях, оговоренных в лицензии. Лицензии, с одной стороны, устанавливают существенные различия между программными продуктами с открытым исходным кодом, а с другой — разделяют сообщество корпоративных пользователей на две группы — на тех, кто поощряет разработку ПО с открытым исходным кодом, и на тех, кто не поощряет ее.

Лицензия или кража?

Степень свободы, предоставляемой корпоративным пользователям ПО с открытым исходным кодом, зависит от целей, которые преследуют производители в отношении его распространения. Те из них, кто желает распространять свое ПО как можно шире, смягчают лицензионные ограничения и разрешают пользователям копировать, модифицировать и даже распространять модифицированные версии с минимальными ограничениями. Так, например, когда компания AT&T перестала поставлять операционную систему Unix с открытым исходным кодом в некоторые академические институты бесплатно, программистам Университета Беркли (шт. Калифорния) пришлось разработать ОС BSD (Berkeley Software Distribution). Они намеревались создать новый клон Unix и распространить его повсеместно. Вот почему открытый исходный код BSD сопровождается лицензией на право пользователей модифицировать его и распространять модифицированную версию ОС как с открытым исходным кодом, так и без него.

Либерализм лицензии BSD способствовал достижению поставленной цели — распространить эту ОС как можно шире. Сообщество программистов модифицировало исходный код этой ОС и вернуло его в виде таких ее версий, как FreeBSD, OpenBSD и NetBSD. Коммерческие интересы компаний тоже способствовали разработке новых версий BSD. С точки зрения предприятий, эта ОС обладает множеством достоинств. Первое время компания Sun Microsystems распространяла ОС BSD бесплатно, но позднее перевела ее в разряд фирменных. Код BSD можно найти также в операционных системах Microsoft Windows NT и Apple MacOS X.

В прилагаемой в настоящее время к BSD лицензии требуется лишь, чтобы вновь распространяемые версии исходного или двоичного кода этой ОС содержали первоначальный список ограничений, включающий требование о сохранении оригинальных ссылок на авторские права и отказ от гарантий. Кроме того, в списке ограничений есть требование, согласно которому имя автора исходной версии без его согласия “не может быть использовано в целях поддержки и рекламирования производных версий продукта”.

Лицензия X11 на ПО X Window System с открытым исходным кодом еще проще. Как и в лицензии BSD, в ней требуется, чтобы все производные распространяемые версии X Window System содержали исходные ссылки на авторские права. Что же касается самого продукта, то владельцами авторских прав на него являются компании Compaq Computer, Hewlett-Packard, IBM, Hummingbird Communications, Silicon Graphics, Sun Microsystems и The Open Group. Любых пользователей, включая корпоративных разработчиков, устраивают лицензии, содержащие минимум ограничений.

Совсем другое дело, когда лицензии на продукты с открытым исходным кодом требуют от разработчиков сотрудничества с сообществом его сторонников. Первой такой лицензией стала Универсальная общественная лицензия (General Public License — GPL) проекта GNU. Аналогично лицензиям BSD и X11 она позволяет пользователям запускать на своих машинах, копировать и распространять оригинальный исходный код программного продукта; выдается она бесплатно. Однако, если корпоративные разработчики внесут изменения в защищенное GPL ПО, то распространять его модификации разрешается, лишь сопровождая их исходным кодом.

Следовательно, в данном случае, совместно компилируя открытый и фирменный исходные коды, разработчик вынужден “дарить” плоды своего труда сообществу. Не нужно быть юристом, чтобы понять, что владелец фирменного кода вправе расценить это как посягательство на его собственность и что лицензия GPL способствует превращению Open-Source Community в организацию, закрытую для корпоративных разработчиков. И как результат этого, некоторые производители предпочитают иметь лицензии, которые содействуют использованию ПО с открытым исходным кодом на предприятиях.

Фактором, стимулирующим этот процесс, стало образование комитета OSI (Open Source Initiative). Он ставит свою “печать одобрения” на тех лицензиях, формулировки которых соответствуют определению открытого исходного кода (Open Source Definition), и публикует в Интернет список одобренных лицензий (http://www.opensource.org/licenses).

Хотя инициатива OSI содействует свободному распространению ПО как с доступом к исходному коду, так и с доступом к откомпилированному коду, она не направлена на ущемление прав компаний в отношении фирменных программных продуктов. К лицензиям, одобренным этим комитетом, относятся лицензии BSD, GPL и X11, а также лицензии IPL (IBM Public License), MPL (Mozilla Public License), SCSL (Sun Community Source License) и APSL (Apple Public Source License).

Открытый исходный код, защищенный лицензиями IPL и MPL, допускает корпоративную разработку ПО путем отделения защищенного кода от его модификаций. Корпоративный разработчик может изменить защищенный код, включив в него фирменное ПО, и не распространять результирующий код. Рассекречивая лишь суть изменений, сделанных в защищенном коде, разработчик сохраняет закрытость фирменного кода. Лицензия SCSL предусматривает аналогичное разделение защищенного и модифицированного кодов, но требует, чтобы разработчик сохранил совместимость развернутых версий защищенного кода и выплатил полагающиеся отчисления в зависимости от используемой технологии Sun.

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

Проблемы лицензирования

Когда-то разработчикам приходилось беспокоиться только о соблюдении требований зависимости пакетов и совместимости различных программных продуктов. Сегодня их беспокоит несовместимость лицензий, защищающих различные компоненты проектов с открытым исходным кодом. Например, проект Mozilla включает в себя четыре различных лицензии. Участвуя в его разработке, нужно обращать внимание на нестыковку требований различных лицензий.

Фактически, заимствование кодов из разных проектов Open-Source может моментально обернуться правовыми проблемами. Основанный на проекте Mozilla браузер Galeon был разработан с помощью комплекта инструментальных графических средств GTK+, распространяемого по лицензии GPL. Так вот, распространение этого браузера автоматически привело к возникновению “конфликта” модулей, защищенных лицензией MPL, с модулями, защищенными лицензией GPL. Далее, фирма Transarc (подразделение компании IBM) разработала свой вариант распределенной сетевой файловой системы для ОС Linux, воспользовавшись лицензией IPL. К сожалению, несовместимость лицензий IPL и GPL не позволяет использовать эту файловую систему в паре с ядром Linux. Может быть, комитету OSI следовало сосредоточить свои усилия не на “одобрении” различных лицензионных схем, а на устранении конфликтов между ними?

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

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

Ветвление исходного кода не обязательно наносит вред рынку. Оно способствует появлению большого числа модифицированных версий программного продукта и тем самым — максимальному удовлетворению нужд каждого конкретного пользователя. Тем не менее может наступить такой момент, когда все усилия и ресурсы рынка будут направлены исключительно на поддержку многочисленных “мутантов”. Классический пример такого явления — ОС BSD.

BSD - это мощная и зрелая операционная система для предприятий. Тем не менее бесконечные ответвления от нее низвели эту ОС до продукта с ограниченной областью применения. ОС BSD компании Wind River Systems обычно используется серверами Интернет и во встраиваемых системах. А вот бесплатная ОС NetBSD ориентирована главным образом на обеспечение безопасности.

Многочисленные версии ОС BSD снижают эффективность имеющейся сети поддержки и не исключают возможность того, что от выбранной предприятием версии ответвятся новые, оставив его без помощи в случае отсутствия своих собственных Unix-программистов.

Следует отметить, что ответвления порождают не только “либеральные” лицензии, такие, как BSD. ПО с открытым исходным кодом и “более ограничительными” лицензиями, такими, как GPL, тоже может ветвиться. Могут появиться отростки и от ядра Linux, поддерживаемого командой Линуса Торвальдса, если разработчиков не удовлетворит то направление, в котором ведется его модернизация. С одной стороны, они могут написать “заплаты”, откомпилировать их с ядром и в качестве новой версии Linux распространить производный код вместе с открытым исходным кодом, защищенным лицензией GPL.

С другой стороны, разработчики могут создавать отдельные модули и использовать их как фирменные. На этот счет проектом GNU предусмотрена лицензия LGPL (Library General Public License, или иначе Lesser GPL).

Лицензия LGPL позволяет фирменному ПО “вызывать” программы, защищенные лицензией GPL. По условиям LGPL, фирменный код можно использовать вместе с кодом, защищенным лицензией GPL, но нельзя компилировать или статически связывать его с кодом GPL. Однако для поддержки вызовов на уровне интерфейса API фирменный код можно динамически связывать с кодом GPL. К сожалению, здесь приходится ограничиться достаточно расплывчатой формулировкой относительно различия между статическим и динамическим связыванием, хотя новейшие технологии порождают еще боўльшую неопределенность в этом плане. Например, архитектура CORBA связывает программные компоненты друг с другом, не компилируя их.

Лицензии на ПО с открытым исходным кодом должны учитывать такую неопределенность и разъяснить двусмысленность, возникающую при разработке и эксплуатации фирменного ПО вместе с ПО Open-Source. В противном случае корпоративные разработчики не станут рисковать, запуская совместно свои фирменные и открытые коды, что сведет на нет усилия сообщества, направленные на то, чтобы сделать открытый исходный код доминирующим компонентом инструментария разработчика.

Чем больше открытого ПО используется и модифицируется все разрастающимся сообществом, тем выше риск, связанный с возможностью нарушения чьих-либо патентных прав. Многие приверженцы открытого исходного кода предпочитают применять самые что ни на есть “драконовские” меры: вы немедленно теряете свои лицензионные права, если возбуждаете судебные дела против владельца авторских прав. Хотя против патентных “разборок” между сторонами —членами сообщества сторонников открытого исходного кода такие меры и являются достаточно эффективными, они ничего не дают в случае предъявления патентного иска стороной, не являющейся членом сообщества. И если корпорации привыкли торговать патентными правами, сидя за столом переговоров, то сообщество зачастую действует здесь наобум. Хотя патентование программ с открытым исходным кодом и привело бы к увеличению их стоимости, оно снизило бы вероятность возникновения патентных претензий с чьей-либо стороны.

Во главу угла всех лицензий на ПО с открытым исходным кодом ставится его распространение, а отнюдь не эксплуатация. Пока члены сообщества спорили о том, нужно ли определять в лицензиях права на запуск программ, технические достижения расширили возможности их эксплуатации. Например, клиент-серверная архитектура позволяет эксплуатировать код, не распространяя его. Программу можно запустить на Web-сервере с помощью интерфейса CGI. Он не является распространяемым, и его можно применять без каких бы то ни было обязательств по отношению к сообществу Open-Source.

Детализация прав на исполнение программ достаточно сложный процесс, порождающий иногда гораздо больше проблем, чем он того заслуживает. Для ПО исполнение означает “использование без распространения”. По существу, лицензия на исполнение — это соглашение между сторонами, которое зачастую реализуется путем простого щелчка мышью на кнопке “Click to Agree” (если соглашение принято). Ну а достаточно ли для формирования соглашения элементов предложения и акцепта, предоставляемых таким механизмом, покажет время. Открытым остается и вопрос о том, можно ли вообще рассматривать в суде лицензии на открытый программный код.

Является ли авторское право юридическим?

Лицензии на открытый исходный код опираются на закон об авторском праве, к которому апеллируют владельцы этих прав. Хотя сам закон и гарантирует владельцам авторских прав достаточно прочную юридическую базу, передача этих прав другим лицам посредством лицензии часто становится предметом разбирательства в судах — соответствуют ли они государственным законам о торговле, включая UCITA (Uniform Commercial Information Transactions Act).

Индивидуальные лицензии, формально согласованные заинтересованными сторонами, предполагают наличие элементов предложения и акцепта, необходимых для формирования соглашения. Однако лицензии, выпускаемые в массовом порядке для членов сообщества пользователей ПО с открытым исходным кодом, могут вступать в противоречия с государственными законами о торговле. Например, по схеме предоставления прямой лицензии GPL она передается от владельца авторского права каждому разработчику или пользователю при каждой передаче программы. Если лицензия многократно переходит от пользователя к пользователю, то элементы предложения и акцепта постепенно “размываются”, и суды могут счесть лицензию как не имеющую исковой силы.

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





  
13 '2001
СОДЕРЖАНИЕ

колонка редактора

• Спутниковая отрасль возвращается к истокам

бизнес

• Катастрофоустойчивые корпоративные информационные системы

• Hewlett-Packard всерьез обосновывается на рынке ПО

• Профессиональная сертификация - уравнение со многими неизвестными

локальные сети

• Экранирование кабелей: практичное решение защищенной передачи сигналов

• Взаимодействие ИБП и дизель-генератора

• Еще раз о совместимости ИБП с дизель-генератором

• Руководство для покупателя серверов NAS

• Linux как рабочая платформа

корпоративные сети

• Коммутаторы Web: руководство для покупателя

• Резервирование данных для мобильных и удаленных пользователей

• Тестируем 2-Гбит/с адаптеры Fibre Channell

• Закон и ПО с открытым исходным кодом

услуги сетей связи

• VoDSL. Что над чем и зачем

• Сначала сеть - потом приложения?

• MMDS: от телевещания к высокоскоростному доступу в Интернет

• Технологическое оборудование для прокладки волоконно-оптических линий связи на ЛЭП

системы учрежденческой связи

• Call-центры в России и за рубежом

• Телефонные "лего" из Москвы и Петербурга

защита данных

• Урок функциональности

новые продукты

• Знакомьтесь: ViewStation; Очередная "пятерка" Invensys Powerware Division


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх