Решение о выборе лицензии с открытым исходным кодом может означать разные вещи для разных людей. Те, кто рассматривает проблему с точки зрения конечного пользователя, могут почувствовать, что решение не имеет значения: эквивалент коммерческой лицензии «клик-конверт», которая обычно также остается непрочитанной. Для такого типа пользователей программное обеспечение просто представляет собой более экономичный или более производительный путь для выполнения задачи или получения функциональности.
Лицензирование является более важным для разработчиков. Прелесть лицензии с открытым исходным кодом заключается в передаче авторских прав (и патентов, если они принадлежат автору) конечному пользователю и распространителю без компенсации. Так, например, веб-профессионал может бесплатно использовать приложение, использовать его в ходе коммерческой деятельности и получать от него прибыль при взаимодействии со своими клиентами.
Зачастую в ходе своей работы разработчики обнаруживают, что программное обеспечение не совсем соответствует их потребностям: ему не хватает заданных возможностей. Чтобы решить проблему, разработчики могут решить создать новую функциональность. Это воплощение лицензии с открытым исходным кодом: здесь нет никаких строк! Новое модифицированное решение может быть распространено в соответствии с исходной лицензией (или отдельно от нее, как мы вскоре увидим) в зависимости от выбора лицензии.
Результатом этого упражнения является то, что сотни новых пакетов программного обеспечения с открытым исходным кодом доступны в целом. Плохая новость заключается в том, что некоторые из этих пакетов могут подвергаться риску нарушения патентов, о которых авторы программного обеспечения, возможно, не знали.
Эта возможность, в сочетании с озабоченностью по поводу возникающих проблем интеллектуальной собственности (ИС) и ответственности, стала поводом для путаницы разработчиков, особенно с учетом того, что существует широкий список различных лицензий с открытым исходным кодом. Процесс выбора лицензии, проверки кода и запуска продукта без проблем ответственности становится более неприятным по мере расширения атмосферы открытого исходного кода.
Лицензионная головоломка
Когда разработчик рассматривает свои варианты лицензий с открытым исходным кодом, первым шагом должна стать инициатива открытого исходного кода (OSI) . Группа поддерживает определение программного обеспечения с открытым исходным кодом и сертифицирует лицензии, которые придерживаются его. Зайдите на сайт, и вы найдете описания более 50 лицензий.
В последнее время возникли вопросы о том, следует ли консолидировать некоторые лицензии, хотя некоторые, такие как академическая бесплатная лицензия, служат нишам. Эрик Рэймонд, соучредитель и почетный президент OSI, предполагает, что многие лицензии, перечисленные в списках OSI, по сути являются индивидуальными или корпоративными проектами тщеславия.
«Лишь около полудюжины широко используются», — сказал Реймонд в LinuxInsider. «Мы обдумываем способы противодействия дальнейшему распространению, но до сих пор наша политика не отклоняла лицензии, которые соответствуют OSD, даже если они дублируют друг друга. Это может скоро измениться».
Прежде чем идти дальше, давайте вернемся назад и посмотрим, как лицензия становится, ну, в общем, лицензией.
Как рождается лицензия?
Ветеринары организации Рэймонда предложили новые лицензии с открытым исходным кодом с батареей обзоров и обсуждений.
«Мы стремимся к соответствию десяти пунктам определения открытого исходного кода . У нас есть юристы и юридически подкованные не юристы, которые обсуждают лицензию на обсуждение лицензии. Правление рассматривает их рекомендации и голоса», — сказал он.
Совсем недавно Sun Microsystems предоставила Общую лицензию на разработку и распространение (CDDL), благодаря которой компания выпустила Open Solaris. Представители Sun заявили, что они решили отказаться от существующих лицензий, чтобы они могли встроить патентную защиту для пользователей новой платформы Solaris.
Раймонд, со своей стороны, не всегда верит, что есть веские аргументы в пользу выпуска новых лицензий, даже если компания большая.
«Большинство новых лицензий — это учения по созданию памятников со стороны юридических отделов, у которых слишком много времени», — сказал он. «Иногда вы получаете лицензию, которая решает основополагающие правовые вопросы по-настоящему новым или интересным способом. Но это никогда не было обычным явлением, а сейчас встречается крайне редко».
Лицензирование Lowdown
Несмотря на то, что формального публичного отчета не существует, недавние исследования по измерению использования лицензий с открытым исходным кодом были завершены независимо и показывают, что подавляющее большинство в две трети проектов с открытым исходным кодом используют GNU General Public License (GPL). За GPL следуют лицензии Limited GPL (LGPL), Berkeley Software Distribution (BSD) и Mozilla.
Достигнув многих лицензий, недавно вышедшая книга юриста Лоуренса Розена « Лицензирование открытого исходного кода» разбила таксономию лицензий, чтобы помочь классифицировать их. Это также помогает разработчикам сократить время, необходимое для исследования различных типов лицензий для их программного обеспечения.
Текущие пятьдесят с лишним лицензий, поддерживаемых OSI, делятся на четыре типа:
1. Академические лицензии
Представляя самые «бесплатные» лицензии с открытым исходным кодом, лицензии Academic не предъявляют никаких требований к пользователю лицензии — у пользователя даже нет необходимости обмениваться модификациями или распространять их. Лицензии в этой категории включают лицензии BSD, MIT и Apache.
Академические лицензии предназначены для обеспечения абсолютной свободы. Единственным отмеченным ограничением является то, что эти лицензии запрещают использовать имя оригинального лицензиара в качестве поддержки в маркетинговых усилиях. Помимо этого, эти лицензии действительно предназначены для тех, кто ищет полный контроль над программным обеспечением, его использованием, модификациями и последующими переизданиями независимо или с другим программным пакетом.
BSD, дедушка лицензирования с открытым исходным кодом, возник в Калифорнийском университете, чтобы предоставить бесплатное использование, модификацию и распространение программного обеспечения, созданного в учреждении. С тех пор он стал общедоступной лицензией, доступной для разработчиков с открытым исходным кодом.
Массачусетский технологический институт был создан Массачусетским технологическим институтом в качестве переписки лицензии BSD. Лицензия Apache отличается от BSD и MIT только тем, что в документацию или исходный код измененных произведений включено уведомление о том, что новый дистрибутив содержит программное обеспечение, созданное Apache Software Foundation.
2. Взаимные лицензии
Как и другие лицензии, Взаимные лицензии предоставляют полные права на использование программного обеспечения разработчику и конечному пользователю. Единственное отличие заключается в том, что все производные программного обеспечения должны быть выпущены под одной лицензией, а исходный код должен быть выпущен. Полученное новое программное обеспечение также должно быть бесплатным.
Цель взаимности заключается в том, чтобы обеспечить появление растущей вселенной свободного программного обеспечения, а также то, что оригинальные работы, а также модифицированные и новые усилия остаются бесплатными для пользователей. Некоторые из самых популярных программ, доступных сегодня, остаются бесплатными и доступными благодаря использованию GPL, включая Linux, MySQL, оболочку Bash, Mailman, gzip и grep.
Центральным элементом этой категории является GPL, который в последний раз обновлялся в 1991 году, хотя ожидается, что он будет обновлен в этом году оригинальными авторами Ричардом Столменом и Эбеном Могленом при участии сообщества открытого исходного кода в целом. Общественная лицензия Mozilla также находится в этой категории.
3. Стандарты Лицензии
Стандарты лицензий стремятся создать базовый стандарт программного обеспечения и документации. Модифицированные и перераспределенные источники обычно должны распространяться в виде исправлений, чтобы не изменять ядро.
Например, представьте ситуацию, в которой создается веб-приложение, позволяющее импортировать и экспортировать между различными популярными блог-приложениями. Веб-разработчик берет источник этого нового программного обеспечения и создает дополнительную функцию для миграции и преобразования определенных элементов дизайна вместе с данными. В соответствии со стандартной лицензией базовое приложение будет распространяться с плагином для включения последней новой возможности.
Цель лицензии на стандарты состоит в том, чтобы сохранить существующую кодовую базу, чтобы автор-автор мог без труда вернуться к ней и развить ее. В некоторых случаях плагины не будут затронуты. В других случаях первоначальный автор будет обновлять документацию, чтобы позволить сторонним организациям обновлять свои плагины (часто также называемые исправлениями).
4. Лицензии на контент
Наконец, лицензии на контент охватывают такие элементы помимо кода, как графика, копирование и аудио / видео. Те, кто знаком с Creative Commons , признают эту лицензию, хотя некоторые из них перечислены в OSI, включая бесплатную академическую лицензию.
Одно из предостережений в отношении лицензий Creative Commons (CC) заключается в том, что если в лицензию CC включен атрибут Share-Alike, это делает лицензию взаимной, аналогичной GPL.
Проблемы интеллектуальной собственности
При понимании процесса лицензирования важно различать авторское право, товарный знак и патенты. Все эти элементы играют роль в программном обеспечении, которое мы используем каждый день. В некоторых случаях свобода от патентного риска была включена в лицензию (как в CDDL Sun Microsystems и, в некоторой степени, в других).
Однако, как поясняет Розен в своей книге, многие из лицензий защищают пользователей от патентных требований к исходному программному обеспечению, но не всегда могут расширять эту защиту после изменения и распространения исходного кода или двоичного кода.
Тем не менее, простота остается основной привлекательностью открытого исходного кода — найдите приложение, которое удовлетворяет потребности, загрузите, установите и начните использовать или разрабатывать с ним.
Такие организации, как Sourceforge, ускоряют этот процесс. Sourceforge можно считать Creative Commons проектов программного обеспечения с открытым исходным кодом, на котором размещено более 90 000 проектов с открытым исходным кодом с более чем одним миллионом зарегистрированных пользователей. Это популярное направление, куда множество разработчиков и пользователей с открытым исходным кодом отправляются на поиски программного обеспечения. Sourceforge будет размещать проект только с использованием одной из утвержденных OSI лицензий.
Одно это не представляет угрозы. Однако соображения IP и лицензии становятся критически важными, если источник изменяется, упаковывается в другое решение и распространяется.
Именно для этой цели создается индустрия коттеджей, и такие компании, как Black Duck Software (см. Этот пост в Open Sourcery ), надеются извлечь выгоду из озабоченности разработчиков по поводу создания, использования и распространения открытого и смешанного исходного кода, предлагая обзор кода. решения. Для некоторых это может быть дорогостоящим предложением, и, по мнению Рэймонда, полное соблюдение невозможно.
«Учитывая столько защищенного авторским правом и запатентованного кода, сколько существует в мире, положительная уверенность путем обзора практически невозможна», — сказал он. «Лучшее, что вы можете сделать, — это убедиться, что в вашем коде нет чьих-то явных авторских прав, а этого недостаточно».
Юридическая экспертиза
Обзоры проводятся регулярно, в основном с целью проявления должной осмотрительности.
Рэймонд считает, что единственная стратегия, которая имеет смысл в сумасшедшей и токсичной среде, созданной современным законодательством в области ИС (особенно патентами), состоит в том, чтобы завершить как минимум предварительную проверку, чтобы иметь в виду, что проверка была проведена, а затем в основном игнорировать ваши риски. до тех пор, пока вам не предъявят иск.
«И это именно тот совет, который вам дадут патентные юристы. Вы не« хотите »знать, какие патенты вы можете нарушать заранее, — это делает его« умышленным »и утраивает ущерб», — сказал он.
«Да, это безумие», — признался он. «Это отражает фундаментальное безумие современного права ИС».
В знак признания возникающих в настоящее время проблем ИС интеллектуальная общественная лицензия GNU — один из самых распространенных вариантов — будет обновлена впервые за тринадцать лет. Пересмотр ожидается в 2005 году. Однако Рэймонд предполагает, что разработчикам не нужно откладывать выбор лицензии, чтобы дождаться новой лицензии GPL, поскольку в настоящее время она по сути является программным обеспечением.
Снижение риска
Политики, адвокаты и судьи в конечном итоге будут руководствоваться архаичным сводом законов в области ИС в 21 веке. Направление этого процесса может зависеть от понимания людьми и организациями открытого кода.
По словам Рэймонда, в то время как OSI проводит небольшую пропаганду для разработчиков политики в области открытого исходного кода и состояния интеллектуальной собственности, «наше основное внимание было сосредоточено на продаже идеи предприятиям, которые верили, что они затем продадут ее правительству. более политически ориентированные группы, с которыми мы сотрудничаем, такие как OSIA (Open Source Industry Alliance). «
В то же время, разработчикам оставлено изучать лицензии и выбирать их самостоятельно. В то время как дорогие юридические консультации могут помочь, другие могут рискнуть, выбирая лицензию, на которую можно поставить свой код.
Важно понимать влияние выбора вашей лицензии. Как вы уже видели, у каждой категории лицензий есть свои особые цели, будь то обеспечение свободы конечного пользователя, предотвращение коммерческого использования или сохранение стандартной базы кода.
Пользователи могут переключать схемы лицензирования после того, как они сделали свой выбор и распространили программное обеспечение; однако вопрос о существующем коде и лицензионных соглашениях неясен, когда дело доходит до внесения таких изменений. Эти недоказанные воды означают, что разработчикам нужно очень тщательно выбирать лицензию, с которой они могут жить в течение длительного срока.
Например, если разработчик предвидит только продажу услуг по поддержке и настройке в течение длительного периода времени, достаточно выбрать взаимную лицензию, которая может помешать продаже самого программного обеспечения. Однако, если есть вероятность того, что будущее приложение может стать частично проприетарным, в том числе с оригинальным или модифицированным открытым исходным кодом, академическая лицензия может быть лучшим путем.
Могут ли разработчики ожидать инструмент, который упростит выбор лицензии из OSI в ближайшее время?
Раймонд только сказал бы: «Пока нет. Мы работаем над этим».