Czym więc różnią się te umowy? Dwoma podstawowymi parametrami – trwałością nabytego uprawnienia oraz wspomnianym pozbawieniem twórcy praw do kodu w przypadku przeniesienia praw. Trwałość jest – z punktu widzenia prawnika – największą różnicą. Przeniesienie praw jest transakcją jednorazową, a skutek tej transakcji jest prosty – wczoraj prawa były po stronie A, dziś są po stronie B. B jest „właścicielem” kodu. Pomijając rzadką możliwość odstąpienia od umowy, A nie ma już wpływu na dysponowanie programem przez B. W przypadku licencji zawsze istnieje ryzyko jej wypowiedzenia lub wygaśnięcia – zapomina się m.in. o tym, że o ile umowa nie stanowi inaczej, licencja automatycznie wygasa po pięciu latach.

Jeżeli jest udzielona na czas nieoznaczony, można ją wypowiedzieć – twórca może to zrobić z rocznym terminem wypowiedzenia na koniec roku kalendarzowego, chyba że umowa ten termin zmieni. W interesie zamawiającego jest wprowadzenie jak najdłuższego terminu wypowiedzenia, choć termin absurdalnie długi (99 lat) zostałby zapewne uznany za próbę obejścia prawa. Niestety nie da się stworzyć takiej licencji na czas nieoznaczony, która byłaby niewypowiadalna. Choć, jak słusznie wskazał Trybunał Sprawiedliwości UE, transakcja taka – jeżeli zapłata za licencję jest jednorazowa i uiszczona z góry – jest zbliżona do umowy sprzedaży, polskie przepisy traktują licencję jako zobowiązanie ciągłe i możliwość przerwania tego zobowiązania jest wbudowana w jego konstrukcję. W przypadku zgody na umowę licencyjną, zamawiający musi zabezpieczyć to ryzyko – jest ku temu kilka środków, od zobowiązania do niewypowiadania, przez długie okresy wypowiedzenia, po kary umowne. To, o czym się często zapomina, to „zaszyta” w wielu umowach możliwość natychmiastowego wypowiedzenia w przypadku naruszenia praw licencyjnych. O ile sama zasada jest trudna do zakwestionowania, to termin natychmiastowy, np. w przypadku systemu ERP, jest z punktu widzenia biznesu nie do zaakceptowania. Zapłata odszkodowania jest zrozumiała, ale konieczność wyłączenia systemu z dnia na dzień (nawet jeżeli naruszono warunki licencji) zazwyczaj nie jest możliwa – minimum przyzwoitości to okres wypowiedzenia pozwalający na migrację do nowego systemu.

Zobacz również:

• Klienci Google Cloud i Workspace otrzymają od firmy ochronę w pozwach o naruszenie praw autorskich
• Rząd Ghany pracuje nad regulacjami dotyczącymi AI

Po to, żeby bardziej skomplikować sytuację, nie ma jasności co się dzieje z licencjami w przypadku sprzedaży praw majątkowych przez licencjodawcę czy w przypadku wypowiedzenia licencji dystrybutorowi, który wcześniej udzielił sublicencji zamawiającemu. Jest poważne ryzyko, że umowy licencyjne (sublicencyjne) wygasają.

Czy powyższe zagrożenia powinny skłaniać nas do nabycia praw zamiast licencji? Wydaje się, że wyłącznie w skrajnych przypadkach, kiedy system jest kluczowy i ryzyko tego typu byłoby nie do zaakceptowania. Bywa tak przy dedykowanych umowach. Mimo że z teoretycznego punktu widzenia ryzyko jest istotne i, co gorsza, nie do zabezpieczenia w 100%, to jak pokazuje praktyka w rzeczywistości nie jest aż tak groźne. Mieliśmy wiele przejęć i transferów na rynku IT i nie znam przypadku, kiedy nabywca próbował dowieść użytkownikowi, że prawa licencyjne wygasły. Znam jednak przypadki, że groźba wypowiedzenia licencji była użyta przez dostawcę w sporze z klientem, nawet wtedy, gdy spór ten dotyczył umów serwisowych a nie samej licencji. Ale rozsądny mechanizm umowy, z odpowiednio długim okresem wypowiedzenia wydaje się wystarczająco zabezpieczać interesy zamawiającego.

Mniej „prawna”, ale nie mniej istotna jest druga różnica, czyli utrudnienie rozpowszechniania kodu. Nie da się ukryć, że w czasie wdrożeń dostawca zapoznaje się z przedsiębiorstwem zamawiającego i informacjami poufnymi. Niejednokrotnie prawdziwy know how w projekt wdrożeniowy wnosi nie dostawca, a właśnie zamawiający. W takiej sytuacji może mu zależeć, żeby rozwiązanie wdrożone w jego firmie, w szczególności przebieg procesów, nie został przekazany konkurencji w kolejnym wdrożeniu. Prawa do tej warstwy „kastomizacyjnej” stosunkowo często przenosi się na zamawiającego – w ten sposób uniemożliwiając proste powielenie kodu w innym projekcie. Oczywiście to tylko półśrodek, bo nie blokuje możliwości wykorzystania przez dostawcę zdobytej wiedzy i doświadczenia – ale przynajmniej wymusza dość istotny wysiłek ponownego kodowania. Oczywiście warto go połączyć z klauzulą zakazu konkurencji.

Czy jest wyjście pośrednie? Poniekąd takim rozwiązaniem jest nabycie udziału w prawie, coś na kształt współwłasności. Wymaga to zawarcia dość wyrafinowanej umowy opisującej sposób korzystania ze wspólnego prawa, ale gwarantuje, że i dostawca i zamawiający są „właścicielami” kodu – znika ryzyko wypowiedzenia, pozostają bardzo szerokie możliwości dysponowania kodem (jeśli się dobrze umowę napisze). Oczywiście konstrukcja ta nie załatwia problemu poufności, ale ten można zabezpieczyć przez odpowiednie postanowienia umowne.

Podsumowując: zbyt często widzę SIWZ-y czy negocjacje, których celem jest nabycie praw. Bardzo często argumentem za takim SIWZ-em czy wymaganiem jest „prawo do modyfikacji i swobodnego rozwoju systemu”. To nieporozumienie – prawo modyfikacji bez problemu można nabyć umową licencyjną (pytanie czy warto, ale to kwestia i biznesowa, i faktycznej możliwości modyfikacji, jak i samej architektury – nikt nie modyfikuje bezpośrednio kodu SAP). Prawa warto nabywać, jeżeli opracowujemy własny produkt oraz w tych przypadkach, kiedy na 100% chcemy wykluczyć ryzyko wypowiedzenia czy wygaśnięcia umowy oraz jako instrument pomocniczy przy kontroli poufności przekazanych dostawcy informacji.