#use wml::debian::template title="Сравнение лицензий программного обеспечения"
#use wml::debian::translation-check translation="a2d057aa44562ddcc643379de20b7fc2c0c7f9e4"

<P><STRONG>******Этот документ находится в стадии разработки*******</STRONG>

<P>Те, кто имел дело с открытым ПО, склонны иметь устойчивое мнение
относительно лицензий. Новички не беспокоятся о них настолько сильно,
поскольку они более заинтересованы в выполнении задачи и не понимают,
как относится длинный список условий к выбору из разных программ по
их лицензиям (сомнительно, что есть много людей, кто понимает все
нюансы лицензий, но не имеет чёткого мнения на этот счёт).

<P>В течение многих лет число лицензий увеличивалось, поскольку они
дают авторами программного обеспечения некоторый контроль за их
творениями, чего хочет большинство разработчиков. Всё ещё часто можно
найти ПО, где нет явного указания авторских прав, или содержащее
уникальную лицензию, разработанную автором. Последний случай может
быть довольно неприятен для распространителей ПО (как сетевых, так
и тех, кто делает компакт-диски), поскольку многие из этих лицензий
содержат <A HREF="#mistakes">распространённые ошибки</A>, затрудняющие
распространение программного обеспечения.

<P>Далее следует список наиболее распространённых свободных (открытых)
лицензий ПО и некоторые их достоинства и недостатки. Упомянуты только
те положения лицензии, которые связаны с обсуждаемым вопросом. Многие
положения перечислены под заголовком "ХОРОШО/ПЛОХО". Это положения,
которые могут быть как достоинствами, так и недостатками, в зависимости
от вашей точки зрения.

<UL>
<LI><A HREF="https://www.gnu.org/">Универсальная общественная лицензия GNU (GPL)</A>.
	<BR>
	<B>ОБЗОР:</B> должен быть доступен исходный код, ПО может продаваться,
	производные разработки должны распространяться на тех же условиях
	<BR>
	<B>ХОРОШО:</B> Эта лицензия стала самой используемой лицензией мира
	свободного (открытого) ПО, и на то есть причины. Она хорошо защищает
	права разработчиков ПО, а доступность исходного кода гарантирует,
	что пользователи могут не беспокоиться о том, что потеряют поддержку
	в будущем.
	<BR>
	<B>ХОРОШО/ПЛОХО:</B> ПО, выпущенное на условиях GPL не может быть
	включено в коммерческое ПО.
	Плохо ли это, зависит от вашей точки зрения. Те, кто разрабатывает
	коммерческое программное обеспечение, часто бывают разочарованы тем,
	что доступное решение не может быть использовано из-за конфликтов
	лицензий. Конечно, ничто не мешает им связаться с автором и спросить,
	не могут ли они купить версию с	другой лицензией.
	Большинство людей, выпускающих ПО на условиях GPL, не считают эти
	ограничения плохими, потому что они позволяют другим использовать и
	улучшать программное обеспечение, хотя и не дают другим людям
	делать деньги (имеются в виду большие деньги) на их тяжёлом труде
	без их разрешения.

<LI>Художественная лицензия (Artistic License)
	<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
	<BR>
	<B>ОБЗОР:</B>
	<BR>
	<B>ХОРОШО:</B>
	<BR>
	<B>ПЛОХО:</B>

<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">BSD-подобные лицензии</A>.
	<BR>
	<B>ОБЗОР:</B> Двоичные файлы и исходный код должны содержать текст
		лицензии, в рекламе должен содержаться список разработчиков,
		перечисленных в тексте лицензии
	<BR>
	<B>ХОРОШО/ПЛОХО:</B> Такую лицензию часто предпочитают компании,
	   желающие поместить во всеобщем доступе исполняемые файлы (возможно,
	   бесплатно), но не публиковать исходный код. Хороший пример&nbsp;&mdash;
	   компания, желающая выпустить драйвер видеокарты. Сторонники
	   свободного ПО хотят, чтобы в любом случае компания публиковала
	   спецификацию аппаратного обеспечения. Если можно считать показателем
	   разработку драйверов для XFree86, то лучшие драйвер&nbsp;&mdash;
	   это драйверы с доступным исходным кодом. Выпуская проприетарные
	   драйверы, компании только ухудшают качество своей продукции.
	   Они могут также снизить стоимость разработки, позволяя другим
	   разрабатывать драйверы для их устройств.
	<BR>
	<B>ХОРОШО/ПЛОХО:</B> Кто угодно может взять исходный код, модифицировать
	   его и выпустить полученный результат, не публикуя изменения. Вы
	   можете считать это как достоинством, так и недостатком.
</UL>

<HR>

<P><A NAME="mistakes">Несколько общих ошибок в самостоятельно написанных лицензиях</A>:
<UL>
<LI>Продажа ПО с целью извлечения прибыли либо не допускается, либо ограничивается.
	Это затрудняет распространение ПО на компакт-дисках. Люди часто делают
	ошибку, используя не вполне определённые термины, такие как
	'разумная цена' ('reasonable cost'). Лучше просто использовать одну
	из перечисленных выше лицензий, поскольку они достигают тех же целей,
	не прибегая к таким формулировкам.
	Например, позволяя всем распространять ПО, GPL сохраняет цены низким в результате
	работы обычных рыночных механизмов. Если кто-то продаёт компакт-диски по цене,
	значительно превышающей себестоимость, это будет продолжаться только до тех
	пор, пока на рынке не появятся конкуренты и не станут продавать их по более
	низкой цене.
	<BR>Примечание: Художественная лицензия использует термин `Reasonable copying
	fee' (`разумная плата за копирование'), но уточняет термин, пытаясь сделать
	его более определённым.
<LI>Не допускается распространение модифицированных версий ПО.
	Это не позволяет некоторым группам людей распространять ПО. Например, поскольку
	Debian распространяет скомпилированное ПО, часто необходимо изменять исходный
	код, чтобы он компилировался или чтобы привести его в соответствие с
	<A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>.
	Делая это, мы не может распространять такое ПО.
<LI>Требуется, чтобы обо всех изменениях в ПО сообщали автору. Хотя отправлять автору
	изменения/усовершенствования, чтобы они могли быть распространены более широко, и
	хорошая идея, такое требование может вызвать проблемы. Много ли людей знает, где
	они будут через пять лет?
	Просто замените это условие на 'Любые изменения в ПО следует отправлять автору'.
	Большинство людей будут это делать.
	<BR>Это предложение обычно включается в текст лицензии, чтобы предотвратить
	ответвление проектов от основной разработки. История показывает, что до тех
	пор, пока разработка исходного кода не останавливается,
	ответвления происходят только если есть другие причины, провоцирующие разделение.
<LI>Утверждается, что ПО находится в общественном достоянии, но при этом добавляются
	ограничения (такие как запрет на продажу для извлечения прибыли). Либо что-то
	находится в общественном достоянии, либо нет&nbsp;&mdash; третьего не дано.
	Такие лицензии ничтожны, и вероятно, дополнительные условия судом признаны не будут.
</UL>