diff options
author | Lev Lamberov <dogsleg@debian.org> | 2024-02-23 13:09:36 +0500 |
---|---|---|
committer | Lev Lamberov <dogsleg@debian.org> | 2024-02-23 13:09:36 +0500 |
commit | 9400081a5b20a1c3e6c7dec46ede1dd43794afe3 (patch) | |
tree | 139e9d941b0f522259eebaebe1d407562f708210 /russian/intro | |
parent | d8d43d9933f8918180237cbd78942b7b6fd9862b (diff) |
(Russian) Remove obsolete translations
Diffstat (limited to 'russian/intro')
-rw-r--r-- | russian/intro/license_disc.wml | 125 |
1 files changed, 0 insertions, 125 deletions
diff --git a/russian/intro/license_disc.wml b/russian/intro/license_disc.wml deleted file mode 100644 index ad48959def1..00000000000 --- a/russian/intro/license_disc.wml +++ /dev/null @@ -1,125 +0,0 @@ -#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> Такую лицензию часто предпочитают компании, - желающие поместить во всеобщем доступе исполняемые файлы (возможно, - бесплатно), но не публиковать исходный код. Хороший пример — - компания, желающая выпустить драйвер видеокарты. Сторонники - свободного ПО хотят, чтобы в любом случае компания публиковала - спецификацию аппаратного обеспечения. Если можно считать показателем - разработку драйверов для XFree86, то лучшие драйвер — - это драйверы с доступным исходным кодом. Выпуская проприетарные - драйверы, компании только ухудшают качество своей продукции. - Они могут также снизить стоимость разработки, позволяя другим - разрабатывать драйверы для их устройств. - <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>Утверждается, что ПО находится в общественном достоянии, но при этом добавляются - ограничения (такие как запрет на продажу для извлечения прибыли). Либо что-то - находится в общественном достоянии, либо нет — третьего не дано. - Такие лицензии ничтожны, и вероятно, дополнительные условия судом признаны не будут. -</UL> |