Для того, щоб програма вважалася частиною проекту GNU, вона повинна бути явно включена до цього проекту. Для цього потрібна згода і розробників програмного продукту і представників проекту GNU. Якщо Ви хочете долучити свою програму до проекту GNU -- пишіть на <maintainers@gnu.org>.

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

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

Але якщо Ви якимось чином розповсюджуєте модифіковану версію, GPL вимагає надавати користувачам і модифіковані вихідні тексти під ліцензією GPL.

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

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

Незалежно від того, чи хочете Ви мати копірайт на ваші зміни чи ні, модифікована версія GPL програми повинна поширюватися вцілому під GPL.

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

Ви також можете надати ваші зміни замовнику на умовах ліцензії GPL, але погодитися не поширювати їх, поки замовник не дозволить цього. Це також не буде порушенням GPL, оскільки в такій ситуації нема факту поширення GPL коду із якимись додатковими обмеженнями.

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

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

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

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

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

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

      Однак, як спеціальний випадок, від поширюваного вихідного тексту, 

      містити ніяких кодів компонент, що розповсюджуються (вихідними

      текстами або двійковим кодом) звичайним чином (частини

      компілятора, ядра, та ін.) з операційною системою, на якій

      виконується дана програма, окрім випадку, коли така компонента

      сама є супутньою частиною програми.

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

Якщо Ви хочете зв'язати вашу програму з бібліотекою, яка не підпадає під це правило, то Ви повинні додати своє власне доповнення до ліцензії на вашу програму як додаток до GPL. Наступне доповнення до ліцензії дає дозвіл на використання бібліотеки FOO при компілюванні вашої програми:

  Copyright (C) рік <ім'я автора>


  Ця програма -- вільне програмне забезпечення. Ви можете розповсюджувати

  її та/або вносити зміни відповідно до умов Загальної Публічної

  Ліцензії GNU у тому вигляді, у якому вона була опублікована Фундацією

  Вільного Програмного Забезпечення, 2ї версії Ліцензії, або (на Ваш

  розсуд) будь-якої більш пізньої версії.


  Ця програма розповсюджується із сподіванням, що вона виявиться

  корисною, але БЕЗ БУДЬ-ЯКОЇ навіть УЯВНОЇ ҐАРАНТІЇ

  КОМЕРЦІЙНОЇ ПРИДАТНОСТІ чи ВІДПОВІДНОСТІ БУДЬ-ЯКОМУ ПЕВНОМУ

  ЗАСТОСУВАННЮ. Зверніться до Загальної Публічної Ліцензії GNU за

  подробицями.


  Ви мали отримати копію Загальної Публічної Ліцензії GNU разом з цією

  програмою. Якщо Ви не отримали копії ліцензії, напишіть за адресою

  Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,

  MA 02111-1307, USA.


  Додатково, як особливий виняток, <ім'я автора> дає дозвіл на

  зв'язування коду цієї програми з кодом бібліотеки FOO 

  (або зі зміненими версіями FOO, якщо вони використовують таку ж ліцензію 

  як FOO), і поширення утвореної комбінації цих двох складових. Ви повинні 

  дотримуватися вимог ліцензії GNU General Public License у всьому іншому,

  що не стосується бібліотеки FOO. Якщо Ви модифікуєте цей файл, то

  Ви маєте також право розширити рамки доповнення чи переписати його,

  хоча робити це і не обов'язково. При бажанні Ви можете навіть вилучити 

  це доповнення взагалі у своїй версії, якщо бібліотека FOO більше не буде 

  потрібною, або Ви хочете заборонити під'єднання бібліотеки FOO до своєї

  версії програми.

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

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

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

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

Якщо програму вже написано з використанням не вільної бібліотеки, то цілком можливо, що вже надто пізно щось міняти. Можливо, краще випустити програму як є, ніж не випускати її взагалі, але не забудьте вказати в README, про те, що для цієї програми необхідна пропрієтарна бібліотека це недолік і наголосіть, що було б непогано змінити програму так, щоб вона робила те ж саме, але без використання не вільних бібліотек.

Крім того, напишіть нам (<tasks@gnu.org>) про не вільну бібліотеку, що Ви використали і яку роль вона відіграє у вашій програмі. Ми можемо посприяти щоб хтось написав вільну бібліотеку, яка робитиме те, що Вам треба.

Однак, реєстрування авторського права в США є дуже хорошою ідеєю. Реєстрація є вагомим аргументом при розв'язуванні спірних питань.

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

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

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

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

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

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

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

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

Зверніть увагу на те, що юридичні поняття можуть дуже відрізнятися у різних країнах.

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

Якщо урядова установа використовує субпідрядників для виконання роботи, то і самі вдосконалення можуть бути випущені під GPL.

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

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

Але Ви можете дозволяти ще й додаткові способи використання вашого коду. Наприклад поширювати код під менш строгою ліцензією у порівнянні з GPL. Але ця ліцензія повинна бути сумісною з GPL. Неповний список ліцензій можна знайти на сайті GNU.

Однак часто буває, що інтерпретатор надає додаткові засоби (не обов'язково бібліотеки), використання яких фактично полягає у лінкуванні коду програми з частинами коду інтерпретатора. У таких випадках, якщо код, до якого лінкується програма, поширюється згідно з ліцензією GPL, то і сама програма повинна поширюватися згідно з ліцензією, сумісною з GPL. Прикладом такого засобу є JNI або Java Native Interface. Бібліотеки, доступ до яких здійснюється таким чином, фактично динамічно під'єднуються до Java програм.

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

    Ви не маєте права висувати 
    жодних додаткових обмежень прав викладених тут. 

Вимога щодо анонсів просто накладає додаткове обмеження і тому є несумісною з GPL.

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

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

Межовим випадком застосування цього правила є варіант, при якому програма динамічно під'єднує плагін, але весь зв'язок з ним зводиться до виклику якоїсь "головної" функції (наприклад `main') і очікування, поки вона не завершиться.

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

Для додаткової інформації прочитайте відповідь на питання "Я пишу вільні програми, використовуючи не вільні бібліотеки..."

Ви завжди маєте законну альтернативу не використовувати наш код.

  Приєднання модуля FOO статично чи динамічно до інших модулів насправді є

  створенням скомбінованої роботи. Таким чином, умови Загальної

  Публічної Ліцензії GNU поширюються на всю комбінацію вцілому.


  Як особливий виняток, власник авторського права на FOO дає Вам

  дозвіл приєднувати FOO до незалежних модулів, які підтримують зв'язок з

  FOO виключно через інтерфейс FOOBAR, незалежно від типу ліцензії,

  під якою ці модулі поширюються, і поширювати утворену скомбіновану

  роботу будь-яким способом за вашим вибором, при умові, що

  кожна копія скомбінованої роботи буде супроводжуватися повною копією

  вихідних текстів FOO (тої версії, яка була використана при створенні

  скомбінованої роботи), яка надаватиметься згідно з Загальною

  Публічною Ліцензією GNU із збереженням тексту цього дозволу. Незалежний

  модуль -- це модуль, який не є похідним від модуля FOO.


  Зверніть увагу -- той, хто вносить зміни до модуля FOO не зобов'язаний

  надавати цей особливий дозвіл для своєї модифікованої версії, а робить це

  на свій розсуд. Загальна Публічна Ліцензія GNU дає право випускати 

  модифіковані версії не даючи такого виняткового дозволу, лише наявність

  такого дозволу в оригінальній програмі дає право давати такий дозвіл 

  також і для модифікованих версій.

• Для того, щоб працювати, моя програма приєднує бібліотеку FOO, яка розповсюджується під Lesser GPL.
• Моя програма виконує системний виклик з командною стрічкою, яку я побудував, і запускає програму BAR, ліцензія якої: "GPL із спеціальним винятком, що дозволяє лінкувати цю програму з модулем QUUX".

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

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

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

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

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

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

Якщо Ви захочете відстоювати умови GPL для своєї програми особисто, то, можливо, Вам слід також скористатися цим підходом. Напишіть на <licensing@gnu.org>, якщо Вас цікавить детальніша інформація.

Якщо Ви все ж хочете використати нашу преамбулу в модифікованій ліцензії, напишіть нам про це на <licensing@gnu.org>. Якщо умови вашої ліцензії відповідатимуть нашим вимогам, ми дамо на це дозвіл.

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

Виконання цих вимог -- це єдине, що треба зробити, щоб мати право включити код GPL-програми до своєї власної програми.

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

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

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

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

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

Якщо хтось хоче поширювати GPL програму, називаючи її "частиною" системи, про яку відомо, що там є як пропрієтарні, так і вільні складові, в користувача можуть виникати сумніви щодо своїх прав на ту чи іншу складову. Тому користувач повинен мати можливість чітко розрізнити вільні складові і пропрієтарні.

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

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

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

Якщо ліцензія модуля Q дозволяє такі речі, то така ліцензія є сумісною з GPL. Якщо ні -- вона є несумісною з GPL.

Якщо ліцензія модуля Q однозначно стверджує, що якщо Ви поширюєте Q саму по собі, Ви зобов'язані робити щось таке, що суперечить GPL, то це означає, що Ви не маєте права поширювати Q під GPL. Тобто Ви не зможете поширювати P+Q під GPL, а, отже, не маєте права лінкувати чи якимось іншим чином поєднувати P та Q.

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

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

Звичайно ж найпростіший варіант -- це просто завжди надавати вихідні тексти разом із двійковим кодом програми.

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

Частиною ідеї вільного програмного забезпечення є надання користувачам доступу до вихідних текстів *програм, які вони використовують*. Ті, хто використовують вашу версію, повинні мати доступ до вихідних текстів вашої версії програми.

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

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

Отже, разом з двійковими файлами, Вам необхідно надавати крім списку змін ще й повні вихідні тексти програми.

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

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

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

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

При потребі Ви можете використати Affero GPL для програм, призначених для роботи на сервері.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тому на даний момент ми не визнаємо офіційно переклади GPL як такі, що є правильними чи як такі, що до чогось зобов'язують. Замість цього ми робимо дві речі:

• Відсилаємо людей до неофіційних перекладів.

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

  Невизнаний офіційно переклад не має юридичної сили і повинен містити наступний текст:

     This translation of the GPL is informal, and not officially approved
  
     by the Free Software Foundation as valid.  To be completely sure of
  
     what is permitted, refer the original GPL (in English).
  

     Цей переклад GPL не є формальним і не є офіційно затвердженим
  
     Фундацією Вільного Програмного забезпечення як такий, що має
  
     юридичну силу.  Для того, щоб бути впевненим що є дозволеним,
  
     зверніться до оригіналу GPL (англійською мовою).
  

  Незатверджений переклад може допомогти зрозуміти англійський текст GPL. Це може допомогти багатьом користувачам.

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

• Публікуємо переклади, які можуть використовуватися в єдиній країні.

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

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

1. Якщо Ви написали код і поширюєте його під GPL, Ви можете дозволити як виняток, використовувати ці конкретні можливості, несумісні з GPL.

2. Якщо Ви написали програму і випустили її під GPL, і ваша програма спеціально спроектована для використання таких можливостей, користувачі можуть сприймати це як неявний дозвіл до використання цих можливостей. Але якщо саме це Ви мали на увазі -- краще сказати про це явно.

3. Ви не маєте права взяти чужий GPL код і використовувати його таким чином, чи дозволяти для нього винятки такого роду. Тільки власник авторського права може дозволяти такі винятки.

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

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

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

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

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

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

Copyright (C) 2001 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Translation Copyright (C) 2003 Maryan Rachynskyy

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Відтворення і поширення цього документа вцілому будь-яким способом дозволяється при умові збереження цього зауваження.