Цей переклад може не відображати змін, внесених із 2021-10-24 у англійський оригінал.

Ви можете поглянути на ці зміни. Будь-ласка перегляньте файл README стосовно перекладів для того, щоб отримати інформацію про координування перекладів цієї статті.

Проект GNU

Річард Столмен

Спочатку опубліковано в книзі Відкриті вихідні коди. Річард Столмен ніколи не був прихильником “відкритого вихідного коду”, але він передав цю статтю, щоб ідеї руху за вільне програмне забезпечення не були відсутні в цій книзі повністю.

Чому зараз важливо, як ніколи, наполягати на тому, щоб програми, якими ми користуємося, були вільними.

Перша громада обміну програмами

Коли в 1971 році я почав працювати в Лабораторії штучного інтелекту MIT, я став частиною громади обміну програмами, яка існувало протягом багатьох років. Обмін програмами не обмежувався нашою конкретною спільнотою; він був так само старий, як комп'ютери, подібно до того, як обмін рецептами, так само старий, як кулінарія. Але ми займалися цим більше, ніж інші.

Лабораторія ШІ (далі ЛШІ) користувалася операційною системою під назвою ITS (Несумісна система поділу часу), яку штатні хакери (1) лабораторії спроектували і написали на мові асемблера комп'ютера PDP-10 компанії Digital, одного з великих комп'ютерів тієї епохи. Моя робота як члена спільноти, штатного хакера ЛШІ, полягала в поліпшенні цієї системи.

Ми не називали свої програми “вільними програмами”, тому що такого терміну не існувало; але саме цим вони і були. Коли люди з іншого університету або компанії хотіли перенести або скористатися програмою, ми завжди з радістю дозволяли їм це. Якщо ви бачили, що хтось користується незнайомій та цікавою програмою, ви завжди могли попросити поглянути на вихідний текст, щоб його можна було прочитати, змінити або розібрати на запчастини для нової програми.

(1) Вживання слова “хакер” у значенні “зломлювач захисту”   помилка, якою ми зобов'язані засобам масової інформації. Ми, хакери, відмовляємося визнавати це значення й продовжуємо вживати це слово в значенні “той, хто любить програмувати, хто отримує задоволення від гри думки, або комбінація і того, і іншого”. Див. мою статтю “Про хакерство”.

Загибель громади

Ситуація різко змінилося на початку вісімдесятих років XX століття, коли компанія Digital припинила постачання обладнання для серії PDP-10. Її архітектура, витончена і потужна для шістдесятих, не могла природним чином розширюватися на місткіші адресні простори, які ставали досяжні у вісімдесятих. Це означало, що майже всі програми, які складали ITS, застаріли.

Громада хакерів ЛШІ вже розвалилася незадовго до цього. У 1981 році відділилася компанія Symbolics, яка переманила майже всіх хакерів з ЛШІ, і знелюдніла громада була не в змозі підтримувати себе (в книзі Стіва Леві “Хакери” описані ці події, а також дана ясна картина цієї спільноти у час її розквіту.) Коли в 1982 році ЛШІ купила нову PDP-10, адміністрація вирішила користуватися невільною системою поділу часу компанії Digital замість ITS.

У сучасних комп'ютерів тієї епохи, таких, як VAX або 68020, були свої власні операційні системи, але жодна з них не була вільною: доводилося підписувати договір про нерозголошення, щоб отримати хоча б копію виконуваних файлів.

Це означало, що першим кроком у користуванні комп'ютером була обіцянка не допомагати своєму сусідові. Співпраця у громаді була заборонена. Правило, встановлене власниками невільних програм, стверджувало: “Якщо ви обмінюєтеся зі своїм сусідом, то ви   пірат. Якщо вам потрібні будь-які зміни, просіть нас внести їх”.

Думка про те, що суспільна система невільного програмного забезпечення   система, в якій кажуть, що вам не дозволено обмінюватися програмами або змінювати їх   антисоціальна, що вона неетична, що вона просто неправильна, для деяких читачів може стати несподіванкою. Але що ще ми могли б сказати про систему, засновану на тому, що роз'єднує людей і користувачів робить безпорадними? Читачі, яким ця думка здається несподіваною, можливо, прийняли громадську систему невільного програмного забезпечення як данину часу або судили про неї у термінах, запропонованих підприємствами, які займаються невільними програмами. Видавці програм довго і наполегливо працювали над тим, щоб переконати людей, що на це питання можна дивитися тільки з однієї позиції.

Коли видавці програм говорять про “здійснення” своїх “ прав” або “припинення піратства”, те, що вони кажуть насправді є другорядним. Справжній зміст цих заяв полягає в невисловлених припущеннях, які вони вважають само собою зрозумілими і які суспільство просять прийняти без перевірки. Отже, давайте їх перевіримо.

Одне з припущень полягає в тому, що у програмних компаніях є незаперечне природне право володіти програмами і тим самим володіти владою над всіма користувачами цих програм. (Якщо б це було природним правом, то незалежно від того, скільки шкоди це завдає суспільству, ми не могли б заперечувати.) Цікаво, що конституція США та юридична традиція відкидають цю точку зору; авторське право не є природним, це штучна монополія, введена державою, яка обмежує природне право користувачів копіювати.

Інше невисловлене припущення полягає в тому, що єдине, що важливо в програмі — це те, яку роботу вона дозволяє вам виконувати; що нас, користувачів комп'ютерів, не повинно турбувати, якого роду суспільство нам дозволено мати.

Третє припущення полягає в тому, що у нас не було би програм, якими можна було б користуватися (чи ніколи не з'явилося б програми для виконання тієї чи іншої конкретної задачі), якщо б ми не запропонували компанії владу над користувачами цієї програми. Це припущення, можливо, здавалося правдоподібним до того, як рух за вільне програмне забезпечення продемонстрував, що ми можемо зробити безліч корисних програм, не накладаючи на них ланцюгів.

Якщо ми відхиляємо ці припущення і судимо про ці питання на основі моралі звичайного здорового ґлузду, віддаючи пріоритет користувачам, то ми приходимо до зовсім інших висновків. Користувачі комп'ютерів повинні бути вільні змінювати програми під свої потреби і обмінюватися програмами, тому що допомога іншим людям становить основу суспільства.

Тут недостатньо місця для докладного викладу причин, що призводять до цього висновку, тому я відсилаю читача до сторінок http://www.gnu.org/philosophy/why-free.html та http://www.gnu.org/philosophy/free-software-even-more-important.html.

Твердий моральний вибір

Оскільки моя громада зникла, я не міг продовжувати жити, як раніше. Замість цього переді мною постав твердий моральний вибір.

Найлегше було приєднатися до світу невільного програмного забезпечення, підписуючи договори про нерозголошення і обіцяючи не допомагати своєму братові-хакеру. Швидше за все, я також став би розробляти програми, які випускали б на умовах нерозголошення, збільшуючи таким чином тиск на інших людей, щоб вони теж зрадили своїх побратимів.

Я міг би заробляти на цьому гроші, і можливо, мені було б цікаво писати програми. Але я знав, що в кінці своєї кар'єри я озирнуся на минулі роки, в які я будував стіни, щоб роз'єднати людей, і відчую, що я провів своє життя, роблячи світ гіршим.

Я вже відчув на собі, що буває, якщо інші підписують договір про  нерозголошення, коли хтось відмовився дати мені і ЛШІ вихідний текст програми управління нашим принтером. (Відсутність певних функцій у цій програмі призводило до того, що робота з цим принтером просто виводила з себе.) Тому я не міг сказати собі, що договори про нерозголошення — це щось невинне. Я дуже розлютився, коли він відмовився поділитися з нами; я не міг встати на його місце і робити те саме щодо всіх інших.

Іншою можливістю, простою, але неприємною, була б можливість покинути галузь обчислювальної техніки. В цьому випадку мої здібності не пішли б на шкоду, але вони все-таки пропали даремно. Я не був би винен в роз'єднанні і обмеженні користувачів комп'ютерів, але тим не менш це відбувалося б.

Отож, я шукав спосіб, яким програміст міг би робити щось хороше. Я запитав себе, чи не було програми або програм, які я міг би написати з тим, щоб спільнота знову стала можливою.

Відповідь була ясна: що було потрібно насамперед — це операційна система. Ці програми життєво важливі для того, щоб приступити до користування комп'ютером. Якщо є операційна система, то можна робити багато; без неї на комп'ютері не можна працювати взагалі. З вільною операційною системою у нас знову могло б бути спільнота співпрацюючих хакерів — і ми могли б запрошувати будь-кого приєднатися до нас. І кожний був би в змозі користуватися комп'ютером, не починаючи з змови, яка позбавляє його друзів.

У мене як у розробника операційної системи були потрібні для цієї роботи навички. Тому, хоча не міг твердо розраховувати на успіх, я усвідомлював, що сама доля вибрала мене для цієї справи. Я вирішив зробити систему сумісною з Unix, щоби вона була переносна і щоб користувачі Unix могли легко перейти на неї. Назва “GNU” була обрана через гакерську традицію як рекурсивне скорочення фрази “GNU's Not Unix” (Ґну не Юнікс). Вона вимовляється як один склад з українським ґ.

Операційна система означає не тільки ядро, якого ледве достатньо для виконання інших програм. У сімдесяті роки XX століття в кожну операційну систему, що заслуговує цієї назви, входили командні оболонки, асемблери, компілятори, інтерпретатори, налагоджувачі, текстові редактори, поштові програми та багато іншого. Вони були в ITS, вони були в Multics, вони були в VMS, вони були і в Unix. Вони будуть і в операційній системі GNU.

Пізніше я почув такі слова, приписувані Хілелу (1):

Якщо я не за себе, хто буде за мене?
Якщо я тільки за себе, хто я такий?
Якщо не зараз, то коли?

Рішення почати проект GNU було засноване на схожому уявленні.

(1) Як атеїст я не є послідовником будь-яких релігійних лідерів, але іноді я виявляю, що захоплююся тим, що сказав хто-небудь з них.

Вільний від слова воля

Термін “вільна програма” іноді розуміють невірно  — він не має ніякого відношення до вартості. Він відноситься до волі. Таким чином, ось визначення вільної програми.

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

Оскільки “вільний” відноситься до волі, а не вартості, між продажем копій і вільними програмами немає суперечності. Насправді свобода продавати копії життєво важлива: збірники вільних програм, продаються на компакт-дисках, важливі для спільноти, і їх продаж  — важливий спосіб отримати кошти на розвиток вільних програм. Таким чином, програма, яку люди не можуть включати в ці збірники, не є вільною.

Неоднозначність слова “вільний” привела до довгих пошуків альтернатив, але ніхто не знайшов кращого терміна. В англійській мові більше слів і нюансів, ніж в будь-якій іншій, але в ній не вистачає простого однозначного слова, яке означає “вільний” від слова “ воля”   найближче до цього значення підходить слово “розкутий”. Такі альтернативи, як “ звільнений”, “воля” (“програми волі”) і “відкритий”, мають або невірне значення, або якийсь інший недолік.

Програми GNU і система GNU

Розробка цілої системи - це дуже великий проект. Щоб зробити це досяжним, я вирішив адаптувати і застосовувати, де тільки можливо, існуючі частини вільних програм. Наприклад, я з самого початку вирішив застосовувати TeX в якості основної програми форматування тексту; через кілька років я вирішив скористатися системою X Window замість того, щоб писати ще одну віконну систему для GNU.

В результаті цих та інших подібних цим рішенням система GNU — це не те ж саме, що збірка всіх програм GNU. Система GNU включає програми, які не є програмами GNU   програми, які розроблені іншими людьми і проектами у їх власних цілях, але якими ми можемо скористатися, тому що вони вільні.

Початок проекту

У січні 1984 року я звільнився з MIT і почав писати програми GNU. Піти з MIT було необхідно, щоб інститут не зміг перешкодити поширенню GNU в якості вільних програм. Якби я залишився в штаті, інститут міг би заявити, що робота належить йому, і нав'язати свої власні умови поширення або навіть перетворити роботу у пакет невільних програм. Я не мав наміру виконати велику роботу тільки, щоб потім побачити, як вона стане непотрібною для того, заради чого вона задумувалась   створення нового громади обміну програмами.

Проте професор Уїнстон, тодішній керівник ЛШІ, люб'язно запросив мене продовжувати користуватися ресурсами лабораторії.

Перші кроки

Незабаром після організації проекту GNU я почув про Набір вільного університету для компіляторів відомого також як VUCK. (Голландське слово “вільний” пишеться через v.) Це був компілятор, спроектований для роботи з багатьма мовами, включаючи Сі і Паскаль, і для підтримки багатьох цільових машин. Я написав його автору і запитав, чи не може GNU скористатися цим компілятором.

Він відповів з насмішкою, заявивши, що університет вільний, а компілятор    ні. Таким чином, я вирішив, що моєю першою програмою для проекту GNU стане багатомовний багатоплатформний компілятор.

Сподіваючись уникнути необхідності писати весь компілятор самому, я дістав вихідний текст компілятора мови Пастель. Це був багатоплатформний компілятор, розроблений в Ліверморській лабораторії Лоуренса. Він підтримував розширену версію мови Паскаль, задуману як системну мову програмування, і був написаний на цій мові. Я додав інтерфейс для Сі і почав переносити його на комп'ютер Motorola 68000. Але мені довелося кинути це, коли я виявив, що компілятору потрібно багато мегабайт стекового простору, а доступна система Unix 68000 допускала тільки 64k.

Потім я усвідомив, що компілятор Пастеля функціонував, перетворюючи весь вхідний файл в синтаксичне дерево, переводячи все дерево в ланцюжок “ інструкцій”, а потім генеруючи весь вихідний файл, не звільняючи пам'ять ні на жодному етапі. В цей момент я прийшов до висновку, що мені доведеться написати новий компілятор з нуля. Новий компілятор відомий як GCC; з компілятора Пастеля в ньому нічого не використовується, але мені вдалося адаптувати та використовувати препроцесор Сі, який я написав. Але це сталося кілька років потому; спочатку я працював над GNU Emacs.

GNU Emacs

Я почав працювати над GNU Emacs у вересні 1984 року, і на початку 1985 року ним можна було починати користуватися. Це дозволило мені почати користуватися системами Unix для редагування; оскільки вчитися користування vi або ed мені було не цікаво, до цього я проводив редагування на інших видах машин.

У цей момент у людей почало виникати бажання користуватися GNU Emacs, що поставило питання про те, як його поширювати. Звичайно, я помістив його на сервері анонімного ftp на комп'ютері MIT, яким я користувався. (Цей комп'ютер, prep.ai.mit.edu, став, таким чином, основним сайтом ftp для поширення GNU; коли через кілька років його списали, ми перенесли це ім'я на свій новий сервер ftp. Але в той час багато зацікавлених людей не були в Інтернеті і не могли отримати копію з ftp. Отже, питання було в тому, що мені їм казати?

Я міг би сказати: “Знайдіть знайомого, у якого є мережа і який зробить вам копію”. Або я міг би робити те, що я робив з початковим Emacs для PDP-10   сказати їм: “Надішліть мені стрічку і конверт з маркою та зворотною адресою, і я перешлю вам її з записаним на ній Emacs”. Але у мене не було роботи, і я шукав способи заробляти на вільних програмах. Так що я оголосив, що буду висилати стрічку всім, кому вона потрібна, за 150 доларів. Таким чином я приступив до комерційного поширення вільних програм і став предтечею компаній, які в наші дні поширюють цілі системи GNU/Linux.

Для кожного користувача програма вільна?

Якщо програма вільна, коли вона виходить з рук автора, це не обов'язково означає, що вона буде вільною для всякого, у кого є її копія. Наприклад, програми в суспільному надбанні (програми, на які не поширюється авторське право) вільні; але будь-хто може зробити невільну модифікацію такої програми. Подібним чином, багато вільних програм знаходяться під дією авторського права, але вони поширюються під простими необмежувальними ліцензіями, які допускають невільні модифікації.

Хрестоматійною ілюстрацією цієї проблеми є система X Window. Розроблена в MIT і випущена як пакет вільних програм під необмежувальною ліцензією, вона незабаром була освоєна різними комп'ютерними компаніями. Вони додали X до своїх невільних систем Unix, поставляючи її тільки в двійковому вигляді, і поширили на неї той самий договір про нерозголошення. Ці копії X були не більше вільні, ніж Unix.

Розробники системи X Window не вважали це проблемою — вони цього чекали, і це відповідало їхнім намірам. Їх метою була не воля, а тільки “успіх”, який визначається як “велике число користувачів”. Їм було все одно, чи є у цих користувачів воля; вони дбали тільки про те, щоб користувачі були численні.

Це призвело до парадоксальної ситуації, за якої різні способи підрахунку кількості волі дають різні відповіді на питання чи вільна програма? Якби ви судили на підставі волі, що надається умовами ліцензії MIT, то ви б сказали, що X вільна. Але якщо б ви міряли волю середнього користувача X, вам довелося б сказати, що вона невільна. Більшість користувачів X працювало з невільними версіями, які поставлялися з системами Unix, а не з вільною версією.

Копілефт та GNU GPL

Метою GNU було дати користувачам волю, а не просто бути популярною. Тому нам потрібно було застосувати умови розповсюдження, які запобігли б перетворенню програм GNU у невільні програми. Метод, яким ми користуємося, називається “копілефтом”.(1)

Копілефт користується авторським правом, але перевертає його, щоб воно служило цілям, протилежних тим, для яких воно зазвичай використовується: замість того, щоб бути засобом обмеження програми, він стає засобом збереження свободи програми.

Центральна ідея копілефту полягає в тому, що ми даємо всім дозвіл виконувати програму, копіювати програму, змінювати програму і поширювати змінені версії — але не додавати дозвіл свої власні обмеження. Таким чином, життєво важливі свободи, які визначають “вільну програму”, гарантовані для кожного, у кого є копія; вони стають невідчужуваними правами.

Щоби копілефт був дієвим, змінені версії теж повинні бути вільні. Це гарантує, що робота, заснована на нашій, стає доступною нашої спільноти, якщо її публікують. Коли програмісти, які працюють програмістами, безоплатно покращують програми GNU, саме копілефт не дає їх наймачам сказати: “Вам не можна обмінюватися цими змінами, тому що ми збираємося скористатися ними, щоб зробити свою невільну версію цієї програми”.

Вимога, що зміни повинні бути вільні, істотно, якщо ми хочемо гарантувати свободу кожного користувача програми. Компанії, які зробили невільні версії системи X Window, зазвичай вносили зміни, щоб перенести її на свої системи і свою апаратуру. Ці зміни були малі порівняно з найширшим охопленням системи X, але вони не були тривіальні. Якби внесення змін виправдовувало відмову користувачам у свободі, будь-хто легко б скористався цим виправданням.

У зв'язку з цим виникає питання про поєднання вільної програми з невільними вихідними текстами. Таке поєднання неминуче було б невільним; якщо невільною частини бракує будь-яких свобод, цих свобод бракує і всієї програми в цілому. Допустити такі сполучення означало б відкрити пролом, достатній, щоб потопити корабель. Отже, вимога перекрити цю прогалину - критична для копілефту: все, що додається або поєднується з програмою під копілефтом, має бути таким, щоб велика комбінована версія також була вільною і щоб на неї поширювався копілефт.

Конкретна реалізація копілефту, яку ми застосовуємо в більшості програм GNU — це загальна громадська ліцензія GNU, або скорочено GNU GPL. У нас є інші види копілефту, вживані в особливих обставинах. Посібники GNU також випускаються під копілефтом, але ми користуємося набагато простішим видом копілефту, тому що для посібників не потрібна уся складність GNU GPL.(2)

(1) У 1984 чи 1985 році Дон Хопкінс (юнак з багатою уявою) надіслав мені листа. На конверті він написав кілька кумедних висловів, зокрема таке: “Копілефт   усі права зареверсовані”. Я скористався виразом “копілефт ” в якості назви концепції поширення, над якою я в той час працював.

(2) Зараз для документації ми користуємося Ліцензією вільної документації GNU .

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

У міру зростання інтересу до користування Emacs зростав, проект GNU стали залучатися інші люди, і ми вирішили, що пора знову пошукати фонди. Отже, в 1985 році ми створили Фонд вільного програмного забезпечення (ФВПЗ), благодійну організацію, яка користується податковими пільгами, для розвитку вільного програмного забезпечення. ФВПЗ також взяв на себе діяльність по розповсюдженню Emacs на стрічках; згодом вона доповнилася додаванням на стрічку інших вільних програм (як GNU, так і не GNU), а також продажем вільних посібників.

В ті часи дохід ФВПЗ складався здебільшого з прибутку від продажу копій вільних програм та інших пов'язаних з цим послуг (компакт-дисків з вихідним текстом, компакт-дисків з двійковими файлами, чудово роздрукованих посібників — все це зі свободою і змінювати поширювати далі) і дистрибутивів «люкс» (дистрибутивів, в яких ми транслювали повний збірник програм для обраної клієнтом платформи). Сьогодні ФВПЗ як і раніше продає посібники та інший товар, але основну частину коштів він отримує з членських внесків. Ви можете приєднатися до ФВПЗ на fsf.org.

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

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

(1) “Знову оболонка Баурна”   гра слів, побудована на назві “Оболонка Баурна” — так називали звичайний командний інтерпретатор Unix.

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

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

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

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

Однак будьте уважні   деяке число компаній, які асоціюють себе з терміном “відкритий вихідний код”, насправді засновують свої підприємства на невільних програмах, які працюють з вільними програмами. Ці компанії не є компаніями з розробки вільних програм — вони займаються невільними програмами, та продукти їх заманюють користувачів геть від свободи. Вони називають ці програми “пакетами додаткової цінності”. Це показує, які цінності вони хотіли б змусити нас засвоїти: пріоритет зручності над свободою. Якщо ми цінуємо свободу більше, ми повинні називати ці пакети “пакетами з дефіцитом свободи”.

Технічні цілі

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

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

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

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

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

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

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

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

Список завдань GNU

У міру здійснення проекту GNU і збільшення числа знайдених або розроблених системних компонентів в якийсь момент стало корисно скласти список неусунених прогалин. Ми користувалися ним для набору розробників, які б писали відсутні частини. Цей список став відомий як “Список завдань GNU”. На додаток до відсутніх компонентів Unix ми заносили туди різні інші корисні проекти з написання програм і документації, які, як ми думали, зобов'язана утримувати по-справжньому повна система.

Сьогодні (1) у “Списку завдань GNU” навряд чи залишилися які-небудь компоненти Unix   всі ці завдання були виконані, крім кількох неістотних. Але список містить багато проектів, які хтось міг би назвати “програмами (застосунками)”. Будь-яку програму, привабливу більше, ніж для вузького класу користувачів, було б корисно додати до операційної системи.

У список завдань включаються навіть гри — і так було з самого початку.В Unix входили ігри, тому у GNU вони, природно, теж повинні входити. Аледля ігор проблема сумісності не стояла, тому ми не повторювали списокігор, які були в Unix. Замість цього ми записали цілий спектр різного родуігор, які могли б сподобатися користувачам.

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

Бібліотечна GNU GPL

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

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

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

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

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

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

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

(1) Ця ліцензія зараз називається Меншою стандартною громадською ліцензією GNU, щоб не наводити на думку, ніби всі бібліотеки зобов'язані користуватися нею. Подробиці див. у  статті “Чому вам не слід застосовувати Меншу GPL для своєї наступної бібліотеки”.

Творча нетерплячка?

Ерік Реймонд каже, що “будь-яка хороша робота з програмування починається з задоволення особистої творчої нетерплячки розробника”. Може бути, іноді так і відбувається, але багато важливих програм GNU були розроблені для того, щоб отримати повну вільну операційну систему. Їх породило стратегічне планування, а не імпульс.

Наприклад, ми розробили бібліотеки GNU Сі, тому що системі типу Unix потрібна бібліотека Сі, BASH   тому що в системі типу Unix потрібен командний інтерпретатор, GNU tar   тому що в системі типу Unix потрібна програма tar. Те ж саме вірно і для моїх власних програм — компілятор GNU Сі, GNU Emacs і GNU Make.

Деякі програми GNU розроблені, щоб боротися з конкретними загрозами нашій волі. Зокрема, ми розробили gzip, щоб замінити програму Compress, яка була втрачена для суспільства через патенти на LZW. Ми знайшли людей для розробки Lesstif, а пізніше організували GNOME і Harmony, щоб вирішувати проблеми, викликані певними невільними бібліотеками (див. нижче). Ми розробляємо GNU Privacy Guard, щоб замінити популярну невільну програму шифрування, тому що користувачі не повинні вибирати між конфіденційністю і свободою.

Звичайно, у людей, які писали ці програми, з'являвся інтерес до цієї роботи, і різні люди додали до цих програм багато можливостей для задоволення своїх власних потреб та інтересів. Але це не причина існування цих програм.

Несподівані розробки

На початку проекту GNU я уявляв собі, що ми розробимо всю систему GNU, а потім випустимо її цілком. Але вийшло по-іншому.

Оскільки кожен компонент системи GNU був реалізований в системі Unix, кожен компонент міг працювати в системах Unix задовго до появи повної системи GNU. Деякі з цих програм стали популярними, і користувачі почали розширювати і переносити їх   на різні несумісні версії Unix, а іноді і на інші системи.

У цьому процесі ці програми ставали набагато ефективніші і залучали фінансові, так і людські ресурси в проект GNU. Але це також, ймовірно, віддалило завершення мінімальної працюючої системи на декілька років, оскільки час розробників GNU йшло на підтримку цих перенесених версій і додавання можливостей до існуючих компонентів, замість того щоб переходити до написання одного відсутнього компонента за іншим.

GNU Hurd

До 1990 року система GNU була майже завершена; єдиним серйозним відсутнім компонентом було ядро. Ми вирішили реалізувати своє ядро як збірку серверних процесів, що виконуються на Mach. Mach —мікроядро, яке розроблялося в Університеті Карнегі-Меллона, а потім — в Університеті Юти; GNU Hurd   збірка серверів (тобто табун GNU), які працюють на Mach і виконують різні завдання ядра Unix. Початок розробки віддалився, бо ми чекали, коли Mach випустять в якості вільної програми, як було обіцяно.

Однією з причин, по яких ми обрали таку архітектуру, було бажання уникнути того, що здавалося найважчим в цій роботі: налагоджувати програму ядра, не маючи для цього зневадника рівня вихідного тексту. Ця частина роботи була виконана в Mach, і ми збиралися налагоджувати сервери Hurd як користувацькі програми з допомогою GDB. Але на те, щоб зробити це можливим, пішло море часу, а багатопотокові сервери, які розсилали один одному повідомлення, виявилися дуже важкими в налагодженні. Досягнення стабільної роботи Hurd розтягнулося на довгі роки.

Alix

Спочатку не передбачалося, що ядро GNU буде називатися Hurd. Перша назва була “Alix”   на честь жінки, яка була в той час моєю коханою. Вона, будучи системним адміністратором Unix, звернула увагу, що її ім'я укладається в звичайну схему найменування версій системи Unix; жартома вона сказала своїм друзям: “кому-небудь слід було б назвати ядро в мою честь”. Я нічого не відповів, але вирішив зробити їй сюрприз, назвавши ядро “Alix”.

Але згодом становище змінилося. Майкл (тепер Томас) Бушнелл, головний розробник ядра, волів назву “Hurd” і переніс назву Alix на певну частину ядра   ту, що перехоплювала системні виклики та обробляла їх, розсилаючи повідомлення серверів Hurd.

Згодом ми з Елікс розійшлися, а вона змінила ім'я; незалежно від цього архітектура Hurd змінилася так, що бібліотека Сі стала розсилати повідомлення серверів безпосередньо, і в результаті компонент Alix зник з системи.

Але до того, як все це сталося, її знайомий натрапив на назву “Alix” у вихідному тексті Hurd і згадав про це в розмові з нею. Так що можливість знайти ядро, назване на її честь, у неї була.

Linux та GNU/Linux

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

На щастя, є інше ядро. У 1991 року Лінус Торвальдс розробив сумісне з Unix ядро і назвав його Linux. Спершу воно було невільне, але у 1992 році він зробив його вільною програмою; поєднання Linux з не зовсім повною системою GNU дало повну вільну операційну систему. (Звичайно, поєднання було само по собі великою роботою.) Саме завдяки Linux ми можемо сьогодні по справжньому працювати на одній з версій системи GNU.

Ми називаємо цю версію системи “GNU/Linux”, щоб показати її як комбінацію системи GNU та Linux в якості ядра. Будь ласка, не набувайте звички називати всю систему “Linux”, позаяк це означає приписувати нашу роботу комусь іншому. Згадуйте, будь ласка, належним чином і нас.

Виклики у майбутньому

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

У наступних чотирьох розділах обговорюються ці виклики.

Секретна апаратура

У виробників апаратної начинки спостерігається зростаюча тенденція зберігати специфікації обладнання в секреті. Це ускладнює написання вільних драйверів, потрібних для того, щоб Linux і XFree86 могли підтримувати нову апаратуру. Сьогодні у нас є повні вільні системи, але у нас не буде їх завтра, якщо ми не зможемо підтримувати завтрашні комп'ютери.

Наявні два способи подолання цієї проблеми. Програмісти можуть проводити зворотню розробку, щоб з'ясувати, як підтримувати цю апаратуру. Решта з нас можуть обирати апаратуру, яка підтримується вільними програмами; по міру того, як наші ряди будуть поповнюватися, зберігати специфікації в секреті буде ставати катастрофічно невигідно.

Зворотна розробка - велика робота; чи будуть у нас програмісти, рішучості яких вистачило б на її здійснення? Так, якщо ми виховаємо стійку переконаність, що вільні програми - справа принципу, а закриті драйвери неприпустимі. Чи багато хто з нас витратить зайві гроші або хоча б трохи часу, щоб ми могли користуватися вільними драйверами? Так, якщо рішучість володіти свободою не буде рідкістю.

(Зауваження 2008 року: ця проблема також стосується BIOS. Існує вільна BIOS, LibreBoot(дистрибутив coreboot); проблема полягає в отриманні специфікацій на машини, щоб LibreBoot міг їх підтримувати без невільних ляпок.)

Невільні бібліотеки

Невільна бібліотека, яка працює під управлінням вільних операційних систем, діє як пастка для розробників вільних програм. Привабливі особливості бібліотеки - це приманка, якщо ви користуєтеся бібліотекою, ви потрапляєте в пастку, бо ваша програма не може бути корисною частиною вільної операційної системи. (Строго кажучи, ми могли б приєднати вашу програму, але вона не буде працювати, якщо їй буде бракувати бібліотеки.) Гірше того: якщо програма, яка користується невільною бібліотекою, стає популярною, вона може заманити в пастку інших нічого не підозрюючих програмістів.

Першим випадком цієї проблеми стала бібліотека Motif, ще у вісімдесятих. Хоча вільних операційних систем ще не існувало, було ясно, якою проблемою стане для них Motif згодом. Проект GNU відповів двома заходами: він просив окремих розробників вільних програм підтримувати вільні бібліотеки елементів управління X, а не тільки Motif, і просив знайти кого-небудь, хто написав би вільну заміну Motif. Робота зайняла багато років; Lesstif, розроблена групою “Голодні програмісти”, стала достатньо ефективною, щоб підтримувати більшість додатків Motif, тільки в 1997 році.

Між 1996 і 1998 роками інша невільна бібліотека графічного інтерфейсу користувача, названа Qt, застосовувалася для значного масиву вільних програм у графічному середовищі KDE.

Вільні системи GNU/Linux були не в змозі користуватися KDE, тому що ми не могли користуватися цією бібліотекою. Однак деякі комерційні постачальники систем GNU/Linux, які не дотримувалися вільних програм суворо, додавали KDE свої системи   отримуючи систему з підвищеними можливостями, але із зниженою свободою. Група KDE активно заохочувала інших програмістів застосовувати Qt, і мільйони нових користувачів Linux ніколи не осявала думка, що тут є якась проблема. Становище було дуже сумним.

Спільнота вільного програмного забезпечення відповіло на проблему двомазаходами: середовищем GNOME і бібліотекою Harmony.

GNOME, Мережеве об'єктне модельне середовище GNU - проект графічного середовища GNU. Започаткований у 1997 році Мігелем де Іказа і підтриманий Red Hat Software GNOME поклав собі за мету надати схожі засоби графічного середовища, але з застосуванням виключно вільних програм. У нього є і технічні переваги, такі, як підтримка кількох мов, а не тільки Сі++. Але головним його призначенням була свобода: не потрібно було користуватися жодними невільними програмами.

Harmony - сумісна бібліотека для заміни, спроектована для того, аби було можливо виконувати програми KDE без Qt.

У листопаді 1998 року розробники Qt оголосили про зміну ліцензії, яка, коли вона буде проведена, повинна зробити Qt вільною. Це неможливо довести, але я думаю, що частково це було викликано рішучим відгуком спільноти на проблему, яку породила Qt, коли була невільною. (Нова ліцензія незручна й несправедлива, тому до цих пір бажано уникати Qt.)

[Наступне зауваження: у вересні 2000 року Qt була випущена під GNU GPL, що, по суті, вирішило цю проблему.]

Як ми відповімо на таку спокусливу невільну бібліотеку? Чи буде уся громада розуміти необхідність уникати пастки, чи багато з нас проміняє свободу на зручність і породять серйозну проблему? Наше майбутнє залежить від нашої філософії.

Патенти на програми

Найнебезпечніша загроза, що постала перед нами, виходить від патентів на програми, які можуть виносити алгоритми та функції програм за межі вільного програмного забезпечення на термін до двадцяти років. Заявки на патенти на алгоритм стиснення LZW були подані в 1983 році, і ми досі не можемо випускати вільні програми для створення справжніх стиснутих файлів GIF. [На 2009 рік термін дії патентів минув.] У 1998 році вільну програму для створення стиснутого звукозапису у форматі MP3 вилучили з дистрибутиву через боязнь патентного позову. [На 2017 рік термін дії цих патентів минув. Ось як довго нам довелося чекати.]

Наявні два способи боротьби з патентами: можна віднайти докази того, що патент недійсний або можна шукати альтернативні способи вирішення завдання. Але кожен з цих методів працює тільки іноді; коли не допомагає ні те, ні інше, патент може примусити всі вільні програми миритися з відсутністю якоїсь особливості, яку хочуть користувачі. Через певний час дія патентів мине, але що нам робити до цього?

Ті з нас, хто цінує вільні програми заради свободи, все одно залишаться з вільними програмами. При виконанні роботи ми будемо обходитися без запатентованих особливостей. Але люди, які цінують вільні програми тому, що очікують від них технічної переваги, ймовірно, скажуть, що програми не виправдали сподівань, коли патент затримає їх розвиток. Таким чином, хоча корисно говорити про практичну ефективність “ базарної” схеми розробки, надійність і ефективність якихось вільних програм, ми не повинні на цьому зупинятися. Ми повинні говорити про свободу і принципи.

Вільна документація

Найбільший дефіцит, який відчувають наші вільні операційні системи, полягає не в програмах — він полягає в нестачі хороших вільних посібників, які ми можемо включати в свої системи. Документація   істотна частина будь-якого пакета програм; коли у важливого пакету програм немає хорошого вільного посібника, це серйозну упущення. Сьогодні у нас багато таких прогалин.

Вільна документація, як і вільні програми, відрізняється свободою, а не вартістю. Критерій свободи посібника майже збігається з критерієм свободи програми: це питання надання всім користувачам певних свобод. Поширення (в тому числі комерційний продаж) повинне бути дозволено, в електронному вигляді та на папері, щоб посібник міг супроводжувати кожну копію програми.

Дозвіл вносити зміни також життєво важливий. Взагалі я не вважаю, що важливо, щоб людям було дозволено змінювати будь-якого роду статті і книги. Наприклад, я не думаю, що ви або я зобов'язані давати дозвіл змінювати такі статті, як ця, що описує наші дії і наші погляди.

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

Деякого роду обмеження на те, як вносяться зміни, не становлять проблеми. Наприклад, вимоги зберігати зауваження про авторські права первісного автора, умови розповсюдження або список авторів цілком допустимі. Також не становить проблеми вимога включати у змінені версії зауваження про те, що вони були змінені, і навіть вимога про збереження цілих розділів в незмінному вигляді (до тих пір, поки ці розділи присвячені нетехнічним питанням). Такого роду обмеження не становлять проблеми, тому що вони не заважають свідомому програмісту допрацьовувати посібник у відповідності із змінами в програмі. Іншими словами, вони не перешкоджають спільноті вільного програмного забезпечення користуватися посібником у повному обсязі.

Однак повинна бути можливість змінювати увесь технічний вміст посібника, а потім поширювати результат на всіх звичайних носіях по всім звичайним каналам; в іншому випадку такі обмеження заважають нашій спільноті, бо посібник не вільний і нам потрібно інший посібник.

Чи вистачить у розробників вільних програм обізнаності та рішучості на те, щоб створити увесь спектр вільних посібників? У цьому випадку наше майбутнє знову залежить від філософії.

Ми повинні говорити про свободу

За сьогоднішніми оцінками існує десять мільйонів користувачів систем GNU/Linux, таких як Debian GNU/Linux і Red Hat “Linux”. Вільні програми набули такі практичні переваги, що користувачі гуртуються навколо них по чисто практичних причинах.

Добрі наслідки цього очевидні: зростання інтересу до розвитку вільних програм, числа клієнтів підприємств, що займаються вільними програмами, підвищення можливості заохочення компаній до розробки комерційних вільних програм замість невільних програмних продуктів.

Але інтерес до програм зростає швидше, ніж популярність філософії, на якій вони ґрунтуються, а це веде до неприємностей. Наша здатність відповідати на труднощі та загрози, описані вище, залежить від нашої волі твердо стояти за свободу. Щоб гарантувати, що у нашого громади буде така воля, нам потрібно передавати цю думку новим користувачам по мірі того, як вони вступають у нашу громаду.

Але нам це не вдається: роботи по залученню нових користувачів у нашій громаді набагато випереджають роботи по навчанню їх цивільним нормам нашої спільноти. Нам потрібно робити і те, і інше, дотримуючись балансу між цими двома видами діяльності.

“Відкритий вихідний код”

Розповідати новим користувачам про свободу стало важче у 1998 році, коли частина спільноти вирішила припинити користуватися терміном „вільна програма“ та замість цього говорити „програма з відкритим вихідним кодом“.

Деякі з тих, хто виступав за цей термін, прагнули уникнути плутанини між “вільним” і “безкоштовним” — це була розумна мета. Однак інші прагнули залишити в стороні дух принципів, які мотивували рух за вільне програмне забезпечення і проект GNU, і апелювати замість цього до керівників та підприємствам, багато з яких дотримувалися ідеології, яка ставить вигоду вище свободи, вище єдності, вище принциповості. Таким чином, аргументація “відкритого вихідного коду” зосереджена на можливості отримання високоякісних ефективних програм, але обходить стороною ідеї волі, єдності і принциповості.

Журнали про “Linux”   яскравий приклад такого підходу: вони повні реклами невільних програм, що працюють під GNU/Linux. Коли з'явиться наступний Motif або Qt, чи будуть ці журнали застерігати програмістів від нього або вони будуть його рекламувати?

Підтримка підприємництва може збагачувати нашу громаду з різних сторін; при інших рівних умовах вона корисна. Але якщо завойовувати їх підтримку, кажучи ще менше про свободу і принципи, це може призвести до катастрофи; це ще більше посилює дисбаланс між популярністю і цивільним вихованням.

“Вільні програми” і “відкритий вихідний код” описують більш-менш одну і ту ж категорію програм, але про свободу, про цінності вони говорять різне. Проект GNU продовжує вживати термін “вільна програма”, щоб висловити думка, що важливою є свобода взагалі, а не тільки технологія.

Спробуйте!

Афоризм Йоди (“‘Спроб’ не буває”) звучить добре, але для мене він не підходить. Коли я робив свою роботу, я майже завжди турбувався, чи зможу я її виконати, і я не знав напевно, чи буде достатньо для досягнення цілі, якщо я завершу цю роботу. Але я все одно намагався, тому що між ворогом і моїм містом не було нікого, крім мене. На мій власний подив дещо мені вдавалося.

Дещо мені не вдавалося; деякі з моїх міст впали. Тоді я знаходив інше оточене місто і готувався до іншої битви. З часом я привчився шукати загрози і ставити себе між ними і моїм містом, закликаючи інших хакерів встати поруч зі мною.

Сьогодні я часто не самотній. З радістю і полегшенням я бачу ряди хакерів, які окопуються, щоб тримати лінію оборони, і я усвідомлюю, що це місто, можливо, витримає облогу   на цей раз. Але небезпеки ростуть з кожним роком і вже компанія Microsoft відкрито бореться проти нашої громади. Ми не можемо думати, що майбутнє свободи забезпечено. Не думайте так! Якщо ви хочете зберегти свою свободу, ви повинні бути готові захищати її.