BSD 2-Clause: prosta licencja dla przenośnego kodu

BSD 2-Clause to permisywna licencja pozwalająca używać kodu w produktach otwartych i zamkniętych. W odróżnieniu od BSD 3-Clause zawiera dwa warunki redystrybucji: zachowanie informacji prawnych w kodzie źródłowym oraz przekazanie ich w dokumentacji lub innych materiałach przy dystrybucji binarnej. OSI publikuje pełny tekst i identyfikator BSD-2-Clause.

Po co firmie tak krótka licencja?

Mały zestaw obowiązków ułatwia wykorzystanie biblioteki w wielu produktach. Firma może zmieniać kod i nie musi automatycznie publikować własnego produktu ani zmian w bibliotece. Jeśli przekazuje oprogramowanie dalej, musi zachować wymagane noty. To ważne również wtedy, gdy dostarcza wyłącznie skompilowany obraz urządzenia, kontener lub aplikację instalowaną u klienta. Nie należy usuwać not tylko dlatego, że kod nie trafia do repozytorium odbiorcy.

BSD 2-Clause nie zawiera trzeciej klauzuli zakazującej używania nazw autorów do rekomendowania produktu; BSD 3-Clause ma ją wprost. Nie wyciągaj z tego jednak wniosku, że można dowolnie używać cudzych znaków towarowych lub tworzyć mylącą reklamę. Prawa do marki i warunki licencji kodu są odrębnymi zagadnieniami.

Suwerenność a możliwość zamknięcia forka

BSD 2-Clause daje firmie możliwość przejęcia utrzymania krytycznej biblioteki. Kod można skopiować, zbudować i uruchomić bez zgody pierwotnego dostawcy. Równocześnie konkurent może zamknąć swoje udoskonalenia. Oznacza to, że otwarta baza nie zawsze obejmie funkcje używane przez klientów płatnej edycji. Gdy oceniasz AI OS, porównuj zakres funkcji repozytorium z faktyczną usługą, a nie jedynie nazwę licencji na stronie produktu.

Przykład: silnik indeksowania jest BSD, ale panel administracyjny i mechanizm replikacji są zamknięte. Możesz forkować silnik, lecz odtworzenie całego produktu wymaga dodatkowej pracy. Vendor lock-in powstaje w otoczce, integracjach i danych. Sprawdź format eksportu oraz interfejs API przed wyborem.

Kontrola w AI SDLC

Agent kodujący może pobrać bibliotekę i skopiować plik do projektu. Kontrola zależności powinna wtedy zachować jej pochodzenie, dokładną wersję i notę licencyjną w artefakcie wydania. Zbuduj produkt od zera na drugim rejestrze pakietów. Jeśli kompilacja wymaga niedostępnych, prywatnych paczek, swoboda BSD nie przełożyła się na odtwarzalność.

BSD 2-Clause wybieraj dla prostego ponownego użycia i niskiego narzutu prawnego. MIT jest podobnie permisywna; przy ważnym ryzyku patentowym oceń Apache 2.0. Dla obowiązku udostępniania zmian w kodzie potrzebna jest inna rodzina licencji.

Scenariusz urządzenia edge AI

Producent pakuje bibliotekę BSD 2-Clause do urządzenia analizującego obraz. Odbiorca dostaje gotowy firmware, bez repozytorium źródeł całej aplikacji. To możliwe przy tej licencji, o ile producent spełnia warunki dotyczące informacji prawnych w materiałach do wydania. Sam fakt, że urządzenie działa lokalnie, nie oznacza, że klient potrafi je naprawić bez producenta. Potrzebne są także dokumentacja protokołu, eksport konfiguracji i droga aktualizacji firmware.

Jeśli klient wymaga prawa do samodzielnego rozwijania całego stosu, BSD 2-Clause dostawcy pozwala zamknąć warstwy dodane nad biblioteką. Warunek przetargowy powinien więc dotyczyć dostępu do konkretnych źródeł, danych i interfejsów, a nie wyłącznie użycia „oprogramowania open source”. Można wynegocjować dodatkowe prawa umową, nie zmieniając licencji pierwotnej biblioteki.

Co sprawdzić w procesie wytwarzania?

Wygeneruj SBOM dla wydania, potwierdź wersję biblioteki i umieść noty w dokumentacji produktu. Zbuduj firmware ponownie po aktualizacji zależności oraz sprawdź, czy test wyników modelu nie zmienił się przez modyfikację biblioteki. Wpisz też właściciela decyzji o przyszłym forku: prawo do forka ma niewielką wartość, gdy nikt w firmie nie zna kodu ani nie ma budżetu na utrzymanie.