Історія розвитку ВПЗ

Програму можна вільно використовувати  з будь-якою метою ( « нульова свобода  »).

Можна вивчати , як програма працює, і  адаптувати її для своїх цілей ( «  перша свобода »). Умовою цього  є доступність вихідного тексту програми .

Можна вільно поширювати копії програми - на допомогу товаришу ( «друга свобода  »).

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

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

Тільки задовольняє всім чотирьом перерахованим принципам програма може вважатися вільної програмою , тобто гарантовано відкритою  і доступною для модернізації та виправлення помилок і дефектів , і не має обмежень на використання та поширення. Потрібно підкреслити , що ці принципи обумовлюють тільки доступність  вихідних текстів програм для  загального використання , критики  і поліпшення , і права користувача , що отримав здійсненний або вихідний код програми , але ніяк не обумовлюють  пов'язані з поширенням програм  грошові відносини , в тому числі  не припускають і безоплатності . В англомовних текстах тут  часто виникає плутанина , оскільки слово « free » по-англійськи означає  не тільки «вільне » , а й « безкоштовне» , і нерідко вживається стосовно безкоштовному програмному забезпеченню , яке поширюється без справляння плати за використання , але недоступне для зміни користувачами і співтовариством , тому що його вихідні тексти не опубліковані. Таке безкоштовне ПЗ зовсім не є вільним. Навпаки , вільне ПЗ цілком можна поширювати (і поширюють ) , стягуючи при цьому плату , однак дотримуючись при цьому критерії свободи: кожному користувачеві надається право отримати вихідні тексти програм без додаткової плати ( за винятком ціни носія) , змінювати їх і поширювати далі. Всяке програмне забезпечення , користувачам якого не надається такого права , є невільним - незалежно від будь-яких інших умов. 
Open source software

Відкритий доступ до вихідних текстів  програм є ключовою ознакою вільного ПЗ , тому запропонований дещо пізніше  Еріком Реймондом термін open source software ( ПО з відкритим вихідним текстом) деяким представляється навіть більш  вдалим для позначення даного феномена , ніж спочатку запропонований Столлманом « free software ». Столлман наполягає на відмінності  цих двох понять , оскільки слова open source вказують лише на наявність одного , чи не найважливішого (хоча і необхідного  для реалізації двох з чотирьох свобод ) , на його думку , з властивостей , притаманних  вільному ПЗ - можливості побачити вихідний код.

Хоча різні формальні визначення вільних і відкритих творів зазвичай багато в чому збігаються для ПО , вираження open source і « відкрите програмне  забезпечення » в окремих випадках використовується [ ким?] Для пропрієтарного ПЗ , які не підходящого ні під  одне з них (наприклад , комерційне ПЗ з відкритим вихідним кодом) .  
Основна громадська ліцензія GNU

Логотип GNU GPLv3

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

Річард Столлман займався розробкою  текстового редактора Emacs на основі вихідних текстів Джеймса Гослінга . Тоді Гослінг вільно роздавав свої вихідні  тексти всім зацікавленим . Проте в  якийсь момент Гослінг продав права  на розповсюдження Emacs компанії UniPress [ 5] , і ця компанія попросила Столлман припинити поширення його версії Emacs , так як права належать їм. [ Стиль! ] Цей інцидент змусив Столлман переписати заново ті частини початкового тексту Emacs , які тепер належали UniPress , після  чого він розробив власну ліцензію на своє програмне забезпечення .

Ліцензія , сформульована Столлманом , повинна була працювати так само , як і ліцензії на невільне програмне  забезпечення : це типовий договір  автора програми ( власника авторських прав) з користувачем , у якому  автор , серед іншого , обумовлює  права користувача по відношенню до програми . На відміну від типової  власницькою ліцензії , ліцензія Столлман надає користувачеві права , які  є критеріями вільної програми : отримувати вихідні тексти програм , змінювати їх , поширювати змінені, і незмінені версії. Згодом ліцензія Столлман отримала назву GNU General Public License ( «Основна громадська ліцензія GNU "), скорочено GNU GPL або просто GPL.

У цій ліцензії обмовляється також  принципове для Столлман захисне  умова поширення вільного ПЗ: жоден  користувач , який зробив модифіковану версію вільної програми , не має  права поширювати її , не дотримуючись всіх принципів вільного ПЗ , тобто  робити модифікацію вільної програми невільною . Щоб підкреслити відмінність  такої ліцензії , яка використовує ЗоАП ( copyright ) для спонукання до збереження свободи , від типових власницьких  ліцензій , які використовують ЗоАП для обмеження свободи , був придуманий термін copyleft ( копілефт ) - гра слів , побудована на значеннях англійських  слів right і left . Дія копілефту засноване  на тому , що похідні роботи в більшості  випадків успадковують ліцензії своїх  складових; якщо в програмі використовується невелика частина стороннього коду під GPL , то вся програма і її похідні  повинні поширюватися під GPL , поки вони є похідними цього коду . При  цьому в GPL є розділ, що дозволяє вимагати збереження в коді імен авторів , забороняти використання цих імен в рекламі , попереджати про зареєстровані  товарні знаки і т. п. , що дозволяє комбінувати роботи під GPL з роботами під багатьма вільними некопілефтнимі ліцензіями (наприклад , деякими з  ліцензій BSD ) , не створюючи значних  обмежень і не порушуючи ліцензії , - але похідні від результату , будучи похідними від роботи під GPL , вже не можуть (без окремого дозволу  правовласників ) поширюватися на умовах даної некопілефт - ліцензії без  дотримання умов GPL - у тому числі  і як невід'ємна частина невільного ПЗ. З цієї причини ліцензії , подібні GNU GPL , іноді називають також «  вірусними ліцензіями » : вони ніби « заражають » програму , стаючи її невід'ємною частиною. 
Спільнота розробників і користувачів

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

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

Користувач вільно поширюваної програми не отримує  разом з нею ніяких гарантій : автор зробив її вихідний текст відкритим  для суспільства , але при цьому  не взяв на себе зобов'язань пояснювати всім , як працює програма. Хоча справедливості заради варто помітити , що будь-яка  невільна програма в 99 % випадках теж  поставляється «як є» і без  гарантій. Оскільки спільнота користувачів більшості програм розподілено  по всьому світу , для організації  взаємодії в ньому найбільш активні  користувачі ( а часто і самі автори ) організують (рідше - використовують існуючі ) списки розсилки , форуми та інші засоби спілкування в Інтернеті. Для накопичення і рубрикації інформації по програмі ( зокрема , списків  часто ставляться ( ЧаВо ; англ. FAQ - frequently asked questions ) , а також організації  більш складних форм взаємодії ( спільної розробки , систем відслідковування помилок ) створюються веб - сайти , присвячені програмам. 
Виправлення помилок

У будь-який досить складною програмою неодмінно  є помилки і дефекти , кількість  яких звичайно невідомо. Багато великих  виробники ПЗ створюють і оплачують  роботу відділу контролю якості ( QA - Quality assurance ) , який контролює відповідність  процесу розробки ПЗ певним вимогам , виконання яких дозволяє знизити  ймовірність появи помилок в  ПЗ (наприклад , вимогам стандарту DO - 178B , який застосовується при розробці ПЗ для авіаційних систем). Тим не менш, у даний час відсутні методи, що дозволяють повністю гарантувати  відсутність помилок в досить складному ПЗ ( існують формалізовані  критерії складності ПЗ).

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

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

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

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

У типовою  вільної програми ( тобто , некомерційною  і / або розроблюваної невеликою  компанією або приватною особою ) зазвичай немає оплачуваної відділу  контролю якості. Значить , користувач може зіткнутися з ще більшою кількістю  помилок , ніж в типовій комерційної  проприетарной програмі . Тим актуальніше  для нього можливість повідомити про помилку розробникам програми . Раніше в супроводжує програму документації було прийнято вказувати  електронну адресу, за якою розробники брали повідомлення про помилки ( bug report ) . Деякі вводили стереотипну  форму для таких повідомлень , щоб полегшити і автоматизувати їх обробку . Вже це вимагає істотно  більш високою зв'язності сообщества в усьому світі , істотно більшою , ніж достатньо для закритої розробки.

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

Простому  та впорядкованому прийому та перенаправлення  повідомлень про помилки служать  системи відслідковування помилок ( bug tracking system ) , найвідоміші з яких розроблені учасниками великих проектів для себе , а завдяки вільними ліцензіями використовуються повсюдно . Такі GNUTS ( розроблена в GNU ) , Bugzilla ( Mozilla Foundation ) , JitterBug (проект Samba ) або Debian BTS . Більш  ранні версії орієнтуються на електронну пошту , пізніші включають в себе web -інтерфейс. Наприклад , за допомогою Bugzilla організується сайт в Інтернеті , на якому користувач може заповнити  форму повідомлення про помилку . Кожне повідомлення має свій номер , за яким можна потрапити на «  персональну » сторінку даної  помилки , де відображаються всі відбуваються з її приводу події , від первісного повідомлення ( відкриття ) до виправлення ( закриття). При кожній зміні в  стані помилки Bugzilla розсилає всім зацікавленим особам (включаючи , природно , що повідомив  про помилку і займаються даною  програмою розробників ) листи електронною  поштою . Оскільки Bugzilla дозволяє залишати коментарі і прикладати файли , вона є повноцінним засобом для  спілкування користувача з розробником  з приводу помилки в програмі.

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

Щоб полегшити  і автоматизувати процес внесення виправлень , Ларрі Уолл в 1984 році розробив утиліту patch ( « латочка » ) , яка у формалізованому (але добре зрозумілому людині ) вигляді описує операції редагування , які потрібно провести , щоб отримати нову версію тексту. З появою цієї утиліти  користувач , виявити і виправити  помилку в програмі , міг надіслати  автору невелику латочку , за якою автор  міг зрозуміти , які зміни пропонуються , і автоматично « докласти »  їх до свого вихідного тексту. З  появою утиліти patch набагато більше користувачів стало включатися в розробку програм  з доступним початковим текстом , чималу роль і тут зіграла мережу Usenet . Зрештою , даний спосіб виправлення став загальновживаним і применяющимся не тільки до вихідного коду програми , але і безпосередньо до скомпілювати исполнимости кодом у разі закритого ПЗ , а слово « патч » стало прозивним. Патчі ( файли - заплатки з виправленнями ) - обов'язковий атрибут сьогоднішньої розробки будь-яких програм будь-якої складності .