BSD License

BSD License — це назва сімейства permissive open source-ліцензій, що походять від Berkeley Software Distribution, або BSD. BSD-ліцензії дозволяють використовувати, копіювати, змінювати й поширювати програмне забезпечення з мінімальними обмеженнями.

Найчастіше під “BSD License” мають на увазі одну з двох сучасних ліцензій:

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

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

Основна ідея: BSD License каже: “Можете використовувати код майже як завгодно, але не прибирайте повідомлення про авторські права, текст ліцензії й відмову від гарантій”.

Цікавий факт

BSD License — одна з найстаріших і найвпливовіших сімей open source-ліцензій. Вона пов’язана з BSD Unix, який сильно вплинув на розвиток сучасних операційних систем, мережевих стеків, серверного програмного забезпечення й UNIX-подібних систем.

Цікаво, що BSD-style ліцензування дозволило коду з BSD-екосистеми потрапити в дуже різні продукти: open source-системи, комерційні ОС, мережеве обладнання, embedded-пристрої й proprietary software. Саме permissive-характер BSD зробив її зручною для компаній, університетів і незалежних розробників.

Найлюдяніший факт: BSD License — це ліцензія для авторів, які хочуть сказати: “Беріть мій код, будуйте на ньому що завгодно, тільки не стирайте походження й не перекладайте відповідальність на мене”.

Загальний опис

BSD License належить до permissive licenses. Такі ліцензії дають багато свободи користувачам і не вимагають, щоб похідні роботи обов’язково залишалися open source.

BSD License дозволяє:

приватне використання;
комерційне використання;
копіювання;
модифікацію;
поширення;
включення в proprietary software;
включення в open source-проєкти;
продаж продуктів із BSD-licensed кодом;
створення похідних робіт;
використання в embedded software;
використання в server software;
використання в libraries і SDK.

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

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

Термін BSD License може означати різні ліцензії, тому його краще уточнювати.

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

BSD-2-Clause;
BSD-3-Clause;
BSD-4-Clause;
0BSD;
BSD-1-Clause;
BSD-style custom licenses.

SPDX License List містить стандартизовані short identifiers, повні назви, тексти й canonical URLs для ліцензій і винятків. :contentReference[oaicite:1]{index=1}

Важливо: не варто писати просто “BSD License”, якщо потрібна юридична точність. Краще вказати конкретно: `BSD-2-Clause` або `BSD-3-Clause`.

SPDX identifiers

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

Поширені ідентифікатори:

`BSD-2-Clause`;
`BSD-3-Clause`;
`BSD-4-Clause`;
`0BSD`;
`BSD-1-Clause`;
`BSD-2-Clause-Patent`.

SPDX прямо подає `BSD-2-Clause` як short identifier для BSD 2-Clause "Simplified" License. :contentReference[oaicite:2]{index=2}

Приклад у коді:

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

Або:

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

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

BSD 2-Clause License

BSD 2-Clause License також відома як Simplified BSD License або FreeBSD License.

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

при поширенні source code потрібно зберігати copyright notice, список умов і disclaimer;
при поширенні binary form потрібно відтворювати copyright notice, список умов і disclaimer у документації або інших матеріалах.

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

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

BSD 3-Clause License

BSD 3-Clause License також називають New BSD License, Modified BSD License або Revised BSD License.

Вона схожа на BSD-2-Clause, але має додаткову умову — non-endorsement clause. Ця умова забороняє використовувати імена copyright holder або contributors для просування похідного продукту без попереднього письмового дозволу.

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

Проста різниця: BSD-3-Clause додає правило: “не використовуйте ім’я автора для реклами або endorsement без дозволу”.

BSD 2-Clause і BSD 3-Clause

Критерій	BSD-2-Clause	BSD-3-Clause
Тип	Permissive	Permissive
Copyright notice	Потрібно зберігати	Потрібно зберігати
Warranty disclaimer	Є	Є
Non-endorsement clause	Немає	Є
Комерційне використання	Дозволене	Дозволене
Proprietary products	Дозволені	Дозволені

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

BSD 4-Clause License

BSD 4-Clause License — старіший варіант BSD License. Його часто називають Original BSD License.

Головна проблема BSD-4-Clause — advertising clause. Вона вимагала згадувати використання коду в рекламних матеріалах. З часом це стало незручним, особливо коли в одному продукті поєднувалося багато компонентів із різними авторами.

Через advertising clause BSD-4-Clause менш зручна й значно рідше рекомендована для нових проєктів.

Помилка: обирати стару BSD-4-Clause для нового проєкту без особливої причини. У більшості випадків краще BSD-2-Clause або BSD-3-Clause.

Advertising clause

Advertising clause — це умова старої 4-clause BSD License, яка вимагала згадки в advertising materials.

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

ускладнювала license compliance;
погано масштабувалася для великих продуктів;
могла створювати багато різних attribution-вимог;
погіршувала сумісність із GPL;
робила ліцензію менш зручною для сучасного open source.

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

Non-endorsement clause

Non-endorsement clause — це третя умова BSD-3-Clause License.

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

не можна використовувати ім’я автора для просування продукту без дозволу;
не можна натякати, що original contributors підтримують ваш fork або product;
attribution дозволена, endorsement без дозволу — ні.

Приклад сенсу:

Цей продукт використовує код під BSD-3-Clause — можна.
Автори оригінального коду рекомендують наш продукт — не можна без дозволу.

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

Warranty disclaimer

BSD-ліцензії містять warranty disclaimer. Це означає, що програмне забезпечення надається без гарантій.

Disclaimer зазвичай означає:

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

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

Copyright notice

Головна вимога BSD-ліцензій — зберігати copyright notice, license conditions і disclaimer.

Copyright notice може виглядати так:

Copyright (c) 2026 Example Author

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

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

Важливо: BSD License дуже вільна, але attribution і license notice все одно потрібно зберігати.

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

BSD License не вимагає:

відкривати похідний код;
поширювати зміни під BSD;
публікувати модифікації;
використовувати ту саму ліцензію для всього продукту;
робити продукт безкоштовним;
повідомляти автора про використання;
віддавати proprietary code;
розкривати commercial source code;
застосовувати copyleft.

Перевага: BSD License дуже зручна для компаній, бо дозволяє включати код у комерційні й закриті продукти.

BSD License і proprietary software

BSD-licensed код можна використовувати в proprietary software, якщо виконані умови ліцензії.

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

комерційних застосунків;
SDK;
embedded firmware;
операційних систем;
мережевого обладнання;
cloud services;
desktop apps;
mobile apps;
game engines;
libraries;
internal company tools.

Практична роль: BSD License дозволяє бізнесу використовувати open source-код без обов’язку відкривати весь власний продукт.

BSD License і copyleft

BSD License не є copyleft-ліцензією.

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

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

BSD License і MIT License

BSD License і MIT License дуже схожі за permissive-духом.

Критерій	BSD License	MIT License
Тип	Permissive	Permissive
Комерційне використання	Дозволене	Дозволене
Proprietary products	Дозволені	Дозволені
Attribution	Так	Так
Warranty disclaimer	Так	Так
Non-endorsement clause	Є в BSD-3-Clause	Немає

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

BSD License і GPL

BSD License permissive, а GPL copyleft.

Критерій	BSD License	GPL
Тип	Permissive	Copyleft
Похідний код	Може бути закритим	Має залишатися GPL-сумісним при поширенні похідної роботи
Proprietary software	Дозволене	Обмежене copyleft-умовами
Головна умова	Зберегти notices і disclaimer	Зберегти software freedoms і надати source code
Ідея	Максимальна гнучкість	Взаємність і захист відкритості

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

BSD License і Apache License 2.0

Apache License 2.0 також permissive, але довша й детальніша.

Критерій	BSD License	Apache License 2.0
Тип	Permissive	Permissive
Довжина	Коротка	Значно довша
Patent grant	Зазвичай не такий явний	Має явний patent grant
NOTICE mechanism	Простий notice/disclaimer	Детальніший NOTICE-підхід
Корпоративні патентні сценарії	Потребують окремої уваги	Часто зручніша через патентну мову

Важливо: якщо патентні питання критичні, Apache License 2.0 може бути кращим вибором, ніж класична BSD-2-Clause або BSD-3-Clause.

BSD License і ISC License

ISC License схожа на BSD-2-Clause та MIT License: коротка, permissive і проста.

Критерій	BSD-2-Clause	ISC License
Тип	Permissive	Permissive
Довжина	Коротка	Дуже коротка
Attribution	Так	Так
Warranty disclaimer	Так	Так
Proprietary use	Дозволене	Дозволене

Висновок: BSD-2-Clause, MIT і ISC часто виконують схожу практичну роль: дозволяють широке повторне використання з мінімальними умовами.

0BSD

0BSD або Zero-Clause BSD — дуже permissive BSD-style ліцензія, яка фактично прибирає attribution-вимогу класичних BSD-ліцензій.

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

маленьких code snippets;
прикладів;
навчального коду;
шаблонів;
public-domain-like сценаріїв;
проєктів, де автор хоче максимально спростити повторне використання.

Важливо: 0BSD — не те саме, що BSD-2-Clause або BSD-3-Clause. Якщо потрібно зберегти attribution-умову, краще не використовувати 0BSD.

BSD-2-Clause-Patent

BSD-2-Clause-Patent — варіант BSD-2-Clause із патентною частиною.

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

permissive BSD-style ліцензування;
коротший текст, ніж Apache License 2.0;
явніший patent grant;
стандартний SPDX identifier;
кращу ясність для patent-sensitive contributors.

Практична роль: BSD-2-Clause-Patent — це спроба поєднати простоту BSD-2-Clause з явнішою патентною мовою.

OSI approval

BSD-2-Clause і BSD-3-Clause належать до стандартних open source-ліцензій, які широко використовуються в екосистемі. SPDX для BSD-2-Clause також посилається на OSI-сторінку цієї ліцензії як related web page. :contentReference[oaicite:3]{index=3}

OSI approval важлива для:

open source governance;
corporate compliance;
GitHub license recognition;
package ecosystems;
SBOM;
legal review;
сумісності з open source-політиками;
довіри до стандартного тексту ліцензії.

Практична роль: стандартна OSI-approved ліцензія значно зрозуміліша для користувачів і компаній, ніж самописний license text.

Як додати BSD License до проєкту

Типова структура:

project/
  LICENSE
  README.md
  src/

У `LICENSE` додають текст конкретної BSD-ліцензії: BSD-2-Clause або BSD-3-Clause.

У `README.md` можна написати:

## License

This project is licensed under the BSD 3-Clause License. See the LICENSE file for details.

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

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

Або:

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

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

Third-party notices

Якщо продукт використовує BSD-licensed код, зазвичай потрібно зберегти license notices у third-party notices.

Це може бути:

`THIRD_PARTY_NOTICES.txt`;
розділ Legal у застосунку;
документація;
About screen;
license bundle;
firmware notices;
web page з open source notices;
package metadata.

Важливо: навіть permissive-ліцензії не означають “можна видалити всі згадки про автора”.

BSD License у package metadata

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

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

{
  "license": "BSD-3-Clause"
}

Приклад для Python `pyproject.toml`:

[project]
license = "BSD-2-Clause"

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

[package]
license = "BSD-3-Clause"

Практична роль: package metadata допомагає автоматичним інструментам перевіряти ліцензії dependencies.

BSD License і GitHub

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

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

contributors;
dependency scanners;
package users;
open source compliance;
SBOM;
legal review;
автоматичного визначення ліцензії;
прозорості проєкту.

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

BSD License і комерційні продукти

BSD License часто зручна для комерційних продуктів.

Причини:

дозволяє proprietary use;
не вимагає відкривати похідний код;
коротка;
зрозуміла;
сумісна з багатьма політиками;
не створює copyleft-обов’язків;
зручна для embedded і enterprise;
добре підходить для libraries;
дозволяє продаж продукту.

Перевага: BSD License дозволяє open source-коду жити і в відкритих, і в закритих продуктах без складної взаємності.

BSD License і університети

BSD License історично пов’язана з університетською й дослідницькою культурою.

Вона зручна для:

академічних проєктів;
дослідницького коду;
reference implementations;
університетських бібліотек;
networking research;
operating systems research;
навчального коду;
спільного використання між індустрією й академією.

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

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

BSD License важлива для операційних систем і системного ПЗ.

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

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

Практична роль: BSD License дозволила системному коду широко поширюватися між open source і commercial ecosystems.

BSD License і безпека

Ліцензія не гарантує безпеку коду.

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

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

Критично: BSD License відповідає на питання “чи можна використовувати код”, але не відповідає на питання “чи безпечний цей код”.

Патенти

Класичні BSD-2-Clause і BSD-3-Clause не мають такої явної й детальної patent grant-мови, як Apache License 2.0.

Це важливо для:

великих компаній;
patent-sensitive projects;
стандартів;
multimedia;
hardware/software products;
corporate compliance;
open source governance;
contributors.

Важливо: якщо патентні питання критичні, варто розглянути Apache License 2.0 або BSD-2-Clause-Patent і проконсультуватися з фахівцем.

BSD License і SaaS

BSD License дозволяє використовувати код у SaaS-продуктах без обов’язку відкривати власний server-side код.

Це зручно для:

web services;
APIs;
internal services;
cloud platforms;
hosted applications;
developer tools;
backend libraries;
monitoring services;
commercial SaaS.

Практична роль: BSD License не має AGPL-style network copyleft, тому не вимагає відкривати server-side зміни лише через мережеве використання.

Переваги BSD License

Основні переваги BSD License:

permissive;
коротка;
зрозуміла;
дозволяє commercial use;
дозволяє proprietary use;
не вимагає відкривати похідний код;
має стандартні SPDX identifiers;
добре підходить для libraries;
зручна для academic code;
зручна для системного ПЗ;
широко сумісна з іншими ліцензіями;
BSD-3-Clause має non-endorsement захист;
проста для compliance порівняно з copyleft-ліцензіями.

Головна перевага: BSD License робить код дуже легким для повторного використання майже в будь-якому продукті.

Обмеження BSD License

BSD License має обмеження.

Можливі проблеми:

не змушує відкривати похідний код;
не гарантує повернення покращень у open source;
класичні BSD-2/3 не мають детального patent grant;
стара BSD-4-Clause має незручну advertising clause;
термін “BSD License” може бути неоднозначним;
не дає гарантій якості;
не дає підтримки;
потребує правильного збереження notices;
може бути занадто permissive для проєктів, які хочуть copyleft.

Помилка: обирати BSD License, якщо головна мета — змусити всі похідні роботи залишатися open source.

Коли варто використовувати BSD License

BSD License добре підходить, якщо потрібно:

дозволити широке повторне використання;
дозволити commercial use;
дозволити proprietary use;
мати коротку стандартну ліцензію;
опублікувати library;
опублікувати системний інструмент;
поділитися академічним кодом;
зробити SDK;
мінімізувати license friction;
уникнути copyleft-вимог;
дозволити інтеграцію в open source і closed source продукти.

Практична порада: BSD-2-Clause добре підходить, коли потрібна максимальна простота, а BSD-3-Clause — коли важливо додати non-endorsement clause.

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

BSD License може бути не найкращим вибором, якщо:

потрібно, щоб похідний код обов’язково залишався open source;
потрібен strong copyleft;
потрібен AGPL-style захист для SaaS;
потрібен детальний patent grant;
проєкт не хоче дозволяти proprietary forks;
важливо, щоб усі downstream-покращення поверталися спільноті;
потрібна сувора trademark policy;
потрібні складні contributor terms.

Важливо: BSD License — це вибір на користь свободи downstream-користувача, навіть якщо цей користувач закриє свій похідний код.

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

Рекомендовано:

точно вказувати `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 проста, але її потрібно називати точно й зберігати всі notices.

Типові помилки початківців

Поширені помилки:

писати просто “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.

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

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

BSD License — це не одна ліцензія, а сімейство BSD-style ліцензій.
Найпоширеніші сучасні варіанти — BSD-2-Clause і BSD-3-Clause.
BSD-3-Clause додає non-endorsement clause.
Стара BSD-4-Clause мала advertising clause, яка виявилася незручною.
BSD License дозволяє використовувати код у proprietary products.
BSD License не є copyleft-ліцензією.
BSD-style ліцензування сильно вплинуло на UNIX-like системи, мережевий код і комерційне ПЗ.
SPDX License List подає стандартизовані identifiers і canonical URLs для BSD-ліцензій. :contentReference[oaicite:4]{index=4}
BSD-2-Clause дуже близька за духом до MIT License.
Для юридичної точності краще писати `BSD-2-Clause` або `BSD-3-Clause`, а не просто “BSD License”.

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

Приклади сценаріїв використання

Open source library

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

Академічний проєкт

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

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

Команда створює системний інструмент і хоче, щоб його могли включати в різні UNIX-like системи, зокрема proprietary.

Embedded product

Компанія використовує BSD-licensed компонент у firmware пристрою й додає license notice у third-party notices.

Commercial SDK

Компанія відкриває SDK під BSD-3-Clause, щоб інші могли легко інтегруватися з її платформою, але не використовували назву компанії для endorsement без дозволу.

Підказка: якщо хочете максимальну простоту — дивіться BSD-2-Clause; якщо хочете захист від endorsement — BSD-3-Clause.

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

Для BSD-2-Clause:

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

Для BSD-3-Clause:

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

Важливо: SPDX identifier має відповідати реальному тексту ліцензії у файлі `LICENSE`.

Приклад license metadata

Для npm:

{
  "license": "BSD-3-Clause"
}

Для Cargo:

[package]
license = "BSD-2-Clause"

Для Python:

[project]
license = "BSD-3-Clause"

Практична роль: правильна metadata зменшує ручну роботу під час dependency audit і license compliance.

Джерела

SPDX License List.
SPDX: BSD 2-Clause "Simplified" License.
OSI: BSD 2-Clause License.
OSI: BSD 3-Clause License.
FreeBSD materials about BSD-style licensing.
Документація щодо permissive licenses.
Матеріали щодо open source compliance, SBOM, third-party notices, copyright notices, warranty disclaimers і license compatibility.
Матеріали щодо BSD Unix, FreeBSD, OpenBSD, NetBSD і BSD-style software ecosystems.

Висновок

BSD License — це сімейство permissive open source-ліцензій, які дозволяють широко використовувати, змінювати й поширювати код, зокрема в комерційних і proprietary-продуктах. Найчастіше використовують BSD-2-Clause і BSD-3-Clause. BSD-2-Clause є простішою, а BSD-3-Clause додає non-endorsement clause.

BSD License добре підходить для бібліотек, SDK, системного ПЗ, академічного коду, embedded-компонентів і проєктів, де автор хоче мінімізувати обмеження для downstream-користувачів. Водночас вона не є copyleft-ліцензією, не вимагає відкривати похідний код і не гарантує повернення покращень у спільноту.

Головна думка: BSD License — це проста permissive-ліцензія з великим рівнем довіри до користувача: використовуйте код вільно, але зберігайте notices, disclaimer і не приписуйте авторам endorsement без дозволу.