Audyt praw do oprogramowania

Zakres audytu

Zaczynamy od mapy produktu i osób uczestniczących w jego tworzeniu: pracowników, współpracowników B2B, software house’ów, podwykonawców i dostawców komponentów. Sprawdzamy dokumenty dotyczące rezultatów prac, licencje oraz łańcuch przekazania materiałów. Rezultatem może być raport zakresu, lista brakujących dokumentów, rejestr ryzyk i plan działań priorytetowych.

Audyt nie jest analizą kodu źródłowego pod kątem błędów, cyberbezpieczeństwa, wydajności ani zgodności licencji open source na poziomie technicznego skanowania. Jeżeli te badania są potrzebne, określamy osobno ich rolę oraz współpracę z odpowiednim ekspertem.

Co bywa istotne

Znaczenie mają nie tylko główne umowy. W praktyce potrzebne mogą być zamówienia, protokoły, regulaminy repozytoriów, licencje bibliotek, dokumentacja klienta i ustalenia o dalszym rozwoju produktu. Weryfikujemy je względem celu: sprzedaży spółki, finansowania, wdrożenia u klienta albo zmiany dostawcy.

Jak przekazać materiał

Nie przesyłaj repozytorium, danych dostępowych ani kodu przez publiczny formularz. Po wstępnym ustaleniu możliwości współpracy uzgadniamy zakres i bezpieczny kanał dokumentów.

Proces i wynagrodzenie

Najpierw ustalamy cel audytu, podmioty uczestniczące w projekcie, termin i konflikt interesów. Potem uzgadniamy obszar dokumentów, rezultat oraz sposób bezpiecznego udostępnienia danych. Wycena zależy od liczby podmiotów i umów, historii produktu, komponentów zewnętrznych, celu transakcyjnego oraz wymaganej formy raportu. Nie obejmuje technicznego badania repozytorium.

Pytania klientów

Czy audyt wymaga udostępnienia kodu źródłowego?

Nie zawsze. Zaczynamy od dokumentów i mapy produktu; techniczny dostęp ustala się tylko, gdy jest potrzebny i bezpieczny.

Czy umowa B2B automatycznie przenosi prawa do kodu?

Nie należy tego zakładać. Znaczenie ma treść konkretnej umowy, sposób powstania rezultatów i właściwe przepisy.

Czy audyt obejmuje licencje open source?

Zakres licencji i dokumentów ustalamy na początku. Techniczny skan komponentów nie jest elementem domyślnego audytu prawnego.

Czy brak jednego dokumentu kończy audyt?

Nie, ale może wskazać ryzyko lub konieczność dalszych wyjaśnień.

Czy można wysłać dostęp do repozytorium przez formularz?

Nie. Nie przekazuj dostępów ani kodu w formularzu publicznym.

Ustalanie zakresu badania

Audyt staje się użyteczny dopiero wtedy, gdy wiadomo, do czego ma służyć. Przed sprzedażą spółki istotne może być uporządkowanie tytułów prawnych i otwartych ryzyk. Przed wdrożeniem u klienta pytanie częściej dotyczy zakresu korzystania, modyfikacji i przekazania rezultatów. W obu sytuacjach mapa produktu pozwala ustalić priorytety zamiast traktować wszystkie dokumenty jednakowo.

W raporcie oddzielamy potwierdzone informacje od kwestii wymagających dokumentu, wyjaśnienia lub decyzji biznesowej. To pozwala klientowi zdecydować, czy należy uzupełnić umowę, uzyskać potwierdzenie od współtwórcy albo ograniczyć deklaracje wobec nabywcy. Nie przedstawiamy braku dokumentu jako automatycznej utraty praw ani nie przesądzamy skutku bez analizy jego treści.

Przykładowa sytuacja

Produkt rozwijał pracownik i zewnętrzny wykonawca, a firma chce udzielić klientowi szerokich uprawnień. Pierwszy etap audytu może ustalić, których dokumentów dotyczą oba strumienie prac i jakie pytania pozostają otwarte. Przykład jest hipotetyczny.

Granice usługi

Audyt nie jest gwarancją pełnego tytułu prawnego ani ubezpieczeniem transakcji. Opiera się na udostępnionych dokumentach i ustalonym zakresie; nowe informacje, umowy lub elementy produktu mogą wymagać odrębnego rozszerzenia badania.

Przed rozpoczęciem prac warto wskazać jedną osobę koordynującą dokumenty po stronie klienta. Pozwala to ograniczyć wielokrotne przesyłanie wersji plików oraz jasno oznaczać, które informacje wymagają potwierdzenia przez twórcę, kontrahenta lub dział biznesowy.