Ліцензії Open Source: основні види
Практично весь код, який інтегрується чи використовується для розробки програмного забезпечення, вже був написаний до цього. Неважливо, чи ти використовуєш цілі бібліотеки, великі блоки коду чи окремі фрагменти, кожен позичений елемент може мати свої правила та умови використання. Відкритий код, що зазвичай є вільним для використання, також має свої обмеження.
Навіть якщо твоя команда не створює опенсорсне ПЗ, а тільки використовує його, ти теж маєш розуміти різницю в ліцензіях. Наприклад, деякі програми мають ліцензію, яка вимагає, щоб застосунки, створені за допомогою цього ПЗ, також публікували свій вихідний код.
У цьому матеріалі ми розглянемо основні види ліцензій для опенсорсних застосунків, що потрібно знати перед тим, як використовувати такий код, та які наслідки чекають на порушників ліцензій.
Категорії опенсорсних ліцензій
На щастя, більшість ліцензій відносяться до однієї з двох категорій: ліцензії copyleft та permissive (дозвільні). Ми розглянемо обидві категорії та визначимо різницю між ними.
Ліцензії Copyleft
В умовах використання таких ліцензій зазначено, що всі модифіковані версії вільного коду також мають бути випущені під тією ж ліцензією. Якщо це не підходить бізнес-моделі твого проєкту, пильнуй, щоб не використовувати ПЗ з наступними типами ліцензій.
GNU General Public License або GPL
Це найдавніша ліцензія для ПЗ з відкритим кодом. GPL була створена в 1989 році розробниками, які створили операційну систему GNU. Попри свій вік ця ліцензія і досі вважається однією з найпопулярніших для опенсорсу.
Вона дає можливість команді розробки модифікувати код як заманеться, проте за умови, що цю змінену версію також будуть розповсюджувати як опенсорсне ПЗ. Ба більше, GPL вважається ліцензією з «сильним» копілефтом — та, що забезпечує максимальний захист вільного ПЗ. Весь код, для створення якого використовувалось ПЗ або фрагменти коду під GPL, мають випускатися під тією ж ліцензією. Це також стосується повністю зміненого вихідного коду.
Серед відомих опенсорсних проєктів, які використовують ліцензію GPL, можна назвати Linux Kernel, MySQL, VLC Media Player, WordPress, Grafana.
GNU Lesser General Public License або LGPL
Це «слабка» copyleft-ліцензія, менш сувора, ніж GPL. Вона була створена для того, щоб заохочувати використання бібліотек в комерційних програмах.
Якщо команда розробки просто використовує бібліотеку, фінальний продукт можна випускати під будь-якою ліцензією, навіть комерційною. Проте якщо бібліотека була модифікована, то проєкт має вийти з ліцензією LGPL. Тому це вважається більш м’якою альтернативою GPL, яка підходить для бізнесу.
Ліцензії Permissive
Інша велика категорія — це дозвільні ліцензії. На відміну від ліцензій з копілефтом, ці не накладають обмежень на людей, які використовують, змінюють або розповсюджують проєкт. Наприклад, якщо бізнес хоче створити свій форк або версію певного відкритого ПЗ та розповсюджувати її платно, то компанія має на це право лише тоді, якщо програмне забезпечення перебуває під ліцензією permissive.
BSD
Berkeley Software Distribution або BSD — популярна дозвільна ліцензія для ПЗ з відкритим кодом. Вона накладає мінімальні обмеження на розробників. Існує кілька видів ліцензії BSD, проте найпоширеніших всього два:
1. Модифікована версія 3-Clause BSD з такими умовами:
- повторне розповсюдження вихідного коду повинно містити повідомлення про авторські права, список умов і відмову від відповідальності;
- розповсюдження у бінарній формі повинно відтворювати повідомлення про авторські права, список умов та відмову від відповідальності у документації та/або інших матеріалах, що надаються разом з дистрибутивом;
- ні ім’я власника авторських прав, ні імена його розробників не можуть бути використані для схвалення або просування продуктів, отриманих на основі цього ПЗ, без спеціального попереднього письмового дозволу.
2. FreeBSD з тими ж умовами, крім третьої. Вона ще більше спрощує використання та поширення коду.
Відомі проєкти, що використовують ліцензію BSD: Python, MongoDB, ОС OpenBSD, OpenCV, PostgreSQL.
MIT
Ліцензія Массачусетського технологічного інституту — одна з найлегших у виконанні: будь-хто може копіювати, змінювати або поширювати код як заманеться, а для нового проєкту чи форка можна вибрати будь-яку ліцензію. Це робить MIT дуже привабливою ліцензією для відкритих і закритих програмних рішень.
Єдина обов’язкова умова використання продукту під ліцензією MIT — це те, що змінена версія коду повинна містити текст оригінальної ліцензії з заявою про авторські права. Цей текст складається приблизно зі 150 слів і є коротким у порівнянні з іншими ліцензіями.
MIT дозволяє користувачам не відповідати за можливі проблеми або помилки у програмному забезпеченні, тобто код використовується «на власний страх і ризик».
Такі проєкти, як Ruby on Rails, Node.js та React, були поширені під ліцензією MIT, тому їх використовують як для опенсорсних проєктів, так і комерційних.
Apache 2.0
Як і з будь-якою іншою дозвільною ліцензією, хто завгодно може використати проєкт, змінити його на свій лад та вільно поширювати відповідно до умов Apache 2.0. Крім цього, ліцензія надає захист від патентних претензій — автори не можуть мати претензії щодо того, що хтось використовує ці технології. Це надає користувачам впевненості та створює більш сприятливе середовище для інновацій.
Щоб застосувати цю ліцензію, треба в шапці кожного файлу вихідного коду або у файлі NOTICE вказати наступний текст:
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.Замість квадратних дужок та інформації в них потрібно вказати необхідні дані. Якщо для твого проєкту використовується ПЗ з ліцензією Apache 2.0, то ти маєш перенести зміст файлу NOTICE у кінцевий продукт.
Також необхідно прописати всі зміни, які були внесені у вихідний код. Це дає можливість іншим розробникам зрозуміти, які саме зміни були внесені у код та робить його більш прозорим.
Ліцензія Apache 2.0 містить стандартну відмову від відповідальності за помилки та баги у коді, щоб захистити авторів від можливої юридичної відповідальності.
Що буде, якщо порушити умови?
Якщо хтось порушує умови GPL або LGPL і розповсюджує програми під цією ліцензією без дотримання вимог, власники авторських прав можуть примусити виконати ліцензію. Це може бути лист з вимогою припинити порушувати ліцензію, запит на дотримання умов або позов до суду. GPL підтримується у різних правових системах по всьому світу.
Існує така організація, як Фонд вільного програмного забезпечення (FSF), що захищає copyleft-ліцензії та вживає правових заходів для захисту таких програм.
В результаті порушень GPL і LGPL вже укладалися угоди щодо виконання ліцензій та відкриття коду, накладалися судові заборони на використання або розповсюдження ПЗ тощо. Також в результаті порушення умов copyleft-ліцензій компанію можуть змусити відкликати своє ПЗ або змінити його так, аби воно відповідало умовам. Це може стати технічно складним і дорогим процесом.
Якщо порушити умови дозвільних ліцензій, наслідки, звичайно, не будуть настільки ж жорсткими, як з копілефтом. Найчастіше від порушників вимагають просто слідувати умовам ліцензії, оновити документацію та інші атрибути. Проте на компанію також можуть подати до суду, і вона втратить право на використання цього відкритого ПЗ у своїх проєктах.
Порушення ліцензій може призвести до втрати партнерських програм, ліцензійних угод, фінансових втрат, особливо якщо продукт комерційний, та завдати шкоди репутації компанії.
Післяслово
Отже, різні види опенсорсних ліцензій пропонують різні рівні свободи та обмежень для команди розробки. Знання особливостей цих ліцензій допоможе уникнути юридичних проблем, ефективніше використовувати доступні ресурси для розробки продукту та сприяти розвитку спільноти open source.