MPL 2.0: copyleft na poziomie pliku w firmowym AI

MPL 2.0 jest kompromisem: pozwala połączyć objęty nią kod z własnym zamkniętym produktem, ale przy dystrybucji wymaga udostępnienia źródeł zmodyfikowanych plików objętych MPL. Mozilla opisuje ten mechanizm jako copyleft na poziomie pliku. Zakres wynika z pełnego tekstu MPL 2.0, a nie z ogólnego stwierdzenia „weak copyleft”.

Jak działa granica pliku?

Jeśli firma poprawia plik objęty MPL i przekazuje program odbiorcy, powinna udostępnić odpowiedni kod tego pliku na warunkach MPL. Może jednocześnie dodać osobne, własne pliki w większym dziele na innych warunkach, także zamkniętych, jeśli spełnia zasady licencji. To różni MPL od silnego copyleft dla całego objętego dzieła. Nie należy jednak sztucznie przenosić drobnych zmian między plikami tylko po to, aby obejść obowiązki; sprawdź faktyczny zakres kodu i dystrybucji.

MPL zawiera postanowienia patentowe i warunki dotyczące udostępniania kodu źródłowego przy przekazywaniu formy wykonywalnej. Zwróć uwagę na warianty nagłówków plików, w tym ewentualną niezgodność z „Secondary Licenses”. Nie zakładaj automatycznej zgodności każdej kombinacji MPL i GPL. W razie mieszania licencji przygotuj przegląd konkretnych plików oraz ich historii.

Suwerenność bez obowiązku otwarcia całej aplikacji

Gdy wiele firm poprawia wspólną bibliotekę MPL, zmiany w jej plikach mogą wracać do odbiorców. To zwiększa szansę, że wspólna baza nie zniknie za komercyjnymi forkami. Firma zachowuje możliwość rozwijania własnych modułów. Ten balans bywa dobry dla sterowników, komponentów desktopowych lub części platformy danych, które mają wspólny rdzeń i konkurujące produkty wokół niego.

MPL nie usuwa vendor lock-in z usług. Przykład: serwer indeksowania ma rdzeń MPL, ale połączenie z modelem wymaga prywatnego API. Można przejąć kod rdzenia, lecz niekoniecznie odtworzyć cały produkt. Zapisz oddzielnie licencję kodu, format danych, interfejs modelu i proces aktualizacji.

Test przed wdrożeniem

Zbuduj listę plików MPL, które firma zmieniła. Dla wydania binarnego sprawdź, czy odbiorca ma dostęp do właściwych źródeł i informacji licencyjnych. Następnie odtwórz usługę bez konsoli pierwotnego dostawcy. Jeśli brakujące funkcje są w zamkniętym dodatku, policz koszt jego zastąpienia. Apache 2.0 daje większą swobodę zamykania zmian; GPLv3 stawia szerszy obowiązek dla objętego dzieła.

Scenariusz współpracy kilku firm

Trzech producentów buduje wspólny moduł synchronizacji danych. Każdy ma własną aplikację nad nim. MPL 2.0 może zachęcić do oddawania poprawek we wspólnych plikach, gdy produkt jest dystrybuowany, bez wymogu publikowania całej aplikacji. Dzięki temu jeden dostawca nie musi być jedynym opiekunem rdzenia. Aby ten efekt zaistniał, moduł musi być faktycznie objęty MPL, a wkład autorów poprawnie udokumentowany. Samo repozytorium na GitHubie nie ustala praw do wszystkich plików.

Jeżeli wspólny rdzeń będzie oferowany tylko jako usługa, MPL nie daje tej samej ochrony zdalnym użytkownikom co AGPL. Wtedy suwerenność zależy głównie od dostępu do kodu publikowanego dobrowolnie, umów i możliwości eksportu danych. AGPLv3 ma odmienny mechanizm związany z interakcją sieciową zmodyfikowanego programu.

Przy łączeniu MPL z innymi licencjami nie stosuj schematu „wszystkie słabe copyleft są zgodne”. Zapisz licencję każdego pliku, sprawdź nagłówki i specjalne wyłączenia, a następnie przeanalizuj faktyczną paczkę wydania. W ekosystemie Eclipse podobny cel może realizować EPL 2.0, ale jej definicje wkładu i modułu są inne.