Введение
Хотя термины «свободное программное обеспечение» (free software) и «открытое программное обеспечение» (open source software) широко используются, до сих пор существуют некоторые заблуждения относительно их значения. В частности, концепция «свободы» требует более тщательного рассмотрения. Начнем с определения этих двух терминов.
Определение свободного и открытого программного обеспечения
Критерии свободного программного обеспечения
Прежде всего, «free» в контексте свободного ПО не имеет ничего общего с «бесплатностью», или, как кратко выразился основатель Фонда свободного программного обеспечения (FSF) Ричард Столлман:
Чтобы понять концепцию, вы должны думать о «free» как о «свободе слова», а не как о «бесплатном пиве».
— Ричард Столлман
Что такое свободное ПО?
Независимо от того, нужно ли платить за программное обеспечение или нет, существует четыре критерия, которые определяют свободное ПО. Ричард Столлман описывает эти критерии как «четыре существенные свободы», нумерацию которых он начинает с нуля:
- «Свобода запускать программу как угодно и для любых целей (свобода 0).»
Нельзя предписывать или ограничивать, где, как и для каких целей используется программное обеспечение. - «Свобода изучать, как работает программа, и изменять её, чтобы она выполняла ваши вычисления так, как вы пожелаете (свобода 1). Доступ к исходному коду является необходимым условием для этого.»
Каждый может изменять программу в соответствии со своими идеями и потребностями. Это, в свою очередь, предполагает, что так называемый исходный код, т.е. все файлы, из которых состоит программа, должен быть доступен в форме, читаемой программистами. И, конечно, это право распространяется как на отдельного пользователя, который хочет добавить одну функцию, так и на компании-разработчики ПО, создающие сложные системы, такие как операционные системы для смартфонов или прошивки для маршрутизаторов. - «Свобода распространять копии, чтобы вы могли помочь другим (свобода 2).»
Эта свобода явно поощряет каждого пользователя делиться программой с другими. Речь идет о максимально широком распространении и, следовательно, о максимально широком сообществе пользователей и разработчиков, которые на основе этих свобод развивают и улучшают программное обеспечение на благо всех. - «Свобода распространять копии ваших измененных версий другим (свобода 3). Поступая так, вы можете дать всему сообществу шанс получить выгоду от ваших изменений. Доступ к исходному коду является необходимым условием для этого.»
Речь идет не просто о распространении свободного ПО, а о распространении измененного свободного ПО. Любой, кто вносит изменения в свободное ПО, имеет право предоставить эти изменения другим. Если они это делают, они также обязаны делать это на свободных условиях, т.е. они не должны ограничивать исходные свободы при распространении программы, даже если они изменили или расширили её. Например, если у группы разработчиков есть иные представления о направлении развития конкретного ПО, чем у оригинальных авторов, она может отделить собственную ветку разработки (называемую форком) и продолжить её как новый проект. Но, конечно, все обязательства, связанные с этими свободами, остаются в силе.
Акцент на идее свободы также последователен, поскольку любое движение за свободу направлено против чего-то, а именно противника, который подавляет постулируемые свободы, который рассматривает программное обеспечение как собственность и хочет держать его под замком. В отличие от свободного ПО, такое программное обеспечение называется проприетарным.
Открытое ПО против Свободного ПО
Для многих «свободное ПО» и «открытое ПО» — синонимы. Часто используемая аббревиатура FOSS (Free and Open Source Software) подчеркивает эту общность. FLOSS (Free/Libre and Open Source Software) — еще один популярный термин, который недвусмысленно подчеркивает идею свободы также и для других языков, кроме английского. Однако, если рассмотреть происхождение и развитие обоих терминов, их разграничение становится оправданным.
Термин «free software» с определением описанных четырех свобод восходит к Ричарду Столлману и основанному им в 1985 году проекту GNU — почти за 10 лет до появления Linux. Название «GNU is not Unix» (GNU — это не Unix) с иронией описывает намерение: GNU начиналась как инициатива по разработке технически убедительного решения — а именно операционной системы Unix — с нуля, предоставлению его широкой публике и постоянному улучшению совместно с общественностью. Открытость исходного кода была для этого всего лишь технической и организационной необходимостью, но по своему самовосприятию движение за свободное ПО до сих пор является социальным и политическим — некоторые говорят идеологическим — движением.
С успехом Linux, возможностями сотрудничества через Интернет и тысячами проектов и компаний, возникших в этом новом программном космосе, социальный аспект все больше отходил на задний план. Открытость самого исходного кода превратилась из технического требования в определяющую характеристику: как только исходный код становился видимым, ПО считалось «открытым». Социальные мотивы уступили место более прагматичному подходу к разработке ПО.
Свободное ПО и открытое ПО работают над одним и тем же, одними и теми же методами и во всемирном сообществе отдельных лиц, проектов и компаний. Но поскольку они объединились, исходя из разных направлений — одно социальное, другое прагматично-техническое — иногда возникают конфликты. Эти конфликты возникают, когда результаты совместной работы не соответствуют изначальным целям обоих движений. Это происходит особенно тогда, когда программное обеспечение раскрывает свои исходные коды, но при этом не уважает четыре свободы свободного ПО, например, когда существуют ограничения на раскрытие, изменение или связи с другими программными компонентами.
Лицензия, под которой распространяется программное обеспечение, определяет, каким условиям подчиняется программа в отношении использования, распространения и модификации. И поскольку требования и мотивы могут быть самыми разными, в области FOSS было создано бесчисленное множество различных лицензий. Из-за гораздо более фундаментального подхода движения за свободное ПО неудивительно, что оно не признает многие лицензии с открытым исходным кодом как «свободные» и поэтому отвергает их. В обратную сторону это вряд ли возможно из-за гораздо более прагматичного подхода открытого ПО.
Давайте кратко рассмотрим на самом деле очень сложную область лицензий ниже.
Лицензии
В отличие от холодильника или автомобиля, программное обеспечение — это не физический продукт, а цифровой продукт. Таким образом, компания не может фактически передать право собственности на такой продукт путем продажи и изменения физического владения — скорее, она передает права на использование этого продукта, и пользователь соглашается с этими правами использования по договору. Какие это права использования и, что более важно, какими они не являются, записано в лицензии на программное обеспечение, и, таким образом, становится понятно, насколько важны содержащиеся в ней положения.
В то время как крупные поставщики проприетарного ПО, такие как Microsoft или SAP, имеют собственные лицензии, точно адаптированные под их продукты, сторонники свободного и открытого ПО с самого начала стремились к ясности и всеобщей применимости своих лицензий, ведь каждый пользователь должен понимать их и, при необходимости, лично использовать для собственных разработок.
Однако не следует скрывать, что этого идеала простоты трудно достичь, поскольку слишком много специфических требований и не всегда совместимых международных правовых пониманий стоят на пути. Приведем лишь один пример: немецкое и американское авторское право (copyright) принципиально различаются. Согласно немецкому законодательству, существует человек как автор, чья работа является его интеллектуальной собственностью. Хотя автор может предоставить разрешение на использование своей работы, он не может передать или отказаться от своего авторства. Последнее чуждо американскому праву. Здесь также есть автор (который, однако, также может быть компанией или учреждением), но автор обладает только имущественными правами, которые он может передать частично или полностью и, таким образом, полностью отделить автора от произведения. Международно-действительная лицензия должна интерпретироваться с учетом различного законодательства.
Последствиями являются многочисленные и иногда очень разные лицензии FOSS. Что еще хуже, разные версии лицензии или смесь лицензий (в рамках одного проекта или даже при связывании нескольких проектов) могут вызвать путаницу или даже судебные споры.
Как представители свободного ПО, так и сторонники явно экономически ориентированного движения открытого ПО создали свои собственные организации, которые сегодня в решающей степени отвечают за формулировку лицензий на ПО в соответствии с их принципами и поддерживают своих членов в их обеспечении.
Копилефт (Copyleft)
Уже упомянутый Фонд свободного программного обеспечения (FSF) сформулировал Стандартную общественную лицензию GNU (GPL) как одну из важнейших лицензий для свободного ПО, которая используется многими проектами, например, ядром Linux. Кроме того, он выпустил лицензии с настройками для конкретных случаев, такие как Стандартная общественная лицензия GNU в сокращенном варианте (LGPL), которая регулирует комбинирование свободного ПО с модификациями кода, где исходный код модификаций не обязательно должен быть раскрыт публике; Стандартная общественная лицензия GNU Affero (AGPL), которая охватывает продажу доступа к размещенному ПО; или Стандартная лицензия GNU на документацию (FDL), которая распространяет принципы свободы на документацию к ПО. Кроме того, FSF дает рекомендации «за» или «против» сторонних лицензий, а аффилированные проекты, такие как GPL-Violations.org, расследуют предполагаемые нарушения свободных лицензий.
FSF называет принцип, согласно которому свободная лицензия распространяется также на модифицированные варианты ПО, копилефтом (copyleft) — в противовес принципу ограничительного авторского права (copyright), которое он отвергает. Идея, следовательно, заключается в том, чтобы передать либеральные принципы лицензии на ПО как можно более безоговорочно на будущие варианты программы, чтобы предотвратить последующие ограничения.
Однако то, что звучит очевидно и просто, на практике приводит к значительным осложнениям, поэтому критики часто называют принцип копилефта «вирусным», поскольку он передается последующим версиям.
Из сказанного следует, например, что два программных компонента, лицензированных под разными лицензиями копилефта, могут быть несовместимы друг с другом, поскольку обе лицензии не могут быть одновременно переданы последующему продукту. Это может относиться даже к разным версиям одной и той же лицензии!
По этой причине новые лицензии или версии лицензий часто уже не применяют копилефт так строго. Уже упомянутая Стандартная общественная лицензия GNU в сокращенном варианте (LGPL) является в этом смысле уступкой, позволяющей связывать свободное ПО с «несвободными» компонентами, как это часто делается с так называемыми библиотеками. Библиотеки содержат подпрограммы или процедуры, которые, в свою очередь, используются различными другими программами. Это приводит к обычной ситуации, когда проприетарное ПО вызывает такую подпрограмму из свободной библиотеки.
Другой способ избежать конфликтов лицензий — двойное лицензирование, когда одно ПО лицензируется под разными лицензиями, например, под свободной лицензией и проприетарной лицензией. Типичный случай использования — бесплатная версия программы, которая может использоваться только при соблюдении ограничений копилефта, и альтернативное предложение получить программу под другой лицензией, которая освобождает лицензиата от определенных ограничений за определенную плату, которая может быть использована для финансирования разработки программы.
Таким образом, должно стать ясно, что к выбору лицензии для программных проектов следует подходить с большой осторожностью, поскольку от этого зависит сотрудничество с другими проектами, возможность комбинирования с другими компонентами, а также будущее развитие собственного продукта. Копилефт ставит перед разработчиками особые задачи в этом отношении.
Определение открытого ПО и разрешительные лицензии
На стороне открытого ПО именно Инициатива открытого кода (Open Source Initiative, OSI), основанная в 1998 году Эриком С. Рэймондом и Брюсом Перенсом, занимается главным образом вопросами лицензирования. Она также разработала стандартизированную процедуру проверки лицензий на ПО на соответствие своему Определению открытого ПО (Open Source Definition). Более 80 признанных лицензий с открытым исходным кодом можно в настоящее время найти на веб-сайте OSI.
Здесь они также перечисляют лицензии как «одобренные OSI», которые явно противоречат принципу копилефта, особенно группа лицензий BSD. Berkeley Software Distribution (BSD) — это вариант операционной системы Unix, первоначально разработанный в Университете Беркли, который позже дал начало свободным проектам, таким как NetBSD, FreeBSD и OpenBSD. Лицензии, лежащие в основе этих проектов, часто называют разрешительными (permissive). В отличие от лицензий копилефта, они не имеют цели устанавливать условия использования модифицированных вариантов. Скорее, максимальная свобода должна помочь программе получить как можно более широкое распространение, предоставляя редакторам программы самим решать, как поступить с правками — например, выпустить ли их также как открытые или рассматривать как закрытый исходный код и распространять коммерчески.
Лицензия BSD с 2 условиями (2-Clause BSD License), также называемая Упрощенной лицензией BSD или Лицензией FreeBSD, доказывает, насколько сокращенной может быть такая разрешительная лицензия. В дополнение к стандартизированной оговорке об ограничении ответственности, которая защищает разработчиков от претензий по ответственности, возникающих из-за ущерба, причиненного программным обеспечением, лицензия состоит только из следующих двух правил:
Распространение и использование в исходной и бинарной формах, с модификациями или без, разрешены при соблюдении следующих условий:
- При распространении исходного кода должно сохраняться вышеуказанное уведомление об авторских правах, этот список условий и следующий отказ от ответственности.
- При распространении в бинарной форме вышеуказанное уведомление об авторских правах, этот список условий и следующий отказ от ответственности должны быть воспроизведены в документации и/или других материалах
Конечно, вот продолжение перевода статьи:
Творческое достояние (Creative Commons)
Успешная концепция развития FLOSS и связанный с ней технологический прогресс привели к попыткам перенести принцип открытого исходного кода на другие, нетехнические области. Подготовка и предоставление знаний, а также творческое сотрудничество в решении сложных задач теперь рассматриваются как свидетельства расширенного, содержательного принципа открытого исходного кода.
Это привело к необходимости создания надежных основ и в этих областях, в соответствии с которыми результаты работы могут быть распространены и обработаны. Поскольку имеющиеся лицензии на программное обеспечение для этого едва ли подходили, было множество попыток преобразовать специфические требования, возникающие при научной работе с оцифрованными произведениями искусства, «в духе открытого исходного кода», в столь же удобные лицензии.
На сегодняшний день самой важной инициативой такого рода является Creative Commons (CC), которая описывает свою миссию следующим образом:
Creative Commons — это глобальная некоммерческая организация, которая способствует обмену и повторному использованию творческих работ и знаний путем предоставления бесплатных юридических инструментов.
— https://creativecommons.org/faq/#what-is-creative-commons-and-what-do-you-do
В Creative Commons фокус предоставления прав смещается от распространителя обратно к автору. Пример: в традиционном книгоиздании автор обычно передает все издательские права (печать, перевод и т.д.) издателю, который, в свою очередь, обеспечивает максимально широкое распространение произведения. Значительно изменившиеся каналы распространения через Интернет теперь позволяют автору самостоятельно осуществлять многие из этих издательских прав и самостоятельно решать, как может использоваться его работа. Creative Commons дает возможность определить это просто и юридически надежно, но Creative Commons хочет большего: авторам предлагается делать свои работы доступными в качестве вклада в общий процесс обмена и сотрудничества. В отличие от традиционного авторского права, которое предоставляет автору все права, которые он может по мере необходимости передавать другим, подход Creative Commons использует противоположный подход: автор делает свою работу доступной для сообщества, но может выбрать из набора опций те, которые необходимо учитывать при использовании работы — чем больше опций она выбирает, тем более ограничительной становится лицензия.
Итак, принцип «Choose a License» (Выберите лицензию) от CC шаг за шагом запрашивает у автора индивидуальные свойства и генерирует рекомендуемую лицензию, которую автор затем может присвоить произведению в виде текста и значка.
Для лучшего понимания приведем обзор шести возможных комбинаций и лицензий, предлагаемых CC:
- CC BY («Attribution» — «С указанием авторства»)
Свободная лицензия, которая позволяет любому редактировать и распространять произведение при условии указания автора. - CC BY-SA («Attribution-ShareAlike» — «С указанием авторства — На тех же условиях»)
Как CC BY, за исключением того, что измененное произведение может распространяться только на той же лицензии. Этот принцип напоминает копилефт, поскольку лицензия здесь также «наследуется». - CC BY-ND («Attribution-NoDerivatives» — «С указанием авторства — Без производных»)
Как CC BY, за исключением того, что произведение может передаваться только в неизмененном виде. - CC BY-NC («Attribution-NonCommercial» — «С указанием авторства — Некоммерческая»)
Произведение можно редактировать и распространять с указанием автора, но только на некоммерческих условиях. - CC BY-NC-SA («Attribution-NonCommercial-ShareAlike» — «С указанием авторства — Некоммерческая — На тех же условиях»)
Как BY-NC, за исключением того, что произведение может распространяться только на тех же условиях (т.е. лицензия, подобная копилефту). - CC BY-NC-ND («Attribution-NonCommercial-NoDerivatives» — «С указанием авторства — Некоммерческая — Без производных»)
Самая ограничительная лицензия: распространение разрешено с указанием авторства, но только без изменений и на некоммерческих условиях.
Бизнес-модели в сфере открытого ПО
Ретроспективно триумф FLOSS выглядит как низовое движение технофилов-идеалистов, которые, независимо от экономических ограничений и свободные от денежных зависимостей, ставили свою работу на службу общественности. В то же время в среде FLOSS были созданы компании, стоимость которых исчисляется миллиардами; назовем лишь одну — американскую компанию Red Hat, основанную в 1993 году с годовым доходом более 3 миллиардов долларов США (2018 год), которая была поглощена ИТ-гигантом IBM в 2018 году.
Итак, давайте взглянем на противоречие между свободным и, в основном, бесплатным распространением качественного программного обеспечения и бизнес-моделями для его создателей, потому что одно должно быть ясно: бесчисленные высококвалифицированные разработчики свободного ПО тоже должны зарабатывать деньги, и изначально полностью некоммерческая среда FLOSS должна поэтому разрабатывать устойчивые бизнес-модели, чтобы сохранить свой собственный космос.
Распространенный подход, особенно для крупных проектов на начальном этапе, — это так называемый краудфандинг (crowdfunding) , т.е. сбор денежных пожертвований через такую платформу, как Kickstarter. Взамен жертвователи получают от разработчиков заранее определенный бонус в случае успеха, т.е. если ранее определенные цели достигнуты, будь то неограниченный доступ к продукту или специальные функции.
Другой подход — двойное лицензирование: свободное ПО предлагается параллельно под более ограничительной или даже проприетарной лицензией, что, в свою очередь, гарантирует заказчику более обширные услуги (время реагирования при ошибках, обновления, версии для определенных платформ и т.д.). Один из многих примеров — ownCloud, который разрабатывается под лицензией GPL и предлагает бизнес-клиентам «Business Edition» под проприетарной лицензией.
Возьмем также ownCloud в качестве примера еще одной широко распространенной бизнес-модели FLOSS: профессиональные услуги. Многим компаниям не хватает необходимых внутренних технических знаний для надежной и, прежде всего, безопасной установки и эксплуатации сложного и критически важного программного обеспечения. Поэтому они покупают профессиональные услуги, такие как консалтинг, обслуживание или служба поддержки, непосредственно у производителя. Вопросы ответственности также играют роль в этом решении, поскольку компания передает риски эксплуатации производителю.
Если программе удается стать успешной и популярной в своей области, появляются периферийные возможности монетизации, такие как мерчандайзинг или сертификаты, которые приобретают клиенты и которые, таким образом, подтверждают его особый статус при использовании этого программного обеспечения. Обучающая платформа Moodle предлагает сертификацию тренеров, которые, например, документально подтверждают свои знания потенциальным клиентам, и это лишь один пример среди бесчисленного множества других.
Программное обеспечение как услуга (SaaS) — еще одна бизнес-модель, особенно для веб-технологий. Здесь облачный провайдер запускает такое программное обеспечение, как CRM (система управления взаимоотношениями с клиентами) или CMS (система управления контентом), на своих серверах и предоставляет своим клиентам доступ к установленному приложению. Это избавляет клиента от установки и обслуживания программного обеспечения. Взамен клиент платит за использование программного обеспечения в соответствии с различными параметрами, например, за количество пользователей. Доступность и безопасность играют важную роль как критически важные для бизнеса факторы.
И последнее, но не менее важное: особенно распространена в небольших проектах модель разработки по заказу клиентских расширений для свободного ПО. Затем обычно клиент решает, как поступить с этими расширениями, т.е. выпустит ли он также эти расширения или сохранит их в секрете как часть собственной бизнес-модели.
Одно должно было стать ясным: хотя свободное ПО обычно доступно бесплатно, в его среде было создано множество бизнес-моделей, которые постоянно модифицируются и расширяются бесчисленными фрилансерами и компаниями по всему миру в очень творческой форме, что в конечном итоге также обеспечивает дальнейшее существование всего движения FLOSS.