Перейти до вмісту

BSD License

Матеріал з K2 ERP Wiki

Критично: BSD License дає можливість використовувати код, але не гарантує якість, безпеку, підтримку або придатність для вашого продукту.SEO title: BSD License — permissive open source-ліцензії BSD-2-Clause, BSD-3-Clause і BSD-style ліцензування

SEO keywords: BSD License, BSD ліцензія, BSD-2-Clause, BSD-3-Clause, BSD 2-Clause License, BSD 3-Clause License, permissive license, open source license, SPDX BSD-2-Clause, SPDX BSD-3-Clause, OSI approved license, FreeBSD License, Modified BSD License, New BSD License, Simplified BSD License, copyright notice, warranty disclaimer, non-endorsement clause, advertising clause

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки. 

}}


license = "BSD-3-Clause"

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

! * open source governance;
* corporate compliance;
* GitHub license recognition;
* package ecosystems;
* SBOM;
* legal review;
* сумісності з open source-політиками;
* довіри до стандартного тексту ліцензії. Найчастіше використовують BSD-2-Clause і BSD-3-Clause.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

! '''Проста різниця:''' BSD-3-Clause додає правило: “не використовуйте ім’я автора для реклами або endorsement без дозволу”.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Або:

</div>

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* дає можливість proprietary use;
* не вимагає відкривати похідний код;
* коротка;
* зрозуміла;
* сумісна з багатьма політиками;
* не створює copyleft-обов’язків;
* зручна для embedded і enterprise;
* добре підходить для libraries;
* дає можливість продаж продукту. Такі ліцензії дають багато свободи користувачам і не вимагають, щоб похідні роботи обов’язково залишалися open source. З часом це стало незручним, особливо коли в одному продукті поєднувалося багато компонентів із різними авторами. BSD License часто зручна для комерційних продуктів. See the LICENSE file for details. BSD-ліцензії дозволяють використовувати, копіювати, змінювати й поширювати програмне забезпечення (ПЗ) з мінімальними обмеженнями.</div>
== Типові помилки початківців ==
[package]

'''Практична роль:''' файл LICENSE і SPDX-ідентифікатор прибирають неоднозначність: користувачі одразу бачать, який саме BSD-варіант застосовується. * Документація щодо permissive licenses. /*

* приватне використання;
* комерційне використання;
* копіювання;
* модифікацію;
* поширення;
* включення в proprietary software;
* включення в open source-проєкти;
* продаж продуктів із BSD-licensed кодом;
* створення похідних робіт;
* використання в embedded software;
* використання в server software;
* використання в libraries і SDK.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
 "license": "BSD-3-Clause"

! * OSI: BSD 3-Clause License. * BSD-3-Clause додає non-endorsement clause.<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

* '''BSD-2-Clause''';
* '''BSD-3-Clause''';
* '''BSD-4-Clause''';
* '''0BSD''';
* '''BSD-1-Clause''';
* BSD-style custom licenses. '''Практична роль:''' правильна metadata зменшує ручну роботу під час dependency audit і license compliance. [project]
== BSD 4-Clause License ==
'''Головна думка:''' BSD License — це проста permissive-ліцензія з великим рівнем довіри до користувача: використовуйте код вільно, але зберігайте notices, disclaimer і не приписуйте авторам endorsement без дозволу.</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* FreeBSD;
* OpenBSD;
* NetBSD;
* DragonFly BSD;
* мережевими стеком;
* системними утилітами;
* libraries;
* embedded platforms;
* UNIX-like ecosystems;
* частинами комерційних ОС;
* research operating systems.== Загальний SEO-опис ==

* точно вказувати `BSD-2-Clause` або `BSD-3-Clause`;
* додати файл `LICENSE`;
* використовувати стандартний текст ліцензії;
* додати SPDX identifier у файли коду;
* зберігати copyright notices;
* зберігати disclaimer;
* не використовувати імена contributor-ів для endorsement без дозволу;
* вести third-party notices;
* перевіряти dependencies;
* вести SBOM для великих продуктів;
* не використовувати стару BSD-4-Clause для нових проєктів без причини;
* перевіряти patent concerns у корпоративних продуктах.== конкурентні переваги BSD License ==
'''Основна ідея:''' BSD License каже: “Можете використовувати код майже як завгодно, але не прибирайте повідомлення про авторські права, текст ліцензії й відмову від гарантій”.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''BSD-2-Clause-Patent''' — варіант BSD-2-Clause із патентною частиною.== Приклад license metadata ==
Це корисно для:
BSD License здатна бути не найкращим вибором, якщо:
// SPDX-License-Identifier: BSD-2-Clause
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''BSD 2-Clause License''' так само відома як '''Simplified BSD License''' або '''FreeBSD License'''. }
Класичні BSD-2-Clause і BSD-3-Clause не мають такої явної й детальної patent grant-мови, як Apache License 2.0. Ця умова забороняє використовувати імена copyright holder або contributors для просування похідного продукту без попереднього письмового дозволу. ліцензійний пакет не гарантує безпеку коду.== Third-party notices ==
|-
| Тип
| Permissive
| Copyleft
|-
| Похідний код
| здатна бути закритим
| Має залишатися GPL-сумісним при поширенні похідної роботи
|-
| Proprietary software
| Дозволене
| Обмежене copyleft-умовами
|-
| Головна умова
| Зберегти notices і disclaimer
| Зберегти software freedoms і надати source code
|-
| Ідея
| Максимальна гнучкість
| Взаємність і захист відкритості
|}

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
=== Академічний проєкт ===
компаній забезпечується через Цікаво, що BSD-style ліцензування дозволило коду з BSD-екосистеми потрапити в дуже різні продукти: open source-системи, комерційні ОС, мережеве обладнання, embedded-пристрої й proprietary software. GPL

Ця умова створювала проблеми:

'''критично:''' 0BSD — не те саме, що BSD-2-Clause або BSD-3-Clause. '''Критично:''' BSD License відповідає на питання “чи можна використовувати код”, але не відповідає на питання “чи безпечний цей код”.<syntaxhighlight lang="json">
Цей ERP-продукт використовує код під BSD-3-Clause — можна. ## License

Приклад сенсу:
</div>

'''Підказка:''' якщо хочете максимальну простоту — дивіться BSD-2-Clause; якщо хочете захист від endorsement — BSD-3-Clause.</div>
BSD License і MIT License дуже схожі за permissive-духом. |-
| Тип
| Permissive
| Permissive
|-
| Copyright notice
| Потрібно зберігати
| Потрібно зберігати
|-
| Warranty disclaimer
| виступає як
| виступає як
|-
| Non-endorsement clause
| Немає
| виступає як
|-
| Комерційне використання
| Дозволене
| Дозволене
|-
| Proprietary products
| Дозволені
| Дозволені
|}

'''Non-endorsement clause''' — це третя умова BSD-3-Clause License. '''BSD License''' — це сімейство permissive open source-ліцензій, які дозволяють широко використовувати, змінювати й поширювати код, зокрема в комерційних і proprietary-продуктах. * Найпоширеніші сучасні варіанти — BSD-2-Clause і BSD-3-Clause. * SPDX: BSD 2-Clause "Simplified" License. Це критично для:
{| class="wikitable"

BSD-ліцензії містять warranty disclaimer. SPDX License List містить стандартизовані short identifiers, повні назви, тексти й canonical URLs для ліцензій і винятків. * Стара BSD-4-Clause мала advertising clause, яка виявилася незручною.== BSD License і MIT License ==

0BSD

Цікавий момент: сучасні популярні BSD-ліцензії фактично стали простішими саме тому, що стара advertising clause виявилася надто незручною. BSD-2-Clause

  • SPDX License List. * OSI: BSD 2-Clause License.== BSD License у package metadata ==

критично: якщо патентні питання критичні, варто розглянути Apache License 2.0 або BSD-2-Clause-Patent і проконсультуватися з фахівцем. Це означає, що програмне забезпечення (ПЗ) надається без гарантій. * ускладнювала license compliance;

  • погано масштабувалася для великих продуктів;
  • могла створювати багато різних attribution-вимог;
  • погіршувала сумісність із GPL;
  • робила ліцензію менш зручною для сучасного open source. ! * Матеріали щодо BSD Unix, FreeBSD, OpenBSD, NetBSD і BSD-style software ecosystems. :contentReference [oaicite:2]{index=2}

Це корисно для:

Або:

компанія-користувач використовує BSD-licensed компонент у firmware пристрою й додає license notice у third-party notices. Термін BSD License здатна означати різні ліцензії, тому його краще уточнювати.=== Embedded product ===

! Критерій

BSD License належить до permissive licenses.

У `LICENSE` додають текст конкретної BSD-ліцензії: BSD-2-Clause або BSD-3-Clause. Розробник створює library і хоче, щоб її могли використовувати open source-проєкти, стартапи й комерційні продукти.</syntaxhighlight>

через Практична роль: SPDX-рядок користувачі можуть людям, package managers, SBOM-інструментам і compliance scanners автоматизовано розпізнавати ліцензію. src/

Для BSD-3-Clause:

BSD License дає можливість:

Приклад SPDX у файлі

  • писати без зусиль “BSD” без уточнення версії;
  • плутати BSD-2-Clause і BSD-3-Clause;
  • використовувати BSD-4-Clause випадково;
  • видаляти copyright notice;
  • забувати disclaimer;
  • думати, що BSD License забороняє комерційне використання;
  • думати, що BSD License змушує відкривати похідний код;
  • плутати BSD License з GPL;
  • не включати third-party notices у commercial product;
  • використовувати ім’я автора для реклами без дозволу при BSD-3-Clause;
  • змінювати текст ліцензії й далі називати її стандартною BSD.
    </div>
    
    <div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
    
    '''Практична роль:''' стандартна OSI-approved ліцензійний пакет значно зрозуміліша для користувачів і компаній, ніж самописний license text. У більшості випадків краще BSD-2-Clause або BSD-3-Clause. |-
    | Тип
    | Permissive
    | Permissive
    |-
    | Довжина
    | Коротка
    | Значно довша
    |-
    | Patent grant
    | Зазвичай не такий явний
    | Має явний patent grant
    |-
    | NOTICE mechanism
    | Простий notice/disclaimer
    | Детальніший NOTICE-підхід
    |-
    | Корпоративні патентні сценарії
    | Потребують окремої уваги
    | Часто зручніша через патентну мову
    |}
    
    BSD License історично повязана з університетською й дослідницькою культурою. '''Практична роль:''' BSD License дає можливість бізнесу використовувати open source-код без обовязку відкривати весь власний ERP-продукт.</div>
    This project is licensed under the BSD 3-Clause License.
    
* не змушує відкривати похідний код;
* не гарантує повернення покращень у open source;
* класичні BSD-2/3 не мають детального patent grant;
* стара BSD-4-Clause має незручну advertising clause;
* термін “BSD License здатна бути неоднозначним;
* не дає гарантій якості;
* не дає підтримки;
* потребує правильного збереження notices;
* здатна бути занадто permissive для проєктів, які хочуть copyleft. Вона зручна для:
== Коли варто використовувати BSD License ==
<syntaxhighlight lang="c">

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

Цікавий факт: BSD-style ліцензування добре пасує академічному підходу: “ми публікуємо ідею й реалізацію, а ви можете розвивати її далі”.=== Open source library ===

У файлах коду можна додати SPDX:

</syntaxhighlight>

  • web services;
  • APIs;
  • internal services;
  • cloud platforms;
  • hosted applications;
  • developer tools;
  • backend libraries;
  • monitoring services;
  • commercial SaaS. ! Якщо ERP-продукт використовує BSD-licensed код, зазвичай потрібно зберегти license notices у third-party notices. OSI approval важлива для:

Поширені варіанти:

! ISC License !== BSD 3-Clause License ==

OSI approval

  • у source code;
  • у документації;
  • у third-party notices;
  • у license bundle;
  • у About / Legal section застосунку;
  • у firmware notices для embedded-пристроїв;
  • у package metadata.== Приклади сценаріїв використання ==

! Автори оригінального коду рекомендують наш ERP-продукт — не можна без дозволу. критично: якщо патентні питання критичні, Apache License 2.0 здатна бути кращим вибором, ніж класична BSD-2-Clause або BSD-3-Clause. Для Python:

BSD License і безпека

Практична роль: non-endorsement clause захищає авторів від того, щоб їхні імена використовували в маркетингу чужого продукту. Copyright (c) 2026 Example Author

BSD License добре підходить для бібліотек, SDK, системного ПЗ, академічного коду, embedded-компонентів і проєктів, де автор хоче мінімізувати обмеження для downstream-користувачів. Copyright notice здатна виглядати так:

Системна утиліта

BSD License і операційні системи

Патенти

  • академічних проєктів;
  • дослідницького коду;
  • reference implementations;
  • університетських бібліотек;
  • networking research;
  • operating systems research;
  • навчального коду;
  • спільного використання між індустрією й академією. Практична роль: BSD-2-Clause-Patent — це спроба поєднати простоту BSD-2-Clause з явнішою патентною мовою. Критерій

Навіть якщо код BSD-licensed, потрібно перевіряти:

Команда створює системний інструмент і хоче, щоб його могли включати в різні UNIX-like системи, зокрема proprietary. BSD License має обмеження. Університетська лабораторія публікує research code, щоб інші могли вивчати, змінювати й використовувати його без copyleft-обмежень.

Приклад для Rust `Cargo.toml`:

  • великих компаній;
  • patent-sensitive projects;
  • стандартів;
  • multimedia;
  • hardware/software products;
  • corporate compliance;
  • open source governance;
  • contributors. критично: SPDX identifier має відповідати реальному тексту ліцензії у файлі `LICENSE`. Приклад у коді:
'''Advertising clause'''  це умова старої 4-clause BSD License, яка вимагала згадки в advertising materials. BSD License не виступає як copyleft-ліцензією. '''Помилка:''' обирати стару BSD-4-Clause для нового проєкту без особливої причини. '''0BSD''' або '''Zero-Clause BSD'''  дуже permissive BSD-style ліцензійний пакет, яка фактично прибирає attribution-вимогу класичних BSD-ліцензій. BSD License

/*

Для BSD-ліцензій критично використовувати точні SPDX identifiers. Критерій

BSD License і Apache License 2.0

  • `BSD-2-Clause`;
  • `BSD-3-Clause`;
  • `BSD-4-Clause`;
  • `0BSD`;
  • `BSD-1-Clause`;
  • `BSD-2-Clause-Patent`. Вона пов’язана з BSD Unix, який сильно вплинув на дорожня карта розвитку сучасних операційних систем, мережевих стеків, серверного програмного забезпечення й UNIX-подібних систем. BSD-3-Clause

! Висновок: BSD License дає downstream-користувачам більше свободи, але не гарантує, що їхні покращення повернуться в open source. {| class="wikitable"

  • permissive;
  • коротка;
  • зрозуміла;
  • дає можливість commercial use;
  • дає можливість proprietary use;
  • не вимагає відкривати похідний код;
  • має стандартні SPDX identifiers;
  • добре підходить для libraries;
  • зручна для academic code;
  • зручна для системного ПЗ;
  • широко сумісна з іншими ліцензіями;
  • BSD-3-Clause має non-endorsement захист;
  • проста для compliance порівняно з copyleft-ліцензіями. Якщо потрібно зберегти attribution-умову, краще не використовувати 0BSD. * BSD License не виступає як copyleft-ліцензією. Краще вказати конкретно: `BSD-2-Clause` або `BSD-3-Clause`. Apache License 2.0 так само permissive, але довша й детальніша. Критерій

BSD License як сімейство ліцензій

// SPDX-License-Identifier: BSD-3-Clause

Вона має дві основні умови:

  • маленьких code snippets;
  • прикладів;
  • навчального коду;
  • шаблонів;
  • public-domain-like сценаріїв;
  • проєктів, де автор хоче максимально спростити повторне використання. ! :contentReference [oaicite:4]{index=4}
  • BSD-2-Clause дуже близька за духом до MIT License. BSD-2-Clause або BSD-3-Clause добре підходять.

Хороші практики BSD License

Див. так само

У сучасних package ecosystems ліцензію часто вказують через SPDX identifier. Його часто називають Original BSD License.

Перевага: BSD License дає майже максимальну свободу повторного використання коду, залишаючи мінімальні вимоги до attribution і disclaimer. * при поширенні source code потрібно зберігати copyright notice, список умов і disclaimer;

  • при поширенні binary form потрібно відтворювати copyright notice, список умов і disclaimer у документації або інших матеріалах. Найчастіше під “BSD License” мають на увазі одну з двох сучасних ліцензій:

</syntaxhighlight>

Висновок

ISC License схожа на BSD-2-Clause та MIT License: коротка, permissive і проста. * BSD-style ліцензування сильно вплинуло на UNIX-like системи, мережевий код і комерційне ПЗ. SPDX для BSD-2-Clause так само посилається на OSI-сторінку цієї ліцензії як related web page. * FreeBSD materials about BSD-style licensing. * Матеріали щодо open source compliance, SBOM, third-party notices, copyright notices, warranty disclaimers і license compatibility. !

</syntaxhighlight>

  • активність підтримки;
  • known vulnerabilities;
  • code review;
  • dependency chain;
  • maintainer trust;
  • SBOM;
  • release signatures;
  • supply chain;
  • test coverage;
  • security advisories;
  • production readiness. project/

критично: якщо репозиторій не має ліцензії, інші люди не мають чіткого дозволу використовувати код як open source. Водночас вона не виступає як copyleft-ліцензією, не вимагає відкривати похідний код і не гарантує повернення покращень у спільноту.</syntaxhighlight> Найлюдяніший факт: BSD License — це ліцензійний пакет для авторів, які хочуть сказати: “Беріть мій код, будуйте на ньому що завгодно, тільки не стирайте походження й не перекладайте відповідальність на мене”. BSD License

Висновок: MIT License зазвичай коротша, BSD-2-Clause дуже близька до неї, а BSD-3-Clause додає non-endorsement захист. BSD-2-Clause

Головна проблема BSD-4-Clause — advertising clause. BSD License

"license": "BSD-3-Clause"

!== Джерела ==

Warranty disclaimer

Вона означає:

  • потрібно, щоб похідний код обов’язково залишався open source;
  • потрібен strong copyleft;
  • потрібен AGPL-style захист для SaaS;
  • потрібен детальний patent grant;
  • проєкт не хоче дозволяти proprietary forks;
  • критично, щоб усі downstream-покращення поверталися спільноті;
  • потрібна сувора trademark policy;
  • потрібні складні contributor terms. :contentReference [oaicite:3]{index=3}
  1. SPDX-License-Identifier: BSD-3-Clause
критично: BSD License — це вибір на користь свободи downstream-користувача, навіть якщо цей користувач системи закриє свій похідний код. Вона вимагала згадувати використання коду в рекламних матеріалах. Висновок: BSD-2-Clause, MIT і ISC часто виконують схожу практичну роль: дозволяють широке повторне використання з мінімальними умовами. це назва сімейства permissive open source-ліцензій, що походять від Berkeley Software Distribution, або BSD виступає ключовою рисою BSD License. BSD License не вимагає: Причини: Вона схожа на BSD-2-Clause, але має додаткову умову — non-endorsement clause.
<div style="background:#ecfdf5; border-left:6px solid #10b981; padding:12px; margin:12px 0;">
'''критично:''' навіть permissive-ліцензії не означають можна видалити всі згадки про автора. Рекомендовано:
</div>
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

'''Найлюдяніший факт:''' BSD License  це ліцензійний пакет довіри: автор дає багато свободи й не вимагає взаємності, але просить чесно зберегти походження коду. {| class="wikitable"
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
</div>

'''Практична роль:''' BSD License не має AGPL-style network copyleft, тому не вимагає відкривати server-side зміни лише через мережеве використання. |-
| Тип
| Permissive
| Permissive
|-
| Довжина
| Коротка
| Дуже коротка
|-
| Attribution
| Так
| Так
|-
| Warranty disclaimer
| Так
| Так
|-
| Proprietary use
| Дозволене
| Дозволене
|}
Головна вимога BSD-ліцензій — зберігати copyright notice, license conditions і disclaimer. !
{| class="wikitable"

</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
</div>
 * SPDX-License-Identifier: BSD-2-Clause
 */
!</div>

* відкривати похідний код;
* поширювати зміни під BSD;
* публікувати модифікації;
* використовувати ту саму ліцензію для всього продукту;
* робити ERP-продукт безкоштовним;
* повідомляти автора про використання;
* віддавати proprietary code;
* розкривати commercial source code;
* застосовувати copyleft.<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
Основні конкурентні переваги BSD License:
== Non-endorsement clause ==

== Copyright notice ==

* BSD License  це не одна ліцензійний пакет, а сімейство BSD-style ліцензій. '''Проста аналогія:''' BSD-2-Clause  це дуже легка ліцензійний пакет: “залиш повідомлення про автора й гарантій немає”. Критерій

</div>

GitHub і подібні платформи можуть автоматизовано розпізнавати стандартні BSD-ліцензії, якщо в репозиторії виступає як файл `LICENSE` зі стандартним текстом. Саме permissive-характер BSD зробив її зручною; так само реалізовано університетів і незалежних розробників. Можливі проблеми:
</div>

'''Помилка:''' обирати BSD License, якщо головна мета  змусити всі похідні роботи залишатися open source.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
license = "BSD-2-Clause"
'''BSD 3-Clause License''' так само називають '''New BSD License''', '''Modified BSD License''' або '''Revised BSD License'''. компанія-користувач відкриває SDK під BSD-3-Clause, щоб інші могли швидко інтегруватися з її платформою, але не використовували назву компанії для endorsement без дозволу. * BSD License дає можливість використовувати код у proprietary products.</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
У `README.md` можна написати:
== BSD License і університети ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
</div>

Головна ідея BSD-ліцензій проста: можна широко використовувати код, зокрема в комерційних і proprietary-продуктах, але потрібно зберігати copyright notice, license text і disclaimer. Критерій

</div>

</div>

</div>
== Advertising clause ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
|-
| Тип
| Permissive
| Permissive
|-
| Комерційне використання
| Дозволене
| Дозволене
|-
| Proprietary products
| Дозволені
| Дозволені
|-
| Attribution
| Так
| Так
|-
| Warranty disclaimer
| Так
| Так
|-
| Non-endorsement clause
| виступає як в BSD-3-Clause
| Немає
|}
== BSD License і SaaS ==

<syntaxhighlight lang="javascript">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Головна перевага:''' BSD License робить код дуже легким для повторного використання майже в будь-якому продукті.

BSD 2-Clause License

  • автор не гарантує безпомилкову роботу;
  • автор не гарантує придатність для конкретної задачі;
  • автор не несе відповідальності за збитки;
  • користувач системи використовує код на власний ризик;
  • перед production-використанням код потрібно тестувати.

Головне правило: BSD License проста, але її потрібно називати точно й зберігати всі notices. { BSD-licensed код можна використовувати в proprietary software, якщо виконані умови ліцензії. * SPDX-License-Identifier: BSD-3-Clause

*/
BSD License permissive, а GPL copyleft. Через advertising clause BSD-4-Clause менш зручна й значно рідше рекомендована для нових проєктів.
Практична роль: package metadata оптимізує автоматичним інструментам перевіряти ліцензії dependencies.

BSD License і copyleft

[project] Перевага: BSD License дає можливість open source-коду жити і в відкритих, і в закритих продуктах без складної взаємності. * Для юридичної точності краще писати `BSD-2-Clause` або `BSD-3-Clause`, а не без зусиль “BSD License”.== Обмеження BSD License ==

Висновок: BSD-2-Clause трохи простіша, а BSD-3-Clause додає захист від використання імені автора або contributor-ів для просування продукту. Для npm: BSD License добре підходить, якщо потрібно: Поширені ідентифікатори:

Іншими словами, можна використовувати код, але не можна казати або натякати, що автори BSD-коду підтримують ваш ERP-продукт, якщо вони цього не дозволили. MIT License

BSD License — одна з найстаріших і найвпливовіших сімей open source-ліцензій.

Для Cargo:

/* SPDX-License-Identifier: BSD-2-Clause */

BSD 2-Clause і BSD 3-Clause

BSD 4-Clause License — старіший варіант BSD License. README.md

}

BSD License і ISC License

</syntaxhighlight>

BSD-2-Clause і BSD-3-Clause належать до стандартних open source-ліцензій, які широко використовуються в екосистемі. BSD License

Приклад для npm:

0BSD здатна бути доречною для:

  • комерційних застосунків;
  • SDK;
  • embedded firmware;
  • операційних систем;
  • мережевого обладнання;
  • cloud services;
  • desktop apps;
  • mobile apps;
  • game engines;
  • libraries;
  • internal company tools. :contentReference [oaicite:1]{index=1}

Він здатна бути цікавий у проєктах, де хочуть:

  • contributors;
  • dependency scanners;
  • package users;
  • open source compliance;
  • SBOM;
  • legal review;
  • автоматичного визначення ліцензії;
  • прозорості проєкту. * `THIRD_PARTY_NOTICES.txt`;
  • розділ Legal у застосунку;
  • документація;
  • About screen;
  • license bundle;
  • firmware notices;
  • web page з open source notices;
  • package metadata. Практична порада: BSD-2-Clause добре підходить, коли потрібна максимальна простота, а BSD-3-Clause — коли критично додати non-endorsement clause.

BSD License і proprietary software

Коли BSD License здатна бути невдалим вибором

BSD License і GitHub

BSD License і GPL

Тип Permissive Reciprocal / copyleft
Відкриття похідного коду Не вимагає Часто вимагає
Proprietary use Дозволене здатна бути обмежене
Головна ідея Мінімальні обмеження Збереження відкритості похідних робіт
!== BSD License і комерційні продукти ==
Disclaimer зазвичай означає:
Типова структура:

<syntaxhighlight lang="text">

[package]

license = "BSD-2-Clause"

* permissive BSD-style ліцензування;
* коротший текст, ніж Apache License 2.0;
* явніший patent grant;
* стандартний SPDX identifier;
* кращу ясність для patent-sensitive contributors.== Цікавий факт ==
Поширені помилки:
BSD License дає можливість використовувати код у SaaS-продуктах без обов’язку відкривати власний server-side код.== Тематичні мітки ==
=== Commercial SDK ===
<syntaxhighlight lang="toml">

license = "BSD-3-Clause"

BSD License важлива для операційних систем і системного ПЗ.
  • не можна використовувати ім’я автора для просування продукту без дозволу;
  • не можна натякати, що original contributors підтримують ваш fork або product;
  • attribution дозволена, endorsement без дозволу — ні. ! Copyleft-ліцензії
  • дозволити широке повторне використання;
  • дозволити commercial use;
  • дозволити proprietary use;
  • мати коротку стандартну ліцензію;
  • опублікувати library;
  • опублікувати системний інструмент;
  • поділитися академічним кодом;
  • зробити SDK;
  • мінімізувати license friction;
  • уникнути copyleft-вимог;
  • дозволити інтеграцію в open source і closed source продукти. * SPDX License List подає стандартизовані identifiers і canonical URLs для BSD-ліцензій. Для BSD-2-Clause:

При використанні BSD-licensed коду в іншому продукті потрібно зберегти відповідні notices:

  • BSD 2-Clause License або Simplified BSD License;
  • BSD 3-Clause License або New BSD License / Modified BSD License.

SPDX identifiers

{

BSD-2-Clause-Patent

Це здатна бути:

Практична роль: BSD License дозволила системному коду широко поширюватися між open source і commercial ecosystems. Перевага: BSD License дуже зручна для компаній, бо дає можливість включати код у комерційні й закриті продукти. BSD-2-Clause виступає як простішою, а BSD-3-Clause додає non-endorsement clause.

Вона пов’язана з:

Це інтуїтивно для: Приклад для Python `pyproject.toml`:

'''критично:''' не варто писати без зусиль BSD License”, якщо потрібна юридична точність. Apache License 2.0

 LICENSE

== Як додати BSD License до проєкту ==
BSD-2-Clause виступає як короткою, permissive і дуже зручною для повторного використання.

Чого BSD License не вимагає

Небезпека: найбільша плутанина з BSD License виникає через нечітке формулювання “BSD” без конкретного SPDX identifier.<syntaxhighlight lang="go">

Цікаві факти про BSD License

критично: BSD License дуже вільна, але attribution і license notice все одно потрібно зберігати. SPDX прямо подає `BSD-2-Clause` як short identifier для BSD 2-Clause "Simplified" License. * Open source