path: root/talermerchantdemos/blog/articles/uk/thegnuproject.html

<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->

<!--#include virtual="/server/header.uk.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Про проект GNU - Проект GNU - Фонд вільного програмного забезпечення</title>
<meta http-equiv="Keywords" content="GNU, проект GNU, ФСПО, вільні програми, Фонд вільного програмного
забезпечення, історія" />

<!--#include virtual="/gnu/po/thegnuproject.translist" -->
<!--#include virtual="/server/banner.uk.html" -->
<h2>Проект GNU</h2>

<p>
<a href="http://www.stallman.org/"><strong>Річард Столмен</strong></a></p>

<blockquote>
<p>
Спочатку опубліковано в книзі <em>Відкриті вихідні коди</em>. Річард Столмен
<a href="/philosophy/open-source-misses-the-point.html"> ніколи не був
прихильником &ldquo;відкритого вихідного коду&rdquo;</a>, але він передав цю
статтю, щоб ідеї руху за вільне програмне забезпечення не були відсутні в
цій книзі повністю.
</p>
<p>
Чому зараз важливо, як ніколи, <a
href="/philosophy/free-software-even-more-important.html"> наполягати на
тому, щоб програми, якими ми користуємося, були вільними</a>.
</p>
</blockquote>

<h3>Перша громада обміну програмами</h3>
<p>
Коли в 1971&nbsp;році я почав працювати в Лабораторії штучного інтелекту
<abbr title="Massachusetts Institute of Technology">MIT</abbr>, я став
частиною громади обміну програмами, яка існувало протягом багатьох
років. Обмін програмами не обмежувався нашою конкретною спільнотою; він був
так само старий, як комп'ютери, подібно до того, як обмін рецептами, так
само старий, як кулінарія. Але ми займалися цим більше, ніж інші.</p>
<p>
Лабораторія ШІ (далі ЛШІ) користувалася операційною системою під назвою
<abbr title="Incompatible Timesharing System">ITS</abbr> (Несумісна система
поділу часу), яку штатні хакери (1) лабораторії спроектували і написали на
мові асемблера комп'ютера <abbr title="Programmed Data
Processor">PDP</abbr>-10 компанії Digital, одного з великих комп'ютерів тієї
епохи. Моя робота як члена спільноти, штатного хакера ЛШІ, полягала в
поліпшенні цієї системи.</p>
<p>
Ми не називали свої програми &ldquo;вільними програмами&rdquo;, тому що
такого терміну не існувало; але саме цим вони і були. Коли люди з іншого
університету або компанії хотіли перенести або скористатися програмою, ми
завжди з радістю дозволяли їм це. Якщо ви бачили, що хтось користується
незнайомій та цікавою програмою, ви завжди могли попросити поглянути на
вихідний текст, щоб його можна було прочитати, змінити або розібрати на
запчастини для нової програми.</p>
<p>
(1) Вживання слова &ldquo;хакер&rdquo; у значенні &ldquo;зломлювач
захисту&rdquo;&nbsp;&nbsp; помилка, якою ми зобов'язані засобам масової
інформації. Ми, хакери, відмовляємося визнавати це значення й продовжуємо
вживати це слово в значенні &ldquo;той, хто любить програмувати, хто отримує
задоволення від гри думки, або комбінація і того, і
іншого&rdquo;. Див.&nbsp;мою статтю <a
href="http://stallman.org/articles/on-hacking.html">
&ldquo;Про&nbsp;хакерство&rdquo;</a>.</p>

<h3>Загибель громади</h3>
<p>
Ситуація різко змінилося на початку вісімдесятих років XX&nbsp;століття,
коли компанія Digital припинила постачання обладнання для серії PDP-10. Її
архітектура, витончена і потужна для шістдесятих, не могла природним чином
розширюватися на місткіші адресні простори, які ставали досяжні у
вісімдесятих. Це означало, що майже всі програми, які складали ITS,
застаріли.</p>
<p>
Громада хакерів ЛШІ вже розвалилася незадовго до цього. У 1981&nbsp;році
відділилася компанія Symbolics, яка переманила майже всіх хакерів з ЛШІ, і
знелюдніла громада була не в змозі підтримувати себе (в книзі Стіва Леві
&ldquo;Хакери&rdquo; описані ці події, а також дана ясна картина цієї
спільноти у час її розквіту.) Коли в 1982&nbsp;році ЛШІ купила нову PDP-10,
адміністрація вирішила користуватися невільною системою поділу часу компанії
Digital замість ITS.</p>
<p>
У сучасних комп'ютерів тієї епохи, таких, як VAX або 68020, були свої власні
операційні системи, але жодна з них не була вільною: доводилося підписувати
договір про нерозголошення, щоб отримати хоча б копію виконуваних файлів.</p>
<p>
Це означало, що першим кроком у користуванні комп'ютером була обіцянка не
допомагати своєму сусідові. Співпраця у громаді була заборонена. Правило,
встановлене власниками невільних програм, стверджувало: &ldquo;Якщо ви
обмінюєтеся зі своїм сусідом, то ви&nbsp;&nbsp; пірат. Якщо вам потрібні
будь-які зміни, просіть нас внести їх&rdquo;.</p>
<p>
Думка про те, що суспільна система невільного програмного
забезпечення&nbsp;&nbsp; система, в якій кажуть, що вам не дозволено
обмінюватися програмами або змінювати їх&nbsp;&nbsp; антисоціальна, що вона
неетична, що вона просто неправильна, для деяких читачів може стати
несподіванкою. Але що ще ми могли б сказати про систему, засновану на тому,
що роз'єднує людей і користувачів робить безпорадними? Читачі, яким ця думка
здається несподіваною, можливо, прийняли громадську систему невільного
програмного забезпечення як данину часу або судили про неї у термінах,
запропонованих підприємствами, які займаються невільними програмами. Видавці
програм довго і наполегливо працювали над тим, щоб переконати людей, що на
це питання можна дивитися тільки з однієї позиції.</p>
<p>
Коли видавці програм говорять про &ldquo;здійснення&rdquo; своїх &ldquo;
прав&rdquo; або &ldquo;припинення <a
href="/philosophy/words-to-avoid.html#Piracy"> піратства</a>&rdquo;, те, що
вони <em>кажуть</em> насправді є другорядним. Справжній зміст цих заяв
полягає в невисловлених припущеннях, які вони вважають само собою
зрозумілими і які суспільство просять прийняти без перевірки. Отже, давайте
їх перевіримо.</p>
<p>
Одне з припущень полягає в тому, що у програмних компаніях є незаперечне
природне право володіти програмами і тим самим володіти владою над всіма
користувачами цих програм. (Якщо б це було природним правом, то незалежно
від того, скільки шкоди це завдає суспільству, ми не могли б заперечувати.)
Цікаво, що конституція США та юридична традиція відкидають цю точку зору;
авторське право не є природним, це штучна монополія, введена державою, яка
обмежує природне право користувачів копіювати.</p>
<p>
Інше невисловлене припущення полягає в тому, що єдине, що важливо в
програмі&nbsp;&mdash; це те, яку роботу вона дозволяє вам виконувати; що
нас, користувачів комп'ютерів, не повинно турбувати, якого роду суспільство
нам дозволено мати.</p>
<p>
Третє припущення полягає в тому, що у нас не було би програм, якими можна
було б користуватися (чи ніколи не з'явилося б програми для виконання тієї
чи іншої конкретної задачі), якщо б ми не запропонували компанії владу над
користувачами цієї програми. Це припущення, можливо, здавалося
правдоподібним до того, як рух за вільне програмне забезпечення
продемонстрував, що ми можемо зробити безліч корисних програм, не накладаючи
на них ланцюгів.</p>
<p>
Якщо ми відхиляємо ці припущення і судимо про ці питання на основі моралі
звичайного здорового ґлузду, віддаючи пріоритет користувачам, то ми
приходимо до зовсім інших висновків. Користувачі комп'ютерів повинні бути
вільні змінювати програми під свої потреби і обмінюватися програмами, тому
що допомога іншим людям становить основу суспільства.</p>
<p>
Тут недостатньо місця для докладного викладу причин, що призводять до цього
висновку, тому я відсилаю читача до сторінок <a
href="/philosophy/why-free.html">
http://www.gnu.org/philosophy/why-free.html</a> та <a
href="/philosophy/free-software-even-more-important.html">
http://www.gnu.org/philosophy/free-software-even-more-important.html</a>.
</p>

<h3>Твердий моральний вибір</h3>
<p>
Оскільки моя громада зникла, я не міг продовжувати жити, як раніше. Замість
цього переді мною постав твердий моральний вибір.</p>
<p>
Найлегше було приєднатися до світу невільного програмного забезпечення,
підписуючи договори про нерозголошення і обіцяючи не допомагати своєму
братові-хакеру. Швидше за все, я також став би розробляти програми, які
випускали б на умовах нерозголошення, збільшуючи таким чином тиск на інших
людей, щоб вони теж зрадили своїх побратимів.</p>
<p>
Я міг би заробляти на цьому гроші, і можливо, мені було б цікаво писати
програми. Але я знав, що в кінці своєї кар'єри я озирнуся на минулі роки, в
які я будував стіни, щоб роз'єднати людей, і відчую, що я провів своє життя,
роблячи світ гіршим.</p>
<p>
Я вже відчув на собі, що буває, якщо інші підписують договір про&nbsp;
нерозголошення, коли хтось відмовився дати мені і ЛШІ вихідний текст
програми управління нашим принтером. (Відсутність певних функцій у&nbsp;цій
програмі призводило до&nbsp;того, що робота з&nbsp;цим принтером просто
виводила з&nbsp;себе.) Тому я не міг сказати собі, що договори
про&nbsp;нерозголошення&nbsp;&mdash; це щось невинне. Я дуже розлютився,
коли він відмовився поділитися з нами; я не міг встати на його місце і
робити те саме щодо всіх інших.</p>
<p>
Іншою можливістю, простою, але неприємною, була б можливість покинути галузь
обчислювальної техніки. В цьому випадку мої здібності не пішли б на шкоду,
але вони все-таки пропали даремно. Я не був би винен в роз'єднанні і
обмеженні користувачів комп'ютерів, але тим не менш це відбувалося б.</p>
<p>
Отож, я шукав спосіб, яким програміст міг би робити щось хороше. Я запитав
себе, чи не було програми або програм, які я міг би написати з тим, щоб
спільнота знову стала можливою.</p>
<p>
Відповідь була ясна: що було потрібно насамперед&nbsp;&mdash; це операційна
система. Ці програми життєво важливі для того, щоб приступити до
користування комп'ютером. Якщо є операційна система, то можна робити багато;
без неї на комп'ютері не можна працювати взагалі. З вільною операційною
системою у нас знову могло б бути спільнота співпрацюючих
хакерів&nbsp;&mdash; і ми могли б запрошувати будь-кого приєднатися до
нас. І кожний був би в змозі користуватися комп'ютером, не починаючи з
змови, яка позбавляє його друзів.</p>
<p>
У мене як у розробника операційної системи були потрібні для цієї роботи
навички. Тому, хоча не міг твердо розраховувати на успіх, я усвідомлював, що
сама доля вибрала мене для цієї справи. Я вирішив зробити систему сумісною з
Unix, щоби вона була переносна і щоб користувачі Unix могли легко перейти на
неї. Назва &ldquo;GNU&rdquo; була обрана через гакерську традицію як
рекурсивне скорочення фрази &ldquo;GNU's Not Unix&rdquo;  (Ґну не
Юнікс). Вона вимовляється як <a href="/gnu/pronunciation.html">один склад з
українським ґ</a>.</p>
<p>
Операційна система означає не тільки ядро, якого ледве достатньо для
виконання інших програм. У сімдесяті роки XX&nbsp;століття в кожну
операційну систему, що заслуговує цієї назви, входили командні оболонки,
асемблери, компілятори, інтерпретатори, налагоджувачі, текстові редактори,
поштові програми та багато іншого. Вони були в ITS, вони були в Multics,
вони були в VMS, вони були і в Unix. Вони будуть і в операційній системі
GNU.</p>
<p>
Пізніше я почув такі слова, приписувані Хілелу (1):</p>

<blockquote><p>
     Якщо я не за себе, хто буде за мене?<br />
     Якщо я тільки за себе, хто я такий?<br />
     Якщо не зараз, то коли?
</p></blockquote>
<p>
Рішення почати проект GNU було засноване на схожому уявленні.</p>
<p>
(1) Як атеїст я не є послідовником будь-яких релігійних лідерів, але іноді я
виявляю, що захоплююся тим, що сказав хто-небудь з них.</p>

<h3>Вільний від слова воля</h3>
<p>
Термін &ldquo;вільна програма&rdquo; іноді розуміють невірно&nbsp; &mdash;
він не має ніякого відношення до вартості. Він відноситься до волі. Таким
чином, ось визначення вільної програми.</p>

<p>Програма вільна для вас, конкретного користувача, якщо:</p>

<ul>
  <li>Ви вільні виконувати програму, як вам завгодно, в будь-яких цілях.</li>

  <li>Ви вільні змінювати програму під свої потреби. (Щоб ця можливість була
практично здійсненна, у вас повинен бути доступ до початкового тексту,
оскільки вносити зміни в програму без вихідного тексту надзвичайно важко.)</li>

  <li>Ви вільно перерозповсюджувати копії, безкоштовно або за гроші.</li>

  <li>Ви вільні поширювати змінені версії програми так, щоб суспільство могло
отримувати користь від ваших поліпшень.</li>
</ul>
<p>
Оскільки &ldquo;вільний&rdquo; відноситься до волі, а не вартості, між
продажем копій і вільними програмами немає суперечності. Насправді свобода
продавати копії життєво важлива: збірники вільних програм, продаються на
компакт-дисках, важливі для спільноти, і їх продаж&nbsp; &mdash; важливий
спосіб отримати кошти на розвиток вільних програм. Таким чином, програма,
яку люди не можуть включати в ці збірники, не є вільною.</p>
<p>
Неоднозначність слова &ldquo;вільний&rdquo; привела до довгих пошуків
альтернатив, але ніхто не знайшов кращого терміна. В англійській мові більше
слів і нюансів, ніж в будь-якій іншій, але в ній не вистачає простого
однозначного слова, яке означає &ldquo;вільний&rdquo; від слова &ldquo;
воля&rdquo;&nbsp;&nbsp; найближче до цього значення підходить слово
&ldquo;розкутий&rdquo;. Такі альтернативи, як &ldquo; звільнений&rdquo;,
&ldquo;воля&rdquo; (&ldquo;програми волі&rdquo;) і &ldquo;відкритий&rdquo;,
мають або невірне значення, або якийсь інший недолік.</p>

<h3>Програми GNU і система GNU</h3>
<p>
Розробка цілої системи - це дуже великий проект. Щоб зробити це досяжним, я
вирішив адаптувати і застосовувати, де тільки можливо, існуючі частини
вільних програм. Наприклад, я з самого початку вирішив застосовувати TeX в
якості основної програми форматування тексту; через кілька років я вирішив
скористатися системою X&nbsp;Window замість того, щоб писати ще одну віконну
систему для GNU.</p>
<p>
В результаті цих та інших подібних цим рішенням система GNU&nbsp;&mdash; це
не те ж саме, що збірка всіх програм GNU. Система GNU включає програми, які
не є програмами GNU&nbsp;&nbsp; програми, які розроблені іншими людьми і
проектами у їх власних цілях, але якими ми можемо скористатися, тому що вони
вільні.</p>

<h3>Початок проекту</h3>
<p>
У січні 1984&nbsp;року я звільнився з MIT і почав писати програми GNU. Піти
з MIT було необхідно, щоб інститут не зміг перешкодити поширенню GNU в
якості вільних програм. Якби я залишився в штаті, інститут міг би заявити,
що робота належить йому, і нав'язати свої власні умови поширення або навіть
перетворити роботу у пакет невільних програм. Я не мав наміру виконати
велику роботу тільки, щоб потім побачити, як вона стане непотрібною для
того, заради чого вона задумувалась&nbsp;&nbsp; створення нового громади
обміну програмами.</p>
<p>
Проте професор Уїнстон, тодішній керівник ЛШІ, люб'язно запросив мене
продовжувати користуватися ресурсами лабораторії.</p>

<h3>Перші кроки</h3>
<p>
Незабаром після організації проекту GNU я почув про Набір вільного
університету для компіляторів відомого також як VUCK. (Голландське слово
&ldquo;вільний&rdquo; пишеться через <em>v</em>.) Це був компілятор,
спроектований для роботи з багатьма мовами, включаючи Сі і Паскаль, і для
підтримки багатьох цільових машин. Я написав його автору і запитав, чи не
може GNU скористатися цим компілятором.</p>
<p>
Він відповів з насмішкою, заявивши, що університет вільний, а
компілятор&nbsp; &nbsp; ні. Таким чином, я вирішив, що моєю першою програмою
для проекту GNU стане багатомовний багатоплатформний компілятор.</p>
<p>
Сподіваючись уникнути необхідності писати весь компілятор самому, я дістав
вихідний текст компілятора мови Пастель. Це був багатоплатформний
компілятор, розроблений в Ліверморській лабораторії Лоуренса. Він
підтримував розширену версію мови Паскаль, задуману як системну мову
програмування, і був написаний на цій мові. Я додав інтерфейс для Сі і почав
переносити його на комп'ютер Motorola 68000. Але мені довелося кинути це,
коли я виявив, що компілятору потрібно багато мегабайт стекового простору, а
доступна система Unix 68000 допускала тільки 64k.</p>
<p>
Потім я усвідомив, що компілятор Пастеля функціонував, перетворюючи весь
вхідний файл в синтаксичне дерево, переводячи все дерево в ланцюжок &ldquo;
інструкцій&rdquo;, а потім генеруючи весь вихідний файл, не звільняючи
пам'ять ні на жодному етапі. В цей момент я прийшов до висновку, що мені
доведеться написати новий компілятор з нуля. Новий компілятор відомий як
<abbr title="GNU Compiler Collection">GCC</abbr>; з компілятора Пастеля в
ньому нічого не використовується, але мені вдалося адаптувати та
використовувати препроцесор Сі, який я написав. Але це сталося кілька років
потому; спочатку я працював над GNU Emacs.</p>

<h3>GNU Emacs</h3>
<p>
Я почав працювати над GNU Emacs у вересні 1984&nbsp;року, і на початку
1985&nbsp;року ним можна було починати користуватися. Це дозволило мені
почати користуватися системами Unix для редагування; оскільки вчитися
користування vi або ed мені було не цікаво, до цього я проводив редагування
на інших видах машин.</p>
<p>
У цей момент у людей почало виникати бажання користуватися GNU Emacs, що
поставило питання про те, як його поширювати. Звичайно, я помістив його на
сервері анонімного ftp на комп'ютері MIT, яким я користувався. (Цей
комп'ютер, prep.ai.mit.edu, став, таким чином, основним сайтом ftp для
поширення GNU; коли через кілька років його списали, ми перенесли це ім'я на
свій новий сервер ftp. Але в той час багато зацікавлених людей не були в
Інтернеті і не могли отримати копію з ftp. Отже, питання було в тому, що
мені їм казати?</p>
<p>
Я міг би сказати: &ldquo;Знайдіть знайомого, у якого є мережа і який зробить
вам копію&rdquo;. Або я міг би робити те, що я робив з початковим Emacs для
PDP-10&nbsp;&nbsp; сказати їм: &ldquo;Надішліть мені стрічку і конверт з
маркою та зворотною адресою, і я перешлю вам її з записаним на ній
Emacs&rdquo;. Але у мене не було роботи, і я шукав способи заробляти на
вільних програмах. Так що я оголосив, що буду висилати стрічку всім, кому
вона потрібна, за 150&nbsp;доларів. Таким чином я приступив до комерційного
поширення вільних програм і став предтечею компаній, які в наші дні
поширюють цілі системи GNU/Linux.</p>

<h3>Для кожного користувача програма вільна?</h3>
<p>
Якщо програма вільна, коли вона виходить з рук автора, це не обов'язково
означає, що вона буде вільною для всякого, у кого є її копія. Наприклад, <a
href="/philosophy/categories.html#PublicDomainSoftware">програми
в&nbsp;суспільному надбанні</a> (програми, на які не поширюється авторське
право) вільні; але будь-хто може зробити невільну модифікацію такої
програми. Подібним чином, багато вільних  програм знаходяться під дією
авторського права, але вони поширюються під простими необмежувальними
ліцензіями, які допускають невільні модифікації.</p>
<p>
Хрестоматійною ілюстрацією цієї проблеми є система X&nbsp;Window. Розроблена
в MIT і випущена як пакет вільних програм під необмежувальною ліцензією,
вона незабаром була освоєна різними комп'ютерними компаніями. Вони додали X
до своїх невільних систем Unix, поставляючи її тільки в двійковому вигляді,
і поширили на неї той самий договір про&nbsp;нерозголошення. Ці копії X були
не більше вільні, ніж Unix.</p>
<p>
Розробники системи X&nbsp;Window не вважали це проблемою&nbsp;&mdash; вони
цього чекали, і це відповідало їхнім намірам. Їх метою була не воля, а
тільки &ldquo;успіх&rdquo;, який визначається як &ldquo;велике число
користувачів&rdquo;. Їм було все одно, чи є у цих користувачів воля; вони
дбали тільки про те, щоб користувачі були численні.</p>
<p>
Це призвело до парадоксальної ситуації, за якої різні способи підрахунку
кількості волі дають різні відповіді на питання чи вільна програма? Якби ви
судили на підставі волі, що надається умовами ліцензії MIT, то ви б сказали,
що X вільна. Але якщо б ви міряли волю середнього користувача X, вам
довелося б сказати, що вона невільна. Більшість користувачів X працювало з
невільними версіями,  які поставлялися з системами Unix, а не з вільною
версією.</p>

<h3>Копілефт та GNU GPL</h3>
<p>
Метою GNU було дати користувачам волю, а не просто бути популярною. Тому нам
потрібно було застосувати умови розповсюдження, які запобігли б перетворенню
програм GNU у невільні програми. Метод, яким ми користуємося, називається
&ldquo;копілефтом&rdquo;.(1)</p>
<p>
Копілефт користується авторським правом, але перевертає його, щоб воно
служило цілям, протилежних тим, для яких воно зазвичай використовується:
замість того, щоб бути засобом обмеження програми, він стає засобом
збереження свободи програми.</p>
<p>
Центральна ідея копілефту полягає в тому, що ми даємо всім дозвіл виконувати
програму, копіювати програму, змінювати програму і поширювати змінені
версії&nbsp;&mdash; але не додавати дозвіл свої власні обмеження. Таким
чином, життєво важливі свободи, які визначають &ldquo;вільну
програму&rdquo;, гарантовані для кожного, у кого є копія; вони стають
невідчужуваними правами.</p>
<p>
Щоби копілефт був дієвим, змінені версії теж повинні бути вільні. Це
гарантує, що робота, заснована на нашій, стає доступною нашої спільноти,
якщо її публікують. Коли програмісти, які працюють програмістами, безоплатно
покращують програми GNU, саме копілефт не дає їх наймачам сказати:
&ldquo;Вам не можна обмінюватися цими змінами, тому що ми збираємося
скористатися ними, щоб зробити свою невільну версію цієї програми&rdquo;.</p>
<p>
Вимога, що зміни повинні бути вільні, істотно, якщо ми хочемо гарантувати
свободу кожного користувача програми. Компанії, які зробили невільні версії
системи X&nbsp;Window, зазвичай вносили зміни, щоб перенести її на свої
системи і свою апаратуру. Ці зміни були малі порівняно з найширшим
охопленням системи X, але вони не були тривіальні. Якби внесення змін
виправдовувало відмову користувачам у свободі, будь-хто  легко б скористався
цим виправданням.</p>
<p>
У зв'язку з цим виникає питання про поєднання вільної програми з невільними
вихідними текстами. Таке поєднання неминуче було б невільним; якщо невільною
частини бракує будь-яких свобод, цих свобод бракує і всієї програми в
цілому. Допустити такі сполучення означало б відкрити пролом, достатній, щоб
потопити корабель. Отже, вимога перекрити цю прогалину - критична для
копілефту: все, що додається або поєднується з програмою під копілефтом, має
бути таким, щоб велика комбінована версія також була вільною і щоб на неї
поширювався копілефт.</p>
<p>
Конкретна реалізація копілефту, яку ми застосовуємо в більшості програм
GNU&nbsp;&mdash; це загальна громадська ліцензія GNU, або скорочено GNU
GPL. У нас є інші види копілефту, вживані в особливих обставинах. Посібники
GNU також випускаються під копілефтом, але ми користуємося набагато
простішим видом копілефту, тому що для посібників не потрібна уся складність
GNU GPL.(2)</p>
<p>
(1) У 1984 чи 1985&nbsp;році Дон Хопкінс (юнак з багатою уявою) надіслав
мені листа. На конверті він написав кілька кумедних висловів, зокрема таке:
&ldquo;Копілефт&nbsp;&nbsp; усі права зареверсовані&rdquo;. Я скористався
виразом &ldquo;копілефт &rdquo; в якості назви концепції поширення, над якою
я в той час працював.</p>

<p>
(2) Зараз для документації ми користуємося <a href="/licenses/fdl.html">
Ліцензією вільної документації GNU </a>.</p>

<h3>Фонд вільного програмного забезпечення</h3>

<p>У міру зростання інтересу до користування Emacs зростав, проект GNU стали
залучатися інші люди, і ми вирішили, що пора знову пошукати фонди. Отже, в
1985&nbsp;році ми створили <a href="http://www.fsf.org/">Фонд вільного
програмного забезпечення</a> (ФВПЗ), благодійну організацію, яка
користується податковими пільгами, для розвитку вільного програмного
забезпечення. ФВПЗ також взяв на себе діяльність по розповсюдженню Emacs на
стрічках; згодом вона доповнилася додаванням на стрічку інших вільних
програм (як GNU, так і не GNU), а також продажем вільних посібників.</p>

<p>В ті часи дохід ФВПЗ складався здебільшого з прибутку від продажу копій
вільних програм та інших пов'язаних з цим послуг (компакт-дисків з вихідним
текстом, компакт-дисків з двійковими файлами, чудово роздрукованих
посібників&nbsp;&mdash; все це зі свободою і змінювати поширювати далі) і
дистрибутивів &laquo;люкс&raquo; (дистрибутивів, в яких ми транслювали
повний збірник програм для обраної клієнтом платформи). Сьогодні ФВПЗ як і
раніше <a href="http://shop.fsf.org/">продає посібники та інший товар</a>,
але основну частину коштів він отримує з членських внесків. Ви можете
приєднатися до ФВПЗ на <a href="http://fsf.org/join">fsf.org</a>.</p>

<p>Співробітники Фонду вільного програмного забезпечення написали і
підтримували деяку кількість пакетів програм GNU. Дві найбільш примітні -
бібліотека Сі та командний інтерпретатор. Бібліотека GNU Сі - це те, що
кожна програма, яка працює в системі GNU/Linux, використовує для зв'язку з
Linux. Вона була розроблена штатним співробітником Фонду вільного
програмного забезпечення Роландом Мак-Ґретом. Командний інтерпретатор, який
застосовується в більшості систем GNU/ Linux - це <abbr title="Bourne Again
Shell">BASH</abbr>, Знову оболонка Баурна (1), розроблений співробітником
ФВПЗ Брайєном Фоксом.</p>

<p>Ми фінансували розробку цих програм, тому що метою проекту GNU були не
тільки кошти або середовище розробки. Нашою метою була повна операційна
система, а ці програми були потрібні для досягнення цієї мети.</p>

<p>(1) &ldquo;Знову оболонка Баурна&rdquo;&nbsp;&nbsp; гра слів, побудована на
назві &ldquo;Оболонка Баурна&rdquo;&nbsp;&mdash; так називали звичайний
командний інтерпретатор Unix.</p>

<h3>Підтримка вільних програм</h3>

<p>Філософія вільного програмного забезпечення відкидає певну широко поширену
ділову практику, але вона не проти підприємництва. Коли підприємства
поважають свободу користувачів, ми бажаємо їм успіху.</p>

<p>Продаж копій Emacs ілюструє один з різновидів підприємницької діяльності,
заснований на вільних програмах. Коли ФВПЗ взяв цю справу на себе, мені
знадобився інший спосіб заробляти на життя. Я знайшов такий спосіб продажу
послуг, пов'язаних з вільними програмами, які я розробив. Сюди входило
навчання таких предметів, як програмування GNU Emacs, налаштування GCC і
розробка програм (здебільшого&nbsp;&mdash; перенесення GCC на нові
платформи).</p>

<p>Сьогодні кожен з цих видів діяльності практикується деяким числом
корпорацій. Одні поширюють збірники вільних програм на компакт-дисках; інші
продають послуги з підтримки різного рівня, починаючи від відповідей на
запитання користувачів та виправлення помилок і закінчуючи додаванням нових
серйозних функцій. Ми навіть починаємо зустрічати компанії, які займаються
вільними програмами і зосереджені на випуску нових вільних програмних
продуктів.</p>

<p>Однак будьте уважні&nbsp;&nbsp; деяке число компаній, які асоціюють себе з
терміном &ldquo;відкритий вихідний код&rdquo;, насправді засновують свої
підприємства на невільних програмах, які працюють з вільними програмами. Ці
компанії не є компаніями з розробки вільних програм&nbsp;&mdash; вони
займаються невільними програмами, та продукти їх заманюють користувачів геть
від свободи. Вони називають ці програми &ldquo;пакетами додаткової
цінності&rdquo;. Це показує, які цінності вони хотіли б змусити нас
засвоїти: пріоритет зручності над свободою. Якщо ми цінуємо свободу більше,
ми повинні називати ці пакети &ldquo;пакетами з дефіцитом свободи&rdquo;.</p>

<h3>Технічні цілі</h3>

<p>Основна мета GNU - бути вільним програмним забезпеченням. Навіть якщо б у
GNU не було технічних переваг перед Unix, у неї була б соціальна перевага -
дозвіл користувачам співпрацювати, і етична перевага - повага свободи
користувача.</p>

<p>Але було природно застосовувати в роботі відомі стандарти хорошої
практики&nbsp;&nbsp; наприклад, динамічне розміщення структур даних, щоб
уникнути довільних фіксованих обмежень на розмір, або обробку всіх можливих
8-розрядних кодів скрізь, де це має сенс.</p>

<p>На додаток, ми відмовилися від властивої Unix оптимізації під
невеликірозміри пам'яті, вирішивши не підтримувати 16-розрядні машини (було
ясно, що 32-розрядні машини будуть нормою до того часу, поки система GNU
будезавершена), і не намагатися знизити споживання пам'яті, якщо тільки воно
неперевищувало мегабайта. У програмах, для яких обробка дуже великихфайлів
не була життєво важлива, ми рекомендували програмістам читати весьвхідний
файл в пам'ять, а потім сканувати його вміст, не турбуючись
провведення-виведення.</p>

<p>Завдяки цим рішенням багато програм GNU змогли перевершити свої аналогиз
Unix по надійності і швидкості.</p>

<h3>Подаровані комп'ютери</h3>

<p>По мірі того, як репутація проекту GNU зростала, люди стали пропонувати в
дар проекту машини під управлінням Unix. Вони були дуже корисні, тому що
найпростіший способом розробки компонентів GNU полягав у виконанні цього в
системі Unix і замінювати компоненти цієї системи один за іншим. Але у
зв'язку з цим виникла етична проблема: чи вірним є те, що у нас взагалі була
копія Unix.</p>

<p>Unix була (і залишається) невільною, а згідно філософії проекту GNU нам не
слід користуватися невільними програмами. Але застосувавши той же хід
міркувань, який приводить до висновку, що насильство з метою самозахисту
виправдане, я зробив висновок, що застосування невільного пакету законне,
коли це критично для розробки вільної заміни, яка допомогла б іншим
припинити користуватися цим невільним пакетом.</p>

<p>Але хоча це було виправдане зло, все-таки це було зло. Сьогодні у насбільше
немає ніяких копій Unix, тому що ми замінили їх на вільніопераційні
системи. Якщо ми не могли замінити операційну систему машинина вільну, ми
замість цього замінювали машину.</p>

<h3>Список завдань GNU</h3>

<p>У міру здійснення проекту GNU і збільшення числа знайдених або розроблених
системних компонентів в якийсь момент стало корисно скласти список
неусунених прогалин. Ми користувалися ним для набору розробників, які б
писали відсутні частини. Цей список став відомий як &ldquo;Список завдань
GNU&rdquo;. На додаток до відсутніх компонентів Unix ми заносили туди різні
інші корисні проекти з написання програм і документації, які, як ми думали,
зобов'язана утримувати по-справжньому повна система.</p>

<p>Сьогодні (1) у &ldquo;Списку завдань GNU&rdquo; навряд чи залишилися
які-небудь компоненти Unix&nbsp;&nbsp; всі ці завдання були виконані, крім
кількох неістотних. Але список містить багато проектів, які хтось міг би
назвати &ldquo;програмами (застосунками)&rdquo;. Будь-яку програму,
привабливу більше, ніж для вузького класу користувачів, було б корисно
додати до операційної системи.</p>

<p>У список завдань включаються навіть гри&nbsp;&mdash; і так було з самого
початку.В Unix входили ігри, тому у GNU вони, природно, теж повинні
входити. Аледля ігор проблема сумісності не стояла, тому ми не повторювали
списокігор, які були в Unix. Замість цього ми записали цілий спектр різного
родуігор, які могли б сподобатися користувачам.</p>

<p>(1) Це було написано в 1998 році. Із 2009 року ми більше не підтримуємо
довгий список завдань. Співтовариство розробляє вільні програми так швидко,
що ми не можемо навіть відслідковувати їх усі. Замість цього у нас є список
високопріоритетних проектів - набагато коротший список проектів, до
здійснення яких ми хочемо заохотити людей перш за все.</p>

<h3>Бібліотечна GNU GPL</h3>

<p>Бібліотека GNU Сі використовує особливий різновид копілефту, який
називається Бібліотечною стандартною громадською ліцензією GNU&nbsp;(1), яка
дає дозвіл компонувати з цією бібліотекою невільні програми. Навіщо був
зроблений виняток?</p>

<p>Це не було справою принципу; немає принципу, за ким невільні програмні
продукти мають право включати в себе наші програми. (Навіщо вносити внесок у
проект, в основі якого лежить відмова ділитися з нами результатами?)
Застосування LGPL для бібліотеки Сі або для будь-якої іншої бібліотеки - це
питання стратегії.</p>

<p>Бібліотека Сі виконує загальну задачу; будь-яка невільна система або
компілятор поставляється з бібліотекою Сі. Отже, якщо б ми зробили свою
бібліотеку Сі доступною тільки для вільних програм, то це не надало б
вільним програмами ніякої переваги&nbsp;&mdash; це тільки створило б стимул
не користуватися нашою бібліотекою.</p>

<p>Для однієї системи це не вірно: в системі GNU (у тому числі GNU/Linux)
бібліотека GNU Сі&nbsp;&nbsp; єдина бібліотека Сі. Тому умови поширення
бібліотеки GNU Сі визначають, чи можна скомпілювати невільну програму для
системи GNU. Немає етичної причини, по якій слід дозволяти невільні програми
в системі GNU, але зі стратегічної точки зору здається, що їх заборона
сильніше відвертала б людей від користування системою GNU, ніж заохочувала б
розробляти вільні програми. Ось чому застосування Бібліотечної
GPL&nbsp;&nbsp; гарне стратегічне рішення для бібліотеки Сі.</p>

<p>Для інших бібліотек стратегічне рішення потрібно приймати окремо для кожного
випадку. Коли бібліотека вирішує спеціальну задачу, яка може допомогти в
написанні програм певних видів, то якщо випустити її під GPL, обмежуючи лише
вільними програмами, це буде одним із способів допомогти розробникам інших
вільних програм, надаючи їм перевагу перед невільним програмним
забезпеченням.</p>

<p>Розглянемо GNU Readline, бібліотеку, розроблену, щоб реалізувати редагування
командного рядка для BASH. Readline випускається під звичайною GNU GPL, а не
Бібліотечною GPL. Це, можливо, і звужує застосування Readline, але для нас
це не втрата. У той же час щонайменше один корисний додаток зробили вільною
програмою саме для того, щоб він міг використовувати Readline, а це реальний
виграш для спільноти.</p>

<p>У розробників невільних програм є переваги, що надаються грошима;
розробникам вільних програм потрібно створювати переваги один для одного. Я
сподіваюся, що настане день, коли у нас буде великий збірник бібліотек під
GPL, у яких немає аналогів, доступних для невільних програм. Цей збірник
буде надавати корисні модулі як будівельних блоків для нових вільних
програм, доповнюватиметься та з часом стане серйозним важелем для подальшого
розвитку вільних програм.</p>

<p>(1) Ця ліцензія зараз називається Меншою стандартною громадською ліцензією
GNU, щоб не наводити на думку, ніби всі бібліотеки зобов'язані користуватися
нею. Подробиці див. у &nbsp;статті <a
href="/philosophy/why-not-lgpl.html">&ldquo;Чому вам не слід застосовувати
Меншу GPL для своєї наступної бібліотеки&rdquo;</a>.</p>

<h3>Творча нетерплячка?</h3>
<p>
Ерік Реймонд каже, що &ldquo;будь-яка хороша робота з програмування
починається з задоволення особистої творчої нетерплячки
розробника&rdquo;. Може бути, іноді так і відбувається, але багато важливих
програм GNU були розроблені для того, щоб отримати повну вільну операційну
систему. Їх породило стратегічне планування, а не імпульс.</p>
<p>
Наприклад, ми розробили бібліотеки GNU Сі, тому що системі типу Unix
потрібна бібліотека Сі, BASH&nbsp;&nbsp; тому що в системі типу Unix
потрібен командний інтерпретатор, GNU tar&nbsp;&nbsp; тому що в системі типу
Unix потрібна програма tar. Те ж саме вірно і для моїх власних
програм&nbsp;&mdash; компілятор GNU Сі, GNU Emacs і GNU Make. </p>
<p>
Деякі програми GNU розроблені, щоб боротися з конкретними загрозами нашій
волі. Зокрема, ми розробили gzip, щоб замінити програму Compress, яка була
втрачена для суспільства через патенти на LZW. Ми знайшли людей для розробки
Lesstif, а пізніше організували <abbr title="GNU Network Object Model
Environment">GNOME</abbr> і Harmony, щоб вирішувати проблеми, викликані
певними невільними бібліотеками (див. нижче). Ми розробляємо GNU Privacy
Guard, щоб замінити популярну невільну програму шифрування, тому що
користувачі не повинні вибирати між конфіденційністю і свободою.</p>
<p>
Звичайно, у людей, які писали ці програми, з'являвся інтерес до цієї роботи,
і різні люди додали до цих програм багато можливостей для задоволення своїх
власних потреб та інтересів. Але це не причина існування цих програм.</p>

<h3>Несподівані розробки</h3>
<p>
На початку проекту GNU я уявляв собі, що ми розробимо всю систему GNU, а
потім випустимо її цілком. Але вийшло по-іншому.</p>
<p>
Оскільки кожен компонент системи GNU був реалізований в системі Unix, кожен
компонент міг працювати в системах Unix задовго до появи повної системи
GNU. Деякі з цих програм стали популярними, і користувачі почали розширювати
і переносити їх&nbsp;&nbsp; на різні несумісні версії Unix, а іноді і на
інші системи.</p>
<p>
У цьому процесі ці програми ставали набагато ефективніші і залучали
фінансові, так і людські ресурси в проект GNU. Але це також, ймовірно,
віддалило завершення мінімальної працюючої системи на декілька років,
оскільки час розробників GNU йшло на підтримку цих перенесених версій і
додавання можливостей до існуючих компонентів, замість того щоб переходити
до написання одного відсутнього компонента за іншим.</p>

<h3>GNU Hurd</h3>
<p>
До 1990&nbsp;року система GNU була майже завершена; єдиним серйозним
відсутнім компонентом було ядро. Ми вирішили реалізувати своє ядро як збірку
серверних процесів, що виконуються на Mach. Mach&nbsp;&mdash;мікроядро, яке
розроблялося в Університеті Карнегі-Меллона, а потім&nbsp;&mdash; в
Університеті Юти; GNU Hurd&nbsp;&nbsp; збірка серверів (тобто  табун GNU),
які працюють на Mach і виконують різні завдання ядра Unix. Початок розробки
віддалився, бо ми чекали, коли Mach випустять в якості вільної програми, як
було обіцяно.</p>
<p>
Однією з причин, по яких ми обрали таку архітектуру, було бажання уникнути
того, що здавалося найважчим в цій роботі: налагоджувати програму ядра, не
маючи для цього зневадника рівня вихідного тексту. Ця частина роботи була
виконана в Mach, і ми збиралися налагоджувати сервери Hurd як користувацькі
програми з допомогою GDB. Але на те, щоб зробити це можливим, пішло море
часу, а багатопотокові сервери, які розсилали один одному повідомлення,
виявилися дуже важкими в налагодженні. Досягнення стабільної роботи Hurd
розтягнулося на довгі роки.</p>

<h3>Alix</h3>
<p>
Спочатку не передбачалося, що ядро GNU буде називатися Hurd. Перша назва
була &ldquo;Alix&rdquo;&nbsp;&nbsp; на честь жінки, яка була в той час моєю
коханою. Вона, будучи системним адміністратором Unix, звернула увагу, що її
ім'я укладається в звичайну схему найменування версій системи Unix; жартома
вона сказала своїм друзям: &ldquo;кому-небудь слід було б назвати ядро в мою
честь&rdquo;. Я нічого не відповів, але вирішив зробити їй сюрприз, назвавши
ядро &ldquo;Alix&rdquo;.</p>
<p>
Але згодом становище змінилося. Майкл (тепер Томас) Бушнелл, головний
розробник ядра, волів назву &ldquo;Hurd&rdquo; і переніс назву Alix на певну
частину ядра&nbsp;&nbsp; ту, що перехоплювала системні виклики та обробляла
їх, розсилаючи повідомлення серверів Hurd.</p>
<p>
Згодом ми з Елікс розійшлися, а вона змінила ім'я; незалежно від цього
архітектура Hurd змінилася так, що бібліотека Сі стала розсилати
повідомлення серверів безпосередньо, і в результаті компонент Alix зник з
системи.</p>
<p>
Але до того, як все це сталося, її знайомий натрапив на назву
&ldquo;Alix&rdquo; у вихідному тексті Hurd і згадав про це в розмові з
нею. Так що можливість знайти ядро, назване на її честь, у неї була.</p>

<h3>Linux та GNU/Linux</h3>
<p>
GNU Hurd непридатне для повсякденного користування і ми не знаємо, чи буде
воно коли-небудь придатне. У архітектурного рішення, прийнятого на основі
потенційних можливостей, є проблеми, що випливають безпосередньо з гнучкості
архітектури і незрозуміло, чи можна їх вирішити.</p>

<p>
На щастя, є інше ядро. У 1991&nbsp;року Лінус Торвальдс розробив сумісне з
Unix ядро і назвав його Linux. Спершу воно було невільне, але у
1992&nbsp;році він зробив його  вільною  програмою; поєднання Linux з не
зовсім повною системою GNU дало   повну вільну операційну
систему. (Звичайно, поєднання було само по собі великою роботою.) Саме
завдяки Linux ми можемо сьогодні по справжньому працювати на одній з версій
системи GNU.</p>
<p>
Ми називаємо цю версію системи &ldquo;<a
href="/gnu/linux-and-gnu.html">GNU/Linux</a>&rdquo;, щоб показати її як
комбінацію системи GNU та Linux в якості ядра. Будь ласка, не набувайте
звички називати всю систему &ldquo;Linux&rdquo;, позаяк це означає
приписувати нашу роботу комусь іншому. <a href="/gnu/gnu-linux-faq.html">
Згадуйте, будь ласка, належним чином і нас</a>.</p>

<h3>Виклики у майбутньому</h3>
<p>
Ми довели, що ми здатні розробляти широкий спектр вільних програм. Це не
означає, що ми непереможні і нестримні. Кілька перешкод вносять
невизначеність у наше майбутнє; подолання їх потребує непохитної стійкості і
наполегливості, іноді протягом довгих років. Це вимагає рішучості, яку
виявляють люди, коли вони цінують свою свободу і не дають нікому забрати її.</p>
<p>
У наступних чотирьох розділах обговорюються ці виклики.</p>

<h3>Секретна апаратура</h3>
<p>
У виробників апаратної начинки спостерігається зростаюча тенденція зберігати
специфікації обладнання в секреті. Це ускладнює написання вільних драйверів,
потрібних для того, щоб Linux і XFree86 могли підтримувати нову
апаратуру. Сьогодні у нас є повні вільні системи, але у нас не буде їх
завтра, якщо ми не зможемо підтримувати завтрашні комп'ютери.</p>
<p>
Наявні два способи подолання цієї проблеми. Програмісти можуть проводити
зворотню розробку, щоб з'ясувати, як підтримувати цю апаратуру. Решта з нас
можуть обирати апаратуру, яка підтримується вільними програмами; по міру
того, як наші ряди будуть поповнюватися, зберігати специфікації в секреті
буде ставати катастрофічно невигідно.</p>
<p>
Зворотна розробка - велика робота; чи будуть у нас програмісти, рішучості
яких вистачило б на її здійснення? Так,  якщо ми виховаємо стійку
переконаність, що вільні програми -  справа принципу, а закриті драйвери
неприпустимі. Чи багато хто з нас витратить зайві гроші або хоча б трохи
часу, щоб ми могли користуватися вільними драйверами? Так, якщо рішучість
володіти свободою не буде рідкістю.</p>
<p>
(Зауваження 2008 року: ця проблема також стосується BIOS. Існує вільна BIOS,
<a href="http://www.libreboot.org/">LibreBoot</a>(дистрибутив coreboot);
проблема полягає в отриманні специфікацій на машини, щоб LibreBoot міг їх
підтримувати без невільних ляпок.)</p>

<h3>Невільні бібліотеки</h3>
<p>
Невільна бібліотека, яка працює під управлінням вільних операційних систем,
діє як пастка для розробників вільних програм. Привабливі особливості
бібліотеки - це приманка, якщо ви користуєтеся бібліотекою, ви потрапляєте в
пастку, бо ваша програма не може бути корисною частиною вільної операційної
системи. (Строго кажучи, ми могли б приєднати вашу програму, але вона не
буде <em>працювати</em>, якщо їй буде бракувати бібліотеки.) Гірше того:
якщо програма, яка користується невільною бібліотекою, стає популярною, вона
може заманити в пастку інших нічого не підозрюючих програмістів.</p>
<p>
Першим випадком цієї проблеми стала бібліотека Motif, ще у
вісімдесятих. Хоча вільних операційних систем ще не існувало, було ясно,
якою проблемою стане для них Motif згодом. Проект GNU відповів двома
заходами: він просив окремих розробників вільних програм підтримувати вільні
бібліотеки елементів управління X, а не тільки Motif, і просив знайти
кого-небудь, хто написав би вільну заміну Motif. Робота зайняла багато
років; Lesstif, розроблена групою &ldquo;Голодні програмісти&rdquo;, стала
достатньо ефективною, щоб підтримувати більшість додатків Motif, тільки
в&nbsp;1997&nbsp;році.</p>
<p>
Між 1996 і 1998&nbsp;роками інша невільна бібліотека графічного інтерфейсу
користувача, названа Qt, застосовувалася для значного масиву вільних програм
у графічному середовищі <abbr title="K Desktop Environment">KDE</abbr>.</p>
<p>
Вільні системи GNU/Linux були не в змозі користуватися KDE, тому що ми не
могли користуватися цією бібліотекою. Однак деякі комерційні постачальники
систем GNU/Linux, які не дотримувалися вільних програм суворо, додавали KDE
свої системи&nbsp;&nbsp; отримуючи систему з підвищеними можливостями, але
із зниженою свободою. Група KDE активно заохочувала інших програмістів
застосовувати Qt, і мільйони нових користувачів Linux ніколи не осявала
думка, що тут є якась проблема. Становище було дуже сумним.</p>
<p>
Спільнота вільного програмного забезпечення відповіло на проблему
двомазаходами: середовищем GNOME і бібліотекою Harmony.</p>
<p>
GNOME, Мережеве об'єктне модельне середовище GNU - проект графічного
середовища GNU. Започаткований у 1997 році Мігелем де Іказа і підтриманий
Red Hat Software GNOME поклав собі за мету надати схожі засоби графічного
середовища, але з застосуванням виключно вільних програм. У нього є і
технічні переваги, такі, як підтримка кількох мов, а не тільки Сі++. Але
головним його призначенням була свобода: не потрібно було користуватися
жодними невільними програмами.</p>
<p>
Harmony - сумісна бібліотека для заміни, спроектована для того, аби було
можливо виконувати програми KDE без Qt.</p>
<p>
У листопаді 1998&nbsp;року розробники Qt оголосили про зміну ліцензії, яка,
коли вона буде проведена, повинна зробити Qt вільною. Це неможливо довести,
але я думаю, що частково це було викликано рішучим відгуком спільноти на
проблему, яку породила Qt, коли була невільною. (Нова ліцензія незручна й
несправедлива, тому до цих пір бажано уникати Qt.)</p>
<p>
[Наступне зауваження: у вересні 2000 року Qt була випущена під GNU GPL, що,
по суті, вирішило цю проблему.]</p>
<p>
Як ми відповімо на таку спокусливу невільну бібліотеку? Чи буде уся громада
розуміти необхідність уникати пастки, чи багато з нас проміняє свободу на
зручність і породять серйозну проблему? Наше майбутнє залежить від нашої
філософії.</p>

<h3>Патенти на програми</h3>
<p>
Найнебезпечніша загроза, що постала перед нами, виходить від патентів на
програми, які можуть виносити алгоритми та функції програм за межі вільного
програмного забезпечення на термін до двадцяти років. Заявки на патенти на
алгоритм стиснення LZW були подані в 1983&nbsp;році, і ми досі не можемо
випускати вільні програми для створення справжніх стиснутих файлів GIF. [На
2009&nbsp;рік термін дії патентів минув.] У 1998&nbsp;році вільну програму
для створення стиснутого звукозапису у форматі  <abbr title="MPEG-1 Audio
Layer 3">MP3</abbr>  вилучили з дистрибутиву через боязнь патентного
позову.  [На 2017 рік термін дії цих патентів минув. Ось як довго нам
довелося чекати.]
</p>
<p>
Наявні два способи боротьби з патентами: можна віднайти докази того, що
патент недійсний або можна шукати альтернативні способи вирішення
завдання. Але кожен з цих методів працює тільки іноді; коли не допомагає ні
те, ні інше, патент може примусити всі вільні програми миритися з
відсутністю якоїсь особливості, яку хочуть користувачі. Через певний час дія
патентів мине, але що нам робити до цього?</p>
<p>
Ті з нас, хто цінує вільні програми заради свободи, все одно залишаться з
вільними програмами. При виконанні роботи ми будемо обходитися без
запатентованих особливостей. Але люди, які цінують вільні програми тому, що
очікують від них технічної переваги, ймовірно, скажуть, що програми не
виправдали сподівань, коли патент затримає їх розвиток. Таким чином, хоча
корисно говорити про практичну ефективність &ldquo; базарної&rdquo; схеми
розробки, надійність і ефективність якихось вільних програм, ми не повинні
на цьому зупинятися. Ми повинні говорити про свободу і принципи.</p>

<h3>Вільна документація</h3>
<p>
Найбільший дефіцит, який відчувають наші вільні операційні системи, полягає
не в програмах&nbsp;&mdash; він полягає в нестачі хороших вільних
посібників, які ми можемо включати в свої системи. Документація&nbsp;&nbsp;
істотна частина будь-якого пакета програм; коли у важливого пакету програм
немає хорошого вільного посібника, це серйозну упущення. Сьогодні у нас
багато таких прогалин.</p>
<p>
Вільна документація, як і вільні програми, відрізняється свободою, а не
вартістю. Критерій свободи посібника майже збігається з критерієм свободи
програми: це питання надання всім користувачам певних свобод. Поширення (в
тому числі комерційний продаж) повинне бути дозволено, в електронному
вигляді та на папері, щоб посібник міг супроводжувати кожну копію програми.</p>
<p>
Дозвіл вносити зміни також життєво важливий. Взагалі я не вважаю, що
важливо, щоб людям було дозволено змінювати будь-якого роду статті і
книги. Наприклад, я не думаю, що ви або я зобов'язані давати дозвіл
змінювати такі статті, як ця, що описує наші дії і наші погляди.</p>
<p>
Але є окрема причина, по якій свобода зміни критична для документації
вільних програм. Коли люди здійснюють своє право змінювати програми і
додають або змінюють її особливості, якщо вони свідомі, то вони будуть
змінювати також посібники, щоб надати зміненій програмі точну і корисну
документацію. Невільний посібник, який не дозволяє програмістам бути
свідомими і виконати роботу до кінця, не відповідає потребам нашої
спільноти.</p>
<p>
Деякого роду обмеження на те, як вносяться зміни, не становлять
проблеми. Наприклад, вимоги зберігати зауваження про авторські права
первісного автора, умови розповсюдження або список авторів цілком
допустимі. Також не становить проблеми вимога включати у змінені  версії
зауваження про те, що вони були змінені, і навіть вимога про збереження
цілих розділів в незмінному вигляді (до тих пір, поки ці розділи присвячені
нетехнічним питанням). Такого роду обмеження не становлять  проблеми, тому
що вони не заважають свідомому програмісту допрацьовувати посібник у
відповідності із змінами в програмі. Іншими словами, вони не перешкоджають
спільноті вільного програмного забезпечення користуватися посібником у
повному обсязі.</p>
<p>
Однак повинна бути можливість змінювати увесь <em>технічний</em> вміст
посібника, а потім поширювати результат на всіх звичайних носіях по всім
звичайним каналам; в іншому випадку такі обмеження заважають нашій
спільноті, бо посібник не вільний і нам потрібно інший посібник.</p>
<p>
Чи вистачить у розробників вільних програм обізнаності та рішучості на те,
щоб створити увесь спектр вільних посібників? У цьому випадку наше майбутнє
знову залежить від філософії.</p>

<h3>Ми повинні говорити про свободу</h3>
<p>
За сьогоднішніми оцінками існує десять мільйонів користувачів систем
GNU/Linux, таких як Debian GNU/Linux і Red&nbsp;Hat
&ldquo;Linux&rdquo;. Вільні програми набули такі практичні переваги, що
користувачі гуртуються навколо них по чисто практичних причинах.</p>
<p>
Добрі наслідки цього очевидні: зростання інтересу до розвитку вільних
програм, числа клієнтів підприємств, що займаються вільними програмами,
підвищення можливості заохочення компаній до розробки комерційних вільних
програм замість невільних програмних продуктів.</p>
<p>
Але інтерес до програм зростає швидше, ніж популярність філософії, на якій
вони ґрунтуються, а це веде до неприємностей. Наша здатність відповідати на
труднощі та загрози, описані вище, залежить від нашої волі твердо стояти за
свободу. Щоб гарантувати, що у нашого громади буде така воля, нам потрібно
передавати цю думку новим користувачам по мірі того, як вони вступають у
нашу громаду.</p>
<p>
Але нам це не вдається: роботи по залученню нових користувачів у нашій
громаді набагато випереджають роботи по навчанню їх цивільним нормам нашої
спільноти. Нам потрібно робити і те, і інше, дотримуючись балансу між цими
двома   видами діяльності.</p>

<h3>&ldquo;Відкритий вихідний код&rdquo;</h3>
<p>
Розповідати новим користувачам про свободу стало важче у 1998 році, коли
частина спільноти вирішила припинити користуватися терміном „вільна
програма“ та замість цього говорити „програма з відкритим вихідним кодом“.</p>
<p>
Деякі з тих, хто виступав за цей термін, прагнули уникнути плутанини між
&ldquo;вільним&rdquo; і &ldquo;безкоштовним&rdquo;&nbsp;&mdash; це була
розумна мета. Однак інші прагнули залишити в стороні дух принципів, які
мотивували рух за вільне програмне забезпечення і проект GNU, і апелювати
замість цього до керівників та підприємствам, багато з яких дотримувалися
ідеології, яка ставить вигоду вище свободи, вище єдності, вище
принциповості. Таким чином, аргументація &ldquo;відкритого вихідного
коду&rdquo; зосереджена на можливості отримання високоякісних ефективних
програм, але обходить стороною ідеї волі, єдності і принциповості.</p>
<p>
Журнали про &ldquo;Linux&rdquo;&nbsp;&nbsp; яскравий приклад такого підходу:
вони повні реклами невільних програм, що працюють під GNU/Linux. Коли
з'явиться наступний Motif або Qt, чи будуть ці журнали застерігати
програмістів від нього або вони будуть його рекламувати?</p>
<p>
Підтримка підприємництва може збагачувати нашу громаду з різних сторін; при
інших рівних умовах вона корисна. Але якщо завойовувати їх підтримку, кажучи
ще менше про свободу і принципи, це може призвести до катастрофи; це ще
більше посилює дисбаланс між популярністю і цивільним вихованням.</p>
<p>
&ldquo;Вільні програми&rdquo; і &ldquo;відкритий вихідний код&rdquo;
описують більш-менш одну і ту ж категорію програм, але про свободу, про
цінності вони говорять різне. Проект GNU продовжує вживати термін
&ldquo;вільна програма&rdquo;, щоб висловити думка, що важливою є свобода
взагалі, а не тільки технологія.</p>

<h3>Спробуйте!</h3>
<p>
Афоризм Йоди (&ldquo;&lsquo;Спроб&rsquo; не буває&rdquo;) звучить добре, але
для мене він не підходить. Коли я робив свою роботу, я майже завжди
турбувався, чи зможу я її виконати, і я не знав напевно, чи буде достатньо
для досягнення цілі, якщо я завершу цю роботу. Але я все одно намагався,
тому що між ворогом і моїм містом не було нікого, крім мене. На мій  власний
подив дещо мені вдавалося.</p>
<p>
Дещо мені не вдавалося; деякі з моїх міст впали. Тоді я знаходив інше
оточене місто і готувався до іншої битви. З часом я привчився шукати загрози
і ставити себе між ними і моїм містом, закликаючи інших хакерів встати поруч
зі мною.</p>
<p>
Сьогодні я часто не самотній. З радістю і полегшенням я бачу ряди хакерів,
які окопуються, щоб тримати лінію оборони, і я усвідомлюю, що це місто,
можливо, витримає облогу&nbsp;&nbsp; на цей раз. Але небезпеки ростуть з
кожним роком і вже компанія Microsoft відкрито бореться проти нашої
громади. Ми не можемо думати, що майбутнє свободи забезпечено. Не думайте
так! Якщо ви хочете зберегти свою свободу, ви повинні бути готові захищати
її.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.uk.html" -->
<div id="footer">
<div class="unprintable">

<p>Будь ласка, надсилайте загальні запити фонду та GNU за адресою <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Наявні також <a
href="/contact/">інші способи зв'язку</a> з фондом. Звіти про непрацюючі
посилання і інші виправлення чи пропозиції можна надсилати за адресою <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Ми намагалися зробити цей переклад точним та якісним, але виключити
можливість помилки ми не можемо. Надсилайте, будь ласка, свої зауваження і
пропозиції щодо перекладу за адресою <a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
</p><p>Відомості з координації та пропозицій перекладів наших статей див. у
<a href="/server/standards/README.translations.html">&ldquo;Посібнику з
перекладу&rdquo;</a>.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
2017, 2018, 2020 Річард Столмен</p>

<p>Ця сторінка доступна на умовах <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.uk"> ліцензії
Creative Commons Attribution-NoDerivatives (<em>Із зазначенням
авторства&nbsp;&mdash; Без похідних творів</em>) 4.0 Міжнародна</a>.</p>

<!--#include virtual="/server/bottom-notes.uk.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Підтримка українського перекладу: Андрій Бандура
(andriykopanytsia@gmail.com)</div>

<p class="unprintable"><!-- timestamp start -->
Оновлено:

$Date: 2020/07/25 20:00:29 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>