Чтение онлайн

ЖАНРЫ

Искусство программирования для Unix

Реймонд Эрик Стивен

Шрифт:

OSD — легальное определение сертификационного знака "OSI-сертифицированного открытого исходного кода" (OSI Certified Open Source), а также лучшее из когда-либо созданных определений "свободного программного обеспечения". Все стандартные лицензии (MIT, BSD, Artistic, GPL/LGPL и MPL) соответствуют данному определению (хотя некоторые, такие как GPL, имеют другие ограничения, в условиях которых следует разобраться, прежде чем принимать их).

Необходимо отметить, что лицензии, позволяющие только некоммерческое использование, не квалифицируются как лицензии открытого исходного кода, даже если они базируются на GPL или любой другой стандартной

лицензии. Такие лицензии дискриминируют определенные занятия, личности и группы, а такая практика недвусмысленно запрещается статьей 5 OSD.

Статья 5 данного документа была написана после нескольких лет болезненных экспериментов. Лицензии на некоммерческое использование столкнулись с проблемой отсутствия четко сформулированного правового теста для определения того, какой вид воспроизведения квалифицируется как "коммерческий". Безусловно, так квалифицируется продажа программы как продукта. А если программа распространяется с нулевой номинальной ценой совместно с другой программой или данными, а цена "ложится грузом" на всю коллекцию? Что изменится, если данная программа существенна для работы всей коллекции?

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

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

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

16.7.2. Стандартные лицензии на открытый исходный код

Ниже представлены стандартные условия лицензий в проектах с открытым исходным кодом, с которыми читателю, вероятно, придется столкнуться.

MIT <http://www.opensource.org/licenses/mit-license.html>

Лицензия MIT или Консорциума X (MIT X Consortium License— подобна лицензии BSD, но без рекламных требований).

BSD <http://www.openeource.org/licenses/bsd-license.html>

Авторское право членов правления Калифорнийского университета в Беркли (используется для BSD-кода).

Artistic License (Артистическая лицензия) <http://www.opensource.org/licenses/artistic-license.html>

Те же условия, что и в Артистической

лицензии Perl (Perl Artistic License).

GPL <http://www.gnu.org/copyleft.html>

Общедоступная лицензия GNU (GNU General Public License).

LGPL <http://www.gnu.org/copyleft.html>

"Library" (Библиотечная) или "Lesser" (Облегченная) GPL-лицензия.

MPL <http://www.opensource.org/licenses/MPL-1.1.html>

Общественная лицензия Mozilla (Mozilla Public License).

Данные лицензии более подробно (с точки зрения разработчика) обсуждаются в главе 19. В данной главе достаточно подчеркнуть, что единственное важное отличие между ними заключается в том, что лицензии могут быть переходящими и непереходящими. Лицензия является переходящей (infectious) в случае, если она требует, чтобы любая производная работа лицензионной программы также попадала под условия данной лицензии.

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

GPL является одновременно самой распространенной и самой спорной переходящей лицензией. В ней есть статья 2(b), которая требует, чтобы любая производная работа GPL-программы сама была лицензирована на условиях GPL, что вызывает разногласия. (К некоторым разногласиям привела статья 3(b), требующая, чтобы обладатели лицензий предоставляли по требованию исходный код на физических носителях, однако взрывной рост Internet сделал публикацию архивов исходного кода, как того требует пункт 3(a) лицензии, настолько дешевой, что никто более не заботится о требованиях опубликования.)

Никто не может точно сказать, что подразумевается под словами "содержит или является производной из..." в статье 2(b), или какие виды использования стоят за формулировкой "простое агрегирование" несколькими параграфами ниже. Спорные вопросы касаются компоновки библиотек и включения GPL-лицензированных файлов заголовков. Часть проблемы состоит в том, что законы США, касающиеся авторского права, не определяют понятия производной; эта задача оставлена судам для создания определений прецедентного права, а компьютерные программы являются той областью, в которой данный процесс начался совсем недавно.

С одной стороны, "простое агрегирование" определенно делает безопасным поставку GPL-программы на одном носителе с разработанным коммерческим кодом при условии, что они не связаны друг с другом или не вызывают друг друга. Они даже могут быть инструментами, оперирующими с одинаковыми файловыми форматами или дисковыми структурами; данная ситуация, согласно закону об авторском праве, не сделала бы одну программу производной от другой.

С другой стороны, внедрение GPL-кода в разрабатываемый коммерческий код или связывание объектного GPL-кода с коммерческим определенно делает последний производным продуктом и требует его лицензирования на условиях GPL.

Поделиться с друзьями: