Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Вільне програмне забезпечення


Стильові проблеми

План:


Введення

Стильові проблеми
У цій статті занадто короткий вступ.
Будь ласка, доповніть вступну секцію, коротко розкриває тему статті і узагальнюючу її вміст.

Вільне програмне забезпечення (ВПЗ) - широкий спектр програмних рішень, в яких права користувача ("свободи") на необмежені установку, запуск, а також вільне використання, вивчення, поширення і зміна (вдосконалення) [1] програм захищені юридично авторськими правами за допомогою вільних ліцензій. Зазвичай СПО доступно без будь-якої оплати, але може мати ціну, наприклад, у формі справляння плати за компакт-диски або інші носії. На практиці, для СПО вихідні коди програмного забезпечення повинні бути доступні користувачам, поряд з виконуваними файлами та ліцензіями.

Рух СПО зародилося в 1983 році, коли Річард Столлман сформував ідею про необхідність дати програмну свободу ( англ. software freedom ) Користувачам. У 1985 році заснував Столлман Фонд вільного програмного забезпечення, щоб забезпечити організаційну структуру для просування своєї ідеї.

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


1. Вільні ліцензії

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

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

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


2. Розробка програмного забезпечення як наукове дослідження

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

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

Однак технологія виробництва комп'ютерів розвивалася не менш активно, ніж програмне забезпечення для них. В 1970-ті роки існувала величезна різноманітність різних архітектур обчислювальних машин, розрізнялися також продуктивністю і ціною. Природно, для кожної архітектури доводилося розробляти окремий набір програмного забезпечення. З середини 1970-х у більшості американських університетів для академічних розробок використовувалися комп'ютери архітектури PDP-10, що дозволяло співробітникам різних університетів використовувати розробки один одного на своїх машинах. Співробітники лабораторії штучного інтелекту Массачусетського технологічного інституту (MIT) в кінці 1970-х розробили для PDP-10 власну операційну систему ITS (Incompatible Timesharing System - несумісна система з поділом часу) і дуже великий набір програм для неї. Вихідні тексти написаних в MIT програм були загальнодоступні, співробітники інших університетів користувалися їх вихідними текстами і надсилали їм виправлення, все програмне забезпечення в цих лабораторіях було повністю академічним.


3. Введення обмежень для ПО

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

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

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

Однак комп'ютери розвивалися дуже швидко, і колишні цілком сучасними в 1970-і PDP-10 до початку 1980-х вже застаріли і значно відставали за продуктивністю від більш сучасних машин. Проте ні для однієї з нових архітектур вже не було операційної системи та іншого програмного забезпечення, розробленого виключно в академічному середовищі і за її правилами. Тепер університети повинні були купувати нові комп'ютери з новим програмним забезпеченням і виконувати умови ліцензії, що обмежує їх права на розробку та розповсюдження ПЗ - інакше кажучи, що обмежує можливість наукової моделі розробки та розповсюдження програмного забезпечення.

У цей час в лабораторії штучного інтелекту MIT розроблялися так звані LISP-машини, які вміли на апаратному рівні інтерпретувати мову програмування, схожий на LISP - розвинений і перспективний мова програмування. На LISP ж була написана операційна система для таких машин і все програмне забезпечення для них. На початку 1980-х деякі співробітники лабораторії штучного інтелекту викупили у MIT права на LISP-машини і математичну систему Macsyma і заснували власні комерційні компанії для подальшої розробки в цій галузі. Дуже багато співробітників лабораторії перейшли працювати в ці компанії, після чого всі їхні подальші розробки вже ставали закритими для наукової спільноти. Нові LISP-машини поширювалися з ліцензіями, що забороняють користувачам модифіковані та поширювати вихідні тексти програм. Програми, які раніше для співробітників MIT були аналогом наукових публікацій, стали належить комусь патентованим продуктом.

Річард Столлман, засновник руху вільного ПЗ.

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

Тоді в пошуках однодумців Річард Столлман створює некомерційну організацію " Фонд вільного програмного забезпечення ". Своєю основною метою Фонд ставить збереження програмного забезпечення, процес розробки якого завжди буде гарантовано відкритим, а вихідні тексти завжди доступні. Більш масштабна мета Фонду - розробка операційної системи, цілком складається з відкрито розроблюваного програмного забезпечення. Декларуючи таку мету, Столлман, фактично, хотів повернути представлявшееся йому ідеальним стан, коли в MIT працювали у власній операційній системі для PDP-10.

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

Фонд вільного ПЗ ділить невільне на напіввільне (таке, що відрізняється від вільного лише забороною на комерційне використання) і власницьке ( англ. proprietary ) (Яке не має всіх чотирьох свобод, навіть якщо комерційне використання дозволено).

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


4. Визначення вільного ПЗ

Для того щоб зберегти модель наукового співробітництва між розробниками, необхідно було забезпечити, щоб вихідні тексти програм, написаних розробниками, залишалися доступними для читання і критики всьому науковому співтовариству зі збереженням авторства творів. Для цього Річард Столлман сформулював поняття вільне програмне забезпечення, в якому відбилися принципи відкритої розробки програм в науковому співтоваристві, що склалося в американських університетах в 1970-і роки. Столлман явно сформулював ці принципи, вони ж - критерії вільного програмного забезпечення. Ці критерії обумовлюють ті права, які автори вільних програм передають будь-якому користувачеві:

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

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

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

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


5. Основна громадська ліцензія GNU

Логотип GNU GPLv3

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

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

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

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


6. Спільнота розробників і користувачів

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

6.1. Взаємодопомога

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

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


6.2. Виправлення помилок

У будь-який досить складною програмою неодмінно є помилки і дефекти, кількість яких зазвичай невідомо. Багато великих виробники ПЗ створюють і оплачують роботу відділу контролю якості (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 [6]. В конце концов, данный способ исправления стал общеупотребительным и применяющимся не только к исходному коду программы, но и непосредственно к скомпилированному исполнимому коду в случае закрытого ПО, а слово "патч" стало нарицательным. Патчи (файлы-заплатки с исправлениями) - обязательный атрибут сегодняшней разработки любых программ любой сложности. [7]

Если пользователю программы нехватает в ней какой-то функции, то при должной квалификации он вполне может запрограммировать её сам и включить в исходный текст программы, либо заплатить за это кому‐то ещё. Естественно, ему выгодно, чтобы его дополнение попало в "главный", авторский вариант программы (его называют "upstream") и появлялось во всех последующих версиях: можно точно так же оформить его в виде патча и выслать автору. Этой возможности лишён пользователь несвободной программы, даже если он достаточно квалифицирован. Единственный способ включить в программу нужную ему функцию - обратиться к производителю (если программа проприетарная) с соответствующей просьбой и надеяться, что производитель сочтёт предложенную функцию действительно необходимой.

Чем больше у свободной программы активных пользователей, готовых вносить исправления и дополнения и делиться ими, тем надёжнее работает и быстрее развивается программа. Причём такая свободная модель отслеживания и исправления ошибок для программы, у которой тысячи активных пользователей, может оказаться гораздо более эффективной, чем у любой собственнической программы: ни одна компания не может себе позволить такой огромный штат сотрудников в отделе контроля качества. Поэтому действительно популярная свободная программа может оказаться гораздо надёжнее проприетарных аналогов.

Написать большую программу в одиночку довольно сложно и даже не всегда возможно, особенно если автор занимается этим в свободное от работы время. Большинство современных свободных программ пишется группой разработчиков. Даже если начинал писать программу один человек и она оказалась интересной, к разработке могут присоединиться активные пользователи. Чтобы они могли не только вносить отдельные исправления, но и вообще всю разработку вести совместно, нужны специальные инструменты. Помимо патчей, для организации совместной разработки ПО применяются системы управления версиями. Функции системы контроля версий состоят в том, чтобы организовать доступ к исходным текстам программы для нескольких разработчиков и хранить историю всех изменений в исходных текстах, позволяя объединять и отменять изменения и пр. [8] Самая ранняя свободная система управления версиями - RCS - использовалась ещё на заре свободного ПО абонентами сети Usenet, затем на смену ей пришла более развитая CVS, но сегодня и она считается во многом устаревшей и всё чаще заменяется Subversion, Git и другими.

Нужно заметить, что преимущества свободной разработки для пользователя не следует преувеличивать. Не все свободные программы в равной степени доступны для изменения пользователям, и это совершенно не связано с лицензией на их распространение. Важный фактор здесь - объём программы: если в ней десятки тысяч строк (как, например, в OpenOffice), то даже квалифицированному пользователю потребуется слишком много времени, чтобы разобраться, что к чему. Рассчитывать же на то, что разработчики ответят на все замечания и предложения пользователя немедленным исправлением программы, тоже нельзя, поскольку они не несут перед пользователем никаких обязательств по качеству программы. В этом отношении пользователь проприетарной коммерческой программы может оказаться в лучшем положении (хотя обязательства её разработчика обычно также обусловлены лишь законами, а не его волей).

Очень многие свойства сообщества разработчиков и пользователей свободных программ проистекают из того, что все его участники обычно занимаются этой программой из интереса или потому, что эта программа - необходимый для них инструмент (например, зарабатывания денег или по другой причине). Время, потраченное ими на программу, не оплачивается, поэтому нет никакой надежды, что обстоятельства не переменятся и разработка не прекратится вовсе. Нередки случаи, когда разработка программы начинается благодаря одному автору-энтузиасту, который привлекает многих к участию в разработке, а потом энтузиазм лидера гаснет, а вместе с ним затухает и разработка. К сожалению, сегодня существуют тысячи свободных программ, так никогда и не достигших версии 1.0, хотя "выгорание" лидеров и не единственная этому причина. Кроме того, программа может быть необходимой, но "неинтересной", а потому не найдётся и свободных разработчиков. [9]

Место свободных программ на сегодняшнем рынке ПО очень значительно, и многие коммерческие и государственные предприятия используют свободное ПО прямо или опосредованно. Собственно, опосредованно все пользователи Интернета задействуют, например, свободную программу BIND, предоставляющую службу DNS. Многие организации, особенно предоставляющие услуги через Интернет, используют свободный web-сервер Apache, от работы которого непосредственно зависит их прибыль, не говоря уже о серверах на платформе Linux. Главный недостаток с точки зрения коммерческого пользователя: разработчики свободных программ не несут никаких обязательств по качеству программы, кроме моральных. Поэтому, сегодня большие корпорации, например, Intel или IBM, находят необходимым поддерживать проекты по разработке свободного ПО, оплачивая сотрудников, которые работают в рамках этих проектов.


7. Філософія

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

Через зазначеного відмінності для ПЗ не діє принцип "користуватися річчю одночасно може тільки одна людина" (і використання її кимось іншим автоматично завдає першого збитків через неотримання блага від неї), унаслідок якого й існує поняття "господар". Тому спроба і тут діяти за цим принципом - закріплювати право використання програми за одним якимось чоловіком - інтуїтивно сприймається [10] як суперечить природі речей. Не дивно, що виникає безліч негараздів, кожну з яких припадає вирішувати штучними, а часто і протиприродними методами.

Класичним таким методом є де-юре збереження прав на ПЗ за виробником, який ніби дає ПО своїм користувачам у тимчасове користування. У цьому випадку використання неліцензійного ПЗ по суті прирівнюється до концепції права англомовних країн, відомої як theft of services. Але ця концепція не має аналогів в інших національних культурах, наприклад, російської, і саме з причин, наведеним на 2 абзацу вище (господар не позбавляється можливості використання речі, що і є головне негативний наслідок крадіжки). У російському праві theft of services будь-яких видів є не більше ніж адміністративне правопорушення, при цьому за неліцензійне ПЗ передбачена кримінальна відповідальність, що звучить дисонансом у російській культурі.

Але іноді, наприклад, доводиться симулювати "збиток через неотримання блага", який "наноситься" "хазяїна" програми при її безущербном копіювання або повернення грошей при виявленні помилок і дефектів в програмах. Зазвичай це - "упущена вигода", тобто та прибуток, який господар міг би отримати, але не отримав через те, що продукт скопіювали. Доводиться винаходити хитромудру апаратуру, що заважає копіювання або заподіює при цьому збиток. Доводиться вводити в законодавство особливу категорію прав - умовно назвемо її "патент" [11] - обмежує зловживання - і свободу - всього людства на користь господаря патенту. Причому далеко не завжди господар патенту та автор винаходу - один і той же чоловік (у таких випадках протиприродність даних заходів лише посилюється).

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

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


8. Міграція на вільне ПЗ

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

9. Поширеність вільного і відкритого ПЗ

Чи не спеціалізуються на комп'ютерній тематиці ЗМІ, як правило, ототожнюють відкрите і вільне ПЗ, використовують їх як синоніми. Тому дані по поширеності відкритого і вільного ПЗ зазвичай наводяться разом.

СПО активно використовується в Інтернеті. Наприклад, найпоширеніший веб-сервер Apache є вільним, Вікіпедія працює на MediaWiki, також є вільним проектом.

СПО використовується в Міністерстві юстиції Бельгії, в якому вже половина комп'ютерів працює під управлінням Linux, і поліцією Франції, яка до 2014 планує повністю перейти на Ubuntu Linux. Про перехід на програмне забезпечення з відкритим вихідним кодом оголосило також Патентне відомство Нідерландів. Перевести всі комп'ютери цієї установи на вільне ПЗ планується до кінця 2009. Адміністрація Амстердама також вивчає можливість переведення своїх 10 тисяч робочих місць на відкрите ПЗ. [ ]

Програма переходу на СПО була успішно реалізована в Мюнхені. Аналогічна програма мала місце в Берліні, але згодом було прийнято рішення використовувати гібридну інфраструктуру з комерційного та вільного програмного забезпечення. [12]

По состоянию на 2009 год, открытым системам уже принадлежит большая часть (более 60 %) рынка мобильных приложений. По прогнозу Juniper Research, к 2014 году количество смартфонов с открытыми ОС возрастет в 2 раза (с 106 до 223 миллионов). [13]


9.1. Свободное программное обеспечение в России

Свободное программное обеспечение, в любом случае, может свободно устанавливаться и использоваться на любых компьютерах. Использование такого ПО свободно везде: в школах, офисах, вузах, на личных компьютерах и во всех организациях и учреждениях, в том числе, и на коммерческих и государственных, в России и в странах СНД.

Уряд РФ распоряжением от 17 декабря 2010 г. № 2299-р утвердило план перехода федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование свободного программного обеспечения на 2011-2015 годы. [14]

В учреждения Министерства Обороны России, а также в российских посольствах в других странах используется операционная система МСВС. Данная ОС, сделанная на основе Red Hat Linux с незначительными изменениями, не является свободным ПО, её исходные коды закрыты, а единственным владельцем прав в нарушение GNU GPL объявлен ВНИИНС (упоминания о предыдущих разработчиках также убраны, хотя такое упоминание является обязательным требованием в лицензии).


9.1.1. Свободное программное обеспечение в школах

В трёх регионах России в 2008 году развёрнуты эксперименты по внедрению и использованию в средних школах базовых пакетов программ для кабинетов информатики и вычислительной техники, и начата подготовка учителей и преподавателей информатики к работе со свободным программным обеспечением в среде Windows и Linux. [15]

9.2. Сдерживающие факторы распространения

Пользователи, которые бы иначе предпочли свободное ПО несвободному, продолжают использовать несвободное по следующим причинам [ источник не указан 938 дней ] :

  • В странах, где неавторизованное распространение объектов авторского права является обычным делом, нет ни юридического, ни экономического стимула переходить на свободное ПО. К тому же пользователи, привыкшие к проприетарному ПО, не хотят тратить время на изучение свободного аналога, если это не даёт им прямой выгоды в короткий срок.
  • В некоторых отраслях мало или вообще нет свободного ПО высокого качества. [16] А именно:
    • Программное обеспечение, в котором доля работы программиста мала по сравнению с работой художника, редактора и т. д. Например: квесты и многие другие жанры игр, электронные словари.
    • Развивающиеся отрасли, для которых мало пригодных к использованию общепринятых алгоритмов, - машинный перевод, распознавание речи с большим словарём и, в меньшей степени, синтез речи. Кроме того, требуется ручная обработка большого количества текстовых или аудиоданных.
    • Отрасли, связанные со сложной высокооплачиваемой работой (фотообработка, инженерное проектирование), - так как создать программу, близкую по сложности и качеству к собственническим стандартам де‐факто очень трудно, то свободных аналогов меньше, чем в других отраслях, и пользователю не всегда удаётся найти подходящий для него продукт.
    • Отрасли, в которых существуют платные или собственнические стандарты де-факто, например Pantone в допечатной подготовке.
    • Для аппаратного обеспечения в отраслях, где господствует лишь несколько производителей, в свободном доступе часто отсутствуют не только драйверы, но и спецификации.
  • Разнообразие лицензий тоже может иметь отрицательное влияние. Пример (не очень удачный): драйвер файловой системы ZFS выпущен под лицензией, несовместимой с GNU GPL 2, и потому долгое время мог быть использован на самой популярной платформе для СПО - Linux - только посредством FUSE, приводившему к сильному замедлению производительности этой ФС. Однако вскоре вышла и реализация ZFS в виде модуля ядра для Linux (то есть полноценно), единственным условием использования которого является недопустимость их совместного(слитного) распространения. [17]
  • Проприетарное ПО настолько популярно, что пользователи не знают о существовании других подобных программ.
  • Проприетарное ПО зачастую использует собственные форматы файлов и протоколы обмена, описание которых отсутствует в свободном доступе. Поэтому переход может быть затруднён проблемами совместимости с другим ПО или с существующими форматами файлов (вариант замыкания на поставщике).
  • Деякий пропрієтарне ПЗ як вимагає величезних фінансових витрат на створення і підтримання в потрібному якості, так і або надзвичайно складно, або містить велику кількість різних патентів з інших джерел, наприклад драйвери відеоприскорювачів. У свою чергу, через стартової, малої відсоткової поширеності відкритого рішення, компанія-виробник не здатна істотно підвищити фінансування, а значить, надати якісну підтримку цій галузі. Як результат, кількість ПЗ, яке користується і вимагає якісних драйверів, невелика - що, відповідно, стримує поширеність відкритих рішень. У зв'язку з тим, драйвера для відеоприскорювачів під Linux, хоч і надаються всіма великими компаніями, але є або повністю закритими і менш ефективними, ніж їх варіанти під Windows, або відкритими, але свідомо створюються менш продуктивними і функціональними. [18].

Примітки

  1. Що таке вільне програмне забезпечення? - Проект GNU - Фонд вільного програмного забезпечення (FSF) - www.gnu.org / philosophy / free-sw.ru.html
  2. Richard Stallman. Why "Open Source" misses the point of Free Software - www.gnu.org / philosophy / open-source-misses-the-point.html (Англ.) (1 березня 2009). Фотогалерея - www.webcitation.org/617AgTHsx з першоджерела 22 серпня 2011.
  3. Сайт компанії UniPress - www.unipress.com
  4. Що таке copyleft? - www.gnu.org / copyleft / copyleft.ru.html. Free Software Foundation (26 серпня 2008). Фотогалерея - www.webcitation.org/617AgxPdg з першоджерела 22 серпня 2011.
  5. У суспільному ліцензії GNU є навіть стандартне формулювання, що закріплює відсутність гарантій: "Справжня програма поставляється на умовах" як є ". Якщо інше не зазначено в письмовій формі, автор і / або іншої правовласник не бере на себе жодних гарантійних зобов'язань, як явно виражених, так і маються на увазі, щодо програми, у тому числі ГАРАНТІЯМИ стану при продажу та придатності для використання в конкретних цілях, а також будь-які інші гарантії ". (Переклад Олени Тяпкіна).
  6. Див статтю про це - tim.oreilly.com/articles/paradigmshift_0504.html Тіма О'Рейлі.
  7. Досить згадати таку складну систему, як Windows, з десятками мегабайт исполнимого коду і не має вільно розповсюджуваних вихідних текстів, щоб зрозуміти масштаби і складність сучасних патчів.
  8. Хорошим і зрозумілим непрограмістів прикладом системи управління версіями, що цікаво, є Вікіпедія.
  9. Аналогічно, у цих абзацах можна провести паралелі між вільним ПЗ і Вікіпедією. Учасники займаються написанням статей у вільний час і з інтересу; користувач, який помітив помилку, може її виправити; існує безліч статей, не розвилися до докладних, і т. д.
  10. Lawrence Lessig. How Big Media uses technology and the law to lock down culture and control creativity - www.piratpartiet.se/node/349 (Англ.) (1 травня 2010). Фотогалерея - www.webcitation.org/617AhQtLX з першоджерела 22 серпня 2011.
  11. Умовно - тому, що далеко не у всіх країнах [ уточнити ] дозволено видавати патенти на програмне забезпечення, проте, скрізь відносини власності на вихідні тексти програм регулюються загальними або спеціальними розділами законів про авторське право.
  12. 20 Jahre Linux - Freie Software fr Jedermann? - www.ardmediathek.de/ard/servlet/content/3517136?documentId=8212640 (Нім.) . Bayerisches Rundfunk (15.09.2011).
  13. Відкрите ПЗ завойовує мобільний ринок - www.astera.ru/news/?id=69958. @ Astera (3 липня 2009).
  14. Держоргани перейдуть на вільне програмне забезпечення - minsvyaz.ru / ru / news / index.php? id_4 = 41934
  15. * Прес-служба Міністерства освіти і науки Республіки Хакасія Вони на "ТИ" з вітчизняним Linux - www.edurh.ru/press/news/395.html. Проект "Освіта" (16.11.2009). (Недоступна посилання)
  16. High Priority Free Software Projects - www.fsf.org/campaigns/priority-projects/. Free Software Foundation, Inc .. архіві - www.webcitation.org/617AkiBI9 з першоджерела 22 серпня 2011. - Список вільних проектів, яким потрібна допомога в розробці або використання і реклама.
  17. [Phoronix] ZFS For Linux Is Now Available To The Public! - www.phoronix.com/scan.php?page=news_item&px=ODgyNA
  18. [Phoronix] Is Windows 7 Actually Faster Than Ubuntu 10.04? - www.phoronix.com/vr.php?view=14887

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Вільне і відкрите програмне забезпечення
Програмне забезпечення
Програмне забезпечення
Кроссплатформенной програмне забезпечення
Документація на програмне забезпечення
Пропрієтарне програмне забезпечення
Реліз (програмне забезпечення)
Ліцензія на програмне забезпечення
Прикладне програмне забезпечення
© Усі права захищені
написати до нас
Рейтинг@Mail.ru