Історія open source software: від GPL до SSPL

Що таке open source software і звідки воно походить

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

Це коротка версія. Розгорнута важлива, оскільки програмне забезпечення, яке ви запускаєте на сервері сьогодні, досі зберігає наслідки тих рішень. Деякі з них ухвалили у 1983 році. Інші ухвалили минулого року, і саме тому деякі застосунки в наших посібниках із self-hosting тепер доступні у двох версіях із різними назвами.

Програмним забезпеченням обмінювалися ще до того, як його почали продавати

У 1950-х і 1960-х роках програмне забезпечення постачалося разом із машиною. IBM постачала вихідний код разом зі своїми системами, а користувацькі групи, зокрема SHARE, заснована в 1955 році, обмінювалися програмами на магнітній стрічці. Це припинили дві події. У 1969 році IBM оголосила, що встановлюватиме окрему ціну на програмне забезпечення та апаратне забезпечення. Так сформувався окремий ринок програмного забезпечення. Потім законодавство наздогнало ці зміни. Computer Software Copyright Act of 1980 підтвердив, що програми є об’єктами авторського права у Сполучених Штатах. Після 1980 року код, написаний не вами, за замовчуванням вважався закритим, тому для його поширення потрібен був письмовий дозвіл автора.

Клуб любителів комп’ютерів Homebrew і відкритий лист до любителів

Клуб любителів комп’ютерів Homebrew провів першу зустріч у березні 1975 року в гаражі в Менло-Парку, штат Каліфорнія. Учасники приносили апаратне забезпечення та перфострічки, а копіювання було частиною зустрічі. Altair BASIC, написаний Bill Gates і Paul Allen, передавався кімнатою на скопійованій стрічці. У лютому 1976 року Gates відповів у бюлетені клубу текстом «Відкритий лист до любителів».

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

Він написав, що менше ніж один із десяти власників Altair заплатив за BASIC, а час роботи комп’ютера, витрачений на його написання, коштував понад 40,000 доларів. У цьому листі вже міститься вся сучасна дискусія. Копіювання програмного забезпечення нічого не коштує та допомагає кожному, хто його копіює. Але на його написання хтось усе одно витратив рік свого життя. Кожна ліцензія, описана нижче, є спробою одночасно врахувати обидва ці факти.

GNU у 1983 році та GPL як юридичний винахід

Richard Stallman оголосив про GNU у вересні 1983 року в Usenet — мережі newsgroup, якою користувалися до появи web. GNU розшифровується як "GNU's Not Unix". План передбачав повну Unix-сумісну систему, яку кожен міг би копіювати та змінювати.

Free Unix! Починаючи з цього Дня подяки, я збираюся написати повну Unix-сумісну програмну систему під назвою GNU (від Gnu's Not Unix) і безкоштовно передати її всім, хто зможе нею користуватися.

У 1985 році з’явилася Free Software Foundation (FSF). Її Free Software Definition визначає чотири свободи, нумерація яких починається з нуля: запускати програму з будь-якою метою, вивчати та змінювати її, розповсюджувати копії та розповсюджувати власні змінені версії. Свобода 1 вимагає вихідного коду, оскільки практично неможливо вивчати двійковий файл. Тут "free" означає свободу, а не відсутність ціни. Власне формулювання FSF — free as in free speech, not free beer.

Маніфест не був винаходом. Ним стала ліцензія. GNU General Public License (GPL) використовує copyright, щоб вимагати спільного розповсюдження, а не забороняти його. Ви отримуєте чотири свободи за однієї умови: кожен, кому ви передасте програмне забезпечення, також отримає ці свободи разом із вихідним кодом. Stallman назвав це copyleft. Спочатку така ліцензія постачалася з GNU Emacs у 1985 році, у 1989 році стала GPL version 1, а в червні 1991 року — version 2.

GPL працює, оскільки спирається на copyright law, а не протистоїть йому. Без ліцензії ви взагалі не маєте права розповсюджувати чужий код. GPL надає це право та встановлює умови його використання. Тому vendor, який постачає змінений GPL-код усередині маршрутизатора та відмовляється надати вихідний код, не просто порушує обіцянку. Він порушує copyright, і власник авторських прав може звернутися до суду. Саме тому правозастосування взагалі можливе: від справ gpl-violations.org Harald Welte у 2000-х роках до позову Software Freedom Conservancy проти Vizio, поданого у 2021 році. У ньому стверджується, що особа, яка придбала телевізор, також може вимагати вихідний код.

Linux завершив систему

До 1991 року проєкт GNU уже мав компілятор, бібліотеку C, командну оболонку та більшість інструментів. Працездатного ядра не було, оскільки власне ядро GNU, Hurd, розробляли значно довше, ніж планували. У серпні 1991 року студент із Гельсінкі опублікував у ньюзгрупі comp.os.minix:

Я розробляю безкоштовну операційну систему (це лише хобі, вона не буде великою та професійною, як gnu) для клонів AT 386(486).

Linux 0.01 вийшов у вересні 1991 року за ліцензією, яку Linus Torvalds написав сам. Вона забороняла продавати систему. На початку 1992 року він замінив її на GPLv2 і відтоді казав, що це було одним із його найкращих рішень. Саме ліцензія зробила внески компаній безпечними: компанія могла залучити інженерів до розробки ядра, знаючи, що конкурент не зможе привласнити ці вдосконалення.

Безкоштовна Unix уже існувала в Berkeley. Linux, а не BSD (Berkeley Software Distribution), стала основною безкоштовною Unix частково через судовий процес. Unix System Laboratories подала позов проти Berkeley Software Design у 1992 році, і справа тривала до початку 1994 року. Протягом цих двох років BSD-системи несли юридичні ризики, а Linux — ні. Саме тоді з’явилися користувачі. FSF просить називати об’єднану систему GNU/Linux, оскільки Linux є ядром, а більшість супутніх інструментів походить із GNU. Більшість людей кажуть Linux. Обидві назви позначають той самий набір програмного забезпечення.

1998: ребрендинг open source і розкол, який так і не вдалося подолати

У січні 1998 року Netscape оголосила, що опублікує вихідний код свого браузера. Це була найбільша на той час компанія, яка пішла на такий крок, і він виявив практичну проблему. Англійською вислів "free software" читається як "програмне забезпечення, яке нічого не коштує", і керівники почули саме це. У лютому 1998 року в Palo Alto зібралася група, щоб знайти кращий термін, і Christine Peterson запропонувала назву "open source". Протягом кількох тижнів Eric Raymond і Bruce Perens заснували Open Source Initiative (OSI). Організація ухвалила Open Source Definition, адаптоване з Debian Free Software Guidelines, які Perens написав у 1997 році.

Open Source Definition містить десять критеріїв. Два з них визначають більшість сучасних суперечок: вихідний код має бути доступним, а ліцензія не повинна обмежувати, хто може використовувати програму або для чого її можна використовувати. Ліцензія з формулюванням "ви не можете пропонувати це як комерційний сервіс" не відповідає цьому критерію, незалежно від інших дозволів. Запам’ятайте це речення. Саме цю межу перетинають сучасні ліцензії з доступним вихідним кодом.

Розкол, що виник у 1998 році, стосується причин, а не того, які ліцензії є прийнятними. Позиція FSF має етичне обґрунтування: користувач, який не може змінювати програму, не контролює власний комп’ютер. Позиція OSI, яку Raymond пояснював бізнесу в есе "The Cathedral and the Bazaar", є практичною: відкрита розробка створює краще програмне забезпечення, і компанія може використовувати це на практиці. Відповідь Stallman, "Why Open Source Misses the Point of Free Software", досі опублікована на gnu.org, і він ніколи не приймав новішого терміна. Perens, який допомагав його створити, у 1999 році вийшов із ради OSI, заявивши, що рух відійшов від вільного програмного забезпечення.

Важливо точно розуміти, наскільки малою є практична різниця. Перелік вільних ліцензій FSF і перелік схвалених ліцензій OSI майже повністю збігаються, зокрема щодо GPL, MIT, Apache 2.0 і BSD. Автори, яким потрібно одночасно передати обидва значення, використовують FOSS (free and open source software) або FLOSS (free/libre and open source software).

Як компанії навчилися випускати код

Лістинг акцій Red Hat на біржі у 1999 році показав, що гроші можна заробляти на підтримці та пакуванні, а не на продажу копій. У 2001 році IBM зобов’язалася інвестувати в Linux один мільярд доларів. У 2001 році генеральний директор Microsoft назвав Linux «раком». У 2016 році та сама компанія приєдналася до Linux Foundation як платиновий учасник, а в 2018 році придбала GitHub за 7.5 мільярда доларів у вигляді акцій. У 2019 році IBM придбала Red Hat за 34 мільярди доларів. Усе це не було зміною ставлення до ліцензій. Змінилося місце, де зосереджені гроші. Коли операційна система є спільними витратами, підтримувати власну систему дорого, і кожен постачальник воліє конкурувати на рівні над нею.

Корпоративне володіння має і зворотний бік. Коли Oracle придбала Sun у 2010 році, вона отримала MySQL і OpenOffice.org, і обидві спільноти залишили проєкти. MariaDB виникла на основі MySQL, а LibreOffice було відгалужено від OpenOffice.org у вересні 2010 року. Fork — це єдиний справжній голос, який має спільнота користувачів, а ліцензія робить такий вибір можливим.

Чому в деяких self-hosted застосунків з’явилися форки

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

• MongoDB перейшла на Server Side Public License (SSPL) у жовтні 2018 року. SSPL передбачає: якщо ви надаєте програмне забезпечення іншим як сервіс, потрібно опублікувати вихідний код усього, що використовується для надання цього сервісу. OSI не визнала цю ліцензію open source, і MongoDB відкликала її з розгляду у 2019 році.
• Redis додала обмеження використання для деяких модулів у 2018 і 2019 роках, а в березні 2024 року перевела основний сервер на подвійні source-available умови у версії 7.4. Через кілька днів з’явився форк останнього релізу під BSD-ліцензією — Valkey. Проєкт розвивається під егідою Linux Foundation за підтримки Amazon, Google, Oracle та інших компаній. У травні 2025 року Redis додала Affero General Public License version 3 (AGPLv3), схвалену OSI, як третій варіант ліцензії для Redis 8.
• У січні 2021 року Elastic перевела Elasticsearch і Kibana з Apache 2.0 на подвійні умови SSPL та Elastic License. Amazon створила форк OpenSearch. У серпні 2024 року Elastic додала AGPLv3 як третій варіант, а у вересні 2024 року OpenSearch передали під управління Linux Foundation як OpenSearch Software Foundation.
• У серпні 2023 року HashiCorp перевела Terraform та інші свої інструменти на Business Source License (BUSL). BUSL не є open source-ліцензією, доки діє, оскільки забороняє конкуруюче використання у production. Кожен реліз переходить на open license у визначену дату: для Terraform це відбувається через чотири роки. Протягом кількох тижнів з’явився форк OpenTofu, який тепер також розвивається під егідою Linux Foundation.

У кожної сторони є обґрунтована позиція, і жодна з них не діє недобросовісно. Компанія, яка виплачує п’ятдесят зарплат, тоді як значно більша компанія перепродає її роботу, має проблему, яку не вирішити доброю волею. Користувач, який побудував рішення на умовах Apache 2.0, а потім виявив, що вони змінилися, також має проблему. До того ж його ніхто не запитував заздалегідь. Зверніть увагу на подальші події у двох із цих випадків. Після того як форки набули поширення, Elastic і Redis знову додали сильний copyleft. Copyleft відповів на початкову претензію, оскільки AGPLv3 вимагає від постачальника сервісу опублікувати зміни, які він використовує. Станом на серпень 2026 року обидва проєкти та обидва форки залишаються активними. Саме такий результат і мали забезпечити ці ліцензії.

Хто має право змінити ліцензію

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

У Linux немає CLA. Внески надходять за GPLv2 із Developer Certificate of Origin, а авторські права розподілені між тисячами людей і компаній. Ніхто не може змінити ліцензію Linux, оскільки ніхто не зміг би зібрати всі ці підписи. Такий самий захист має будь-який проєкт із багатьма незалежними власниками авторських прав. Це надійніший захист, ніж обіцянка, оскільки він ґрунтується на факті: кому що належить.

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

Що насправді дає foundation

Foundation зберігає активи та визначає правила ухвалення рішень. Apache Software Foundation, Linux Foundation, Cloud Native Computing Foundation у її складі та Software Freedom Conservancy виконують цю роботу кожна у своєму форматі. Foundation не стає нейтральною автоматично. Учасники платять за свої місця, а більшість людей, які працюють повний робочий день над великим проєктом foundation, отримують зарплату від компаній-учасників. Ви отримуєте дещо вужчі, але все одно дуже важливі гарантії: торгова марка та процес випуску релізів не належать одному постачальнику, тому жодна окрема компанія не може зробити проєкт приватним.

Торгова марка — це частина, яку часто не враховують. Код ліцензується. Назва є торговою маркою, а торгова марка не регулюється ліцензією на код. Ви завжди можете створити fork коду. Але зазвичай ви не можете зберегти назву. Саме тому fork-и в цій історії називаються Valkey, OpenSearch, OpenTofu та Forgejo.

Проблема супроводу

Сучасна інфраструктура значною мірою залежить від проєктів, які супроводжують один або два неоплачувані мейнтейнери. Саме збої роблять це очевидним. Уразливість Heartbleed в OpenSSL у 2014 році вразила бібліотеку, через яку проходила значна частина зашифрованого вебтрафіку. Її супроводжувала жменька людей майже без фінансування. У грудні 2021 року Log4Shell спрямувала реагування на інциденти в усьому світі до невеликої команди волонтерів проєкту Apache Log4j.

Бекдор у XZ Utils, виявлений у березні 2024 року, є найпоказовішим прикладом, оскільки атака була спрямована не на код, а на мейнтейнера. Один обліковий запис приблизно два роки робив справді корисні внески до бібліотеки стиснення, яку використовують у дистрибутивах Linux. Інші облікові записи тиснули на виснаженого єдиного мейнтейнера, щоб він прийняв допомогу. Новий співмейнтейнер потім вбудував бекдор в архіви релізу. Бекдор був націлений на системи, де SSH (secure shell) daemon лінкується з liblzma. Розробник виявив його, перевіряючи, чому вхід у систему тривав приблизно на пів секунди довше, ніж очікувалося. Це було випадкове везіння, і всі причетні публічно це визнавали.

Фінансування почало надходити: GitHub Sponsors з 2019 року, Open Collective, німецький Sovereign Tech Fund з 2022 року та проєкт Alpha-Omega від OpenSSF. Воно надходить нерівномірно й зазвичай дістається проєктам, які вже стали відомими. Регулювання також посилюється. Cyber Resilience Act Європейського Союзу набув чинності в грудні 2024 року, а більшість його вимог застосовуватиметься з грудня 2027 року. Ранні проєкти документа покладали б відповідальність виробника на неоплачуваних волонтерів. Тому остаточний текст створює окрему, менш обтяжливу категорію під назвою "open source software steward" після тривалого лобіювання з боку фондів і дистрибутивів.

Що історія open source означає для програм на вашому VPS

Кожен застосунок у наших посібниках із self-hosting залежить від цих рішень. Nextcloud існує завдяки fork: у 2016 році засновник ownCloud і значна частина команди залишили проєкт та відновили його під AGPLv3. Відтоді обидва продукти розвиваються паралельно. Ця історія пояснює альтернативи Nextcloud, які варто розглянути, а також self-hosted альтернативи Dropbox, що конкурують з обома продуктами.

Та сама закономірність простежується у hosting Git-репозиторіїв. Сам Gitea почався у 2016 році як fork Gogs. Наприкінці 2022 року торговельна марка та домени проєкту перейшли до компанії. У грудні того самого року Codeberg створив fork Forgejo, а у 2024 році Forgejo перейшов з MIT на GPLv3 у версії 9. Обидва продукти описані в матеріалі варіанти self-hosted Git-серверів, і різниця в ліцензіях значною мірою пояснює, чому вони й далі розвиваються окремо. Водночас більшість free software розробляють на GitHub — закритій платформі, що належить Microsoft. Це давня суперечка, у якій обидві сторони мають вагомі аргументи: див. що насправді являє собою GitHub.

Перш ніж передавати сервер під керування проєкту, варто витратити десять хвилин на чотири перевірки.

• Прочитайте файл LICENSE у репозиторії, а не маркетингову сторінку. На сторінках ще довго пишуть "open source", навіть коли вміст файлу LICENSE вже цього не підтверджує.
• Перевірте наявність CLA або передачі авторських прав. Якщо такий документ існує, один власник може змінити умови майбутніх релізів.
• З’ясуйте, кому належать авторські права: одній компанії, багатьом контриб’юторам чи foundation.
• Порахуйте активних мейнтейнерів. Проєкт з одним мейнтейнером є ризиком для нього так само, як і для вас.

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

Частину цієї історії можна прочитати безпосередньо на вашій машині. Кожен пакет у системі Debian або Ubuntu містить власні умови ліцензування:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Перше число показує, скільки встановлених пакетів містять файл copyright. На невеликому VPS це зазвичай кілька сотень. Друга команда виводить початок такого файлу для bash і показує, що пакет поширюється за GNU General Public License version 3. Відсутній файл означає, що пакет зібрано з порушенням політики Debian. Це трапляється рідко, але перед тим, як довіряти пакету, варто перевірити причину.

FAQ

У чому різниця між вільним програмним забезпеченням і open source?

Вони охоплюють майже однаковий набір ліцензій, але по-різному пояснюють, чому ці ліцензії важливі. Термін «вільне програмне забезпечення» з’явився раніше — його започаткувала Free Software Foundation у 1985 році. Його аргументація має етичний характер: користувач, який не може змінювати програму, не контролює свій комп’ютер. Термін «open source» запровадили в February 1998 року, щоб спростити пояснення тих самих ліцензій для компаній. Його аргументація має практичний характер. Ліцензії GPL, MIT, BSD і Apache 2.0 є в обох офіційних списках. Автори, які хочуть одночасно позначити обидва поняття, використовують FOSS або FLOSS.

Чи є програмне забезпечення з доступним вихідним кодом тим самим, що й open source?

Ні. Програмне забезпечення з доступним вихідним кодом дає змогу читати код. За Open Source Definition, open source також означає, що ліцензія не може обмежувати коло користувачів програмного забезпечення або цілі його використання. Ліцензії SSPL і Business Source License обмежують комерційне використання конкурентами. Тому за цим визначенням жодна з них не є open source, хоча обидві публікують вихідний код. Якщо ви самостійно розміщуєте програмне забезпечення лише для власних потреб, це обмеження може вас не стосуватися. Якщо ви хочете створити на його основі продукт, спочатку уважно прочитайте текст ліцензії.

Чи може компанія відкликати ліцензію open source, яку вже надала?

Ні, щодо коду, який вона вже випустила. Ця версія залишається під ліцензією, з якою її випустили. Саме тому такі форки, як Valkey і OpenTofu, могли почати розробку з останнього коміту, випущеного за дозвільною ліцензією. Компанія може перевести майбутні версії на нові умови. Це можливо лише за умови, що вона контролює авторські права на весь проєкт через передання прав або contributor licence agreement. Проєкти з багатьма незалежними власниками авторських прав, зокрема Linux, ніхто не може перевести на іншу ліцензію одноосібно.

Яку ліцензію слід шукати в self-hosted програмному забезпеченні?

Для програмного забезпечення, яке ви запускаєте самостійно й не перепродаєте, будь-яка схвалена OSI ліцензія, наприклад GPL, AGPL, MIT або Apache 2.0, надає все необхідне. Важливіше перевірити, хто володіє авторськими правами, оскільки саме це визначає, чи можуть умови згодом змінити без вашої згоди. Якщо проєкт належить foundation або багатьом незалежним учасникам, перевести його на іншу ліцензію всупереч інтересам користувачів неможливо. Якщо проєкт належить одному постачальнику і передбачає contributor licence agreement, це можливо. Обидва варіанти можуть стосуватися якісного програмного забезпечення. Але лише в одному випадку власник може самостійно змінити правила.