Wpisy

Open 3D Engine albo jak używać oprogramowania open-source w grach

Część z czytelników zapewne już wie, że na rynku pojawił się nowy silnik 3D dedykowany tworzeniu gier wideo z segmentu AAA – Open 3D Engine (O3DE). Nie jest to w pełni nowy silnik – opiera się na zmodyfikowanej wersji silnika Amazon Games o nazwie Lumberyard (który z kolei jest zmodyfikowanym CryEngine). Ciekawym aspektem nowego silnika jest natomiast fakt, że nie tylko można z niego korzystać za darmo, ale jest również open-source.

To kolejny przypadek oprogramowania open-source dostępnego dla deweloperów gier wideo. Co zatem oznacza ‘open-source’ oraz o czym należy pamiętać tworząc gry z wykorzystaniem oprogramowania open-source? W ramach tego krótkiego artykułu, przybliżymy te kwestie na przykładzie O3DE.

Licencja open-source – jakie są konsekwencje?

W teorii, oprogramowanie open-source to rodzaj programu komputerowego, który jest rozpowszechniany (przez licencjodawcę) na podstawie licencji, która pozwala użytkownikowi (licencjobiorcy) używać (uzyskać dostęp), modyfikować i rozpowszechniać program komputerowy i jego kod źródłowy. Ułatwia to współpracę deweloperów (programistów) w procesie tworzenia oprogramowania i oszczędza programistom czas. W teorii brzmi to wspaniale, jednak w praktyce nie jest to takie proste. Nie każda licencja open-source daje taki sam poziom wolności.

Istnieją niezliczone licencje, które zalicza się do licencji open-source. Dla przykładu, lista licencji zaakceptowanych przez Open Source Initiative (czyli spełniających opracowaną przez OSI Open Source Definition) zawiera ponad 100 licencji (lista jest dostępna tutaj). Najpopularniejsze licencje, z jakimi można się spotkać w sieci (np. na GitHubie) to m.in. licencje Apache, BSD, GNU i MIT.

Wszystkie licencje zawarte we wspomnianej liście są uważane za open-source, jednakże warunki, na jakich udostępniają oprogramowanie różnią się, czasem znacznie. Licencje open-source często zawierają istotne ograniczenia, które mogą sprawić, że sposób, w który deweloper chce użyć oprogramowania będzie nielegalny. Dlatego pierwsza lekcja dotycząca licencji open-source jest następująca: zawsze sprawdzaj, na jakiej licencji jest rozpowszechniany określony program komputerowy (kod źródłowy, binarny).

Na jakich licencjach jest zatem rozpowszechniany Open 3D Engine?

Ogólne licencje Open 3D Engine – permisywny open-source

Gdy zajrzymy do repozytorium O3DE na GitHubie, w pliku ‘LICENSE.txt’ możemy znaleźć informację, że domyślną i ogólną licencją dla O3DE jest licencja Apache 2.0, ale deweloperzy mogą również wybrać korzystanie z O3DE na licencji MIT. Wszystkie przyszłe wkłady do repozytorium muszą być udostępnione na obu ze wspomnianych licencji. Na szczęście, zarówno licencja Apache 2.0, jak i MIT są dosyć liberalne. Zajrzyjmy do warunków obu licencji.

Apache 2.0

Licencja Apache 2.0 daje licencjobiorcy następujący zestaw praw:

„wieczysta, ogólnoświatowa, niewyłączna, bezpłatna, nieodwołalna licencja prawnoautorska na zwielokrotnianie, przygotowywanie Utworów Zależnych, publiczne wyświetlanie, publiczne wykonywanie, udzielanie sublicencji oraz rozpowszechnianie Utworu i takich Utworów Zależnych w formie źródłowej lub obiektowej”

(zwroty zapisane wielkimi literami są zdefiniowane w treści licencji).

Licencja przyznaje również licencjobiorcy prawo do korzystania z patentów (jeśli przedmiot licencji jest chroniony patentem), w bardzo podobnym zakresie.

Kopiowanie oprogramowania i jego kodu źródłowego (zmodyfikowanego lub nie) musi spełniać następujące wymagania:

  1. każdy odbiorca musi otrzymać kopię licencji (np. w formie pliku “license.txt” dołączonego do programu);
  2. każdy zmodyfikowany plik powinien być opatrzony informacją o dokonaniu modyfikacji;
  3. wszystkie wcześniejsze informacje dotyczące prawa autorskiego lub patentów dotyczące oprogramowania powinny być zachowane;
  4. należy dalej rozpowszechniać plik tekstowy „NOTICE”, zawierający wszystkie odpowiednie informacje o przypisaniu autorstwa.

W odniesieniu do wkładów, wszystkie wkłady do oprogramowania objętego licencją Apache są również uważane za objęte licencją Apache, chyba że osoba wnosząca wkład stwierdzi inaczej. W przypadku O3DE, ogólna licencja wymaga od deweloperów dzielenia się wkładem zarówno na licencji Apache 2.0 jak i MIT, więc ta zasada została zmodyfikowana przez ogólną licencję O3DE.

Licencja zawiera również postanowienia dotyczące używania znaków towarowych licencjodawcy (w skrócie: nie używaj znaku, jeśli nie masz na to wyraźnego pozwolenia), ograniczenia odpowiedzialności i gwarancji, a także instrukcje, jak zastosować licencję Apache do utworu stworzonego przez licencjobiorcę.

Nic w licencji nie ogranicza wykorzystania kodu źródłowego w projektach komercyjnych. W skrócie, licencja Apache wymaga umieszczenia w swoim oprogramowaniu informacji o tym, że w jego ramach wykorzystywane jest oprogramowanie objęte licencją Apache; informacji o tym, że takie oprogramowanie zostało zmodyfikowane (jeśli zostało), wszystkich informacji przypisujących autorstwo oraz kopii tekstu licencji. Nie musicie publicznie udostępniać modyfikacji ani żadnej innej części kodu źródłowego.

MIT

Na pierwszy rzut oka, licencja MIT jest dużo prostsza i zdecydowanie krótsza niż licencja Apache 2.0. Licencja daje bezpłatnie prawa „każdej osobie, która otrzyma kopię niniejszego oprogramowania i związanych z nim plików dokumentacji („Oprogramowanie”), do nieograniczonego obrotu Oprogramowaniem, włączając w to bez ograniczeń prawa do używania, kopiowania, modyfikowania, łączenia, publikowania, rozpowszechniania, udzielania sublicencji lub sprzedaży kopii Oprogramowania, oraz do zezwalania na to osobom, którym Oprogramowanie zostało dostarczone”.

Zgoda na korzystanie z oprogramowania w sposoby wskazane powyżej zostaje udzielona pod wyłącznie jednym warunkiem: „Powyższa informacja o prawach autorskich [czyli: informacja określająca, kto jest posiadaczem praw autorskich do oprogramowania – w tym przypadku „Copyright Contributors to the Open 3D Engine”] oraz niniejsza informacja o zezwoleniu powinny być włączone do wszystkich kopii lub istotnych części Oprogramowania”.

W skrócie: możesz korzystać z kodu źródłowego rozpowszechnianego na licencji MIT i modyfikować go, również w produktach komercyjnych, tak długo, jak Twoje oprogramowanie zawiera pełny tekst informacji o prawach autorskich oraz informacji o zezwoleniach.

Copyleft i wtyczki do silnika – na co zwrócić uwagę

Niestety, nie każde oprogramowanie open-source jest rozpowszechniane na tak liberalnych licencjach jak MIT czy Apache 2.0. Deweloperzy muszą być szczególnie świadomi istnienia tzw. licencji „copyleft”, z których najpopularniejsze są licencje z rodziny GNU GPL. Problemów związanych z licencjami copyleft jest zbyt wiele, by omówić je w tym krótkim artykule, jednak ponieważ tekst licencji O3DE omawia te zagadnienia oraz ze względu na ryzyko z tym związane, krótki opis jest niezbędny.

Ogólnie rzecz biorąc, licencje typu copyleft to licencje, które zawierają wymóg, aby utwory zależne stworzone w oparciu o utwór rozpowszechniany na takich licencjach były rozpowszechniane na tych samych warunkach (tej samej licencji) W skrócie oznacza to, że jeżeli wykorzystasz w programie komputerowym kod źródłowy objęty licencją copyleft, to w związku z regułą, która czasami nazywana jest „wirusem copyleft”, możesz zostać zobowiązany do rozpowszechniania swojego programu (reszty kodu) na tej samej licencji copyleft, na przykład za darmo. Takie „zakażenie” to ogromne ryzyko dla oprogramowania własnościowego (komercyjnego) i jest ono również w pewnym stopniu obecne w przypadku Open 3D Engine.

W tekście licencji O3DE znajduje się bardzo ważne zastrzeżenie, które cytujemy w całości poniżej (w języku angielskim):

Open 3D Engine requires the use of (and in some cases makes available to you) software and assets that have been developed by third parties and are subject to separate license terms (such as code licensed under other open source licenses). It is your responsibility to comply with the applicable licenses. Information on third party materials, and the applicable license terms, are referenced in or included with the materials, such as in separate LICENSE.txt files accompanying the materials.

Please note that certain materials are subject to „copyleft” licenses, which require distribution of source code, including:

– Qt Toolkit https://github.com/qtproject/, which is subject to the GNU Lesser General Public License version 3 (with certain exceptions). A copy of the source code for Qt Toolkit may be found at https://s3-us-west-2.amazonaws.com/ly-legal/LicenseConformance/Qt/Src.zip

– The AWS Python SDK uses Chardet https://chardet.github.io/, which is subject to the GNU Lesser General Public License version 2.1. A copy of the source code may be found at https://github.com/chardet/chardet.

Oznacza to, że chociaż O3DE jest oprogramowaniem open-source i jest rozpowszechniany na dość liberalnych licencjach, może wymagać (i wymaga) użycia oprogramowania i materiałów, które mogą podlegać oddzielnym warunkom licencyjnym, w tym również być objęte znacznie bardziej rygorystycznymi licencjami. Zanim zdecydujesz się na korzystanie z O3DE, dokładnie przejrzyj repozytorium w poszukiwaniu innych licencji.

Tekst licencji dostarcza dwa przykłady takich materiałów (Qt Toolkit i Chardet), które są rozprowadzane na licencji GNU LGPL (v. 2.1 i 3.0). W przeciwieństwie do licencji GNU GPL, w uproszczeniu licencja LGPL zezwala na użycie biblioteki objętej licencją LGPL w produktach własnościowych (nierozpowszechnianych na licencji open-source), o ile powstały utwór nie stanowi utworu zależnego względem utworu objętego licencją LGPL. Jest kwestią dyskusyjną, czy w konkretnym przypadku powstałby utwór zależny, ale generalnie przyjmuje się, że dynamiczne linkowanie do biblioteki nie tworzy utworu zależnego, a raczej oprogramowanie jest wówczas – używając języka licencji – „utworem wykorzystującym Bibliotekę”. Prawdopodobnie miałoby to miejsce w powyższym przypadku, gdyż silnik zapewne korzysta z zewnętrznych narzędzi i nie włącza ich kodu źródłowego bezpośrednio do reszty oprogramowania, ale należy poczynić istotne zastrzeżenie: każdy przypadek jest inny i w konkretnym przypadku przedstawiona interpretacja może się różnić.

Jak widać, wykorzystywanie materiałów objętych licencjami copyleft w prawnie zastrzeżonych utworach jest istnym prawnym polem minowym. Ogólna lekcja jest taka, że zawsze należy sprawdzić, jakie inne licencje wchodzą w grę w określonym przypadku i czy pozwalają one na korzystanie z oprogramowania w zaplanowany sposób oraz jak mogą wpłynąć na inne części tworzonego oprogramowania.

Co do zasady, jeśli to możliwe, zaleca się unikanie stosowania licencji typu copyleft w oprogramowaniu własnościowym. Jeśli zamierzacie wykorzystać oprogramowanie typu copyleft w swoim oprogramowaniu, zalecamy skonsultowanie się z prawnikiem specjalizującym się w prawie własności intelektualnej i – co najmniej – bardzo dokładne przeanalizowanie warunków licencji przed podjęciem decyzji o jego wykorzystaniu.

Podsumowanie

Istnieje niezliczona ilość różnych licencji, które mogą mieć zastosowanie w przypadku oprogramowania open-source, a jeśli deweloper chce dodatkowo korzystać z oprogramowania na „zamkniętych” (własnościowych) licencjach obok oprogramowania stworzonego samodzielnie i oprogramowania open-source, dodaje to kolejną warstwę problemów, ponieważ każde oprogramowanie własnościowe ma odrębne zasady jego wykorzystania. Zarządzanie wykorzystaniem oprogramowania osób trzecich w projekcie deweloperskim jest więc sprawą złożoną, wymagającą dokładnego zbadania i starannego podejścia.

Rekomendowaną praktyką jest stworzenie listy całego wykorzystanego oprogramowania osób trzecich (ze wskazaniem wykorzystywanych licencji) i stworzenie wytycznych dotyczących tego, jakie licencje są akceptowalne, a jakie nie. Najważniejszym momentem w procesie zarządzania licencjami jest moment, w którym oprogramowanie (gra wideo, ale również każda kolejna jej aktualizacja) zostaje udostępnione publicznie. W tym momencie, każdy licencjodawca może potencjalnie dowiedzieć się, że deweloperzy wykorzystali jego kod w nieprawidłowy sposób. Rekomendujemy przeanalizowanie kodu pod tym kątem przynajmniej raz przed każdą taką publikacją. Wiele licencji open-source wymaga co najmniej wskazania autorstwa licencjodawcy, zatem taki wewnętrzny audyt będzie niezbędny do zrealizowania choćby tego obowiązku.

Jeśli napotkacie jakiekolwiek problemy w korzystaniu z O3DE lub jakiegokolwiek innego oprogramowania open-source w ramach Waszych projektów, rekomendujemy skontaktowanie się z prawnikami, na przykład z zespołem LegalPlay w ramach kancelarii KL&M LAW.