Licencja MIT pozwala robić z kodem prawie wszystko: używać, zmieniać, łączyć z własnym kodem, sprzedawać i sublicencjonować. Warunek jest jeden: nota o prawach autorskich i tekst licencji muszą zostać we wszystkich kopiach lub istotnych częściach kodu.
Licencja GPL daje te same swobody, ale z warunkiem copyleft. Jeśli przekazujesz komuś program zawierający kod na GPL, cały program musisz udostępnić na GPL razem z kodem źródłowym.
Dla software house’u to pytanie praktyczne. Przekazujesz kod klientowi, obiecujesz mu prawa i czasem licencjonujesz własne moduły. Komponent GPL w złym miejscu może podważyć każdą z tych trzech rzeczy.
Czym różni się licencja MIT od licencji GPL?
| MIT | GPL v3 | AGPL v3 | Apache 2.0 | |
|---|---|---|---|---|
| Użycie komercyjne | Tak | Tak | Tak | Tak |
| Zmiany i łączenie z własnym kodem | Tak | Tak | Tak | Tak |
| Warunek przy przekazaniu kopii | Nota i tekst licencji | Cały program na GPL plus kod źródłowy | Jak GPL | Tekst licencji, oznaczenie zmian, plik NOTICE (sekcja 4) |
| Obowiązek przy SaaS | Brak | Brak, jeśli nie przekazujesz kopii | Kod źródłowy dla użytkowników sieci (sekcja 13) | Brak |
| Licencja patentowa | Brak wprost | Tak (sekcja 11) | Tak | Tak (sekcja 3) |
Do tego dochodzą licencje pośrednie, na przykład LGPL. Pozwala łączyć bibliotekę z kodem zamkniętym, jeśli użytkownik może podmienić bibliotekę na swoją wersję.
Kiedy GPL wymusza otwarcie twojego kodu?
Obowiązki z GPL v3 powstają, gdy przekazujesz kopię programu innym (w tekście licencji „convey”). Wtedy musisz:
- udostępnić cały program na GPL, jeśli twój kod jest z komponentem GPL połączony w jeden utwór (sekcja 5),
- dostarczyć albo zaoferować pełny kod źródłowy w formie, w której da się go zmieniać (sekcja 6),
- nie nakładać dodatkowych ograniczeń na odbiorcę (sekcja 10).
Sam użytek wewnętrzny nie jest przekazaniem. Narzędzie na GPL, którego zespół używa do budowania projektu, nie zmienia licencji tego, co budujesz. Kompilator czy linter zostaje u ciebie i nie trafia do produktu.
Co GPL znaczy, kiedy przekazujesz kod klientowi?
Przekazanie aplikacji klientowi to przekazanie kopii programu. Jeśli w środku jest komponent GPL połączony z twoim kodem, klient dostaje cały program na GPL. Z tego wynikają trzy problemy:
- Przeniesienie praw. Przeniesiesz na klienta autorskie prawa majątkowe do kodu, który napisał twój zespół. Komponentu GPL nie przeniesiesz, bo nie masz do niego praw. Klient dostaje go tylko na warunkach GPL.
- Gwarancje w umowie. Jeśli umowa mówi, że klient może dowolnie zamknąć i sprzedawać system, a w środku jest GPL, składasz obietnicę, której nie dotrzymasz.
- Produkt klienta. Jeśli klient sprzedaje twój system dalej jako zamknięte oprogramowanie, sam narusza GPL. Spór z autorami komponentu szybko stanie się sporem z tobą.
Dlatego do umowy wdrożeniowej dołącz listę komponentów open source z ich licencjami. To jeden załącznik, a jasno pokazuje, za co odpowiadasz.
Co MIT i GPL znaczą dla licencjonowania twojego kodu?
Jeśli licencjonujesz własny moduł na zasadach zamkniętych, licencja każdej zależności musi na to pozwalać.
| Zależność | Licencja zamknięta na twój moduł | Co zrobić |
|---|---|---|
| MIT, BSD | Możliwa | Dołącz noty i teksty licencji |
| Apache 2.0 | Możliwa | Dołącz licencję, plik NOTICE, oznacz zmiany |
| LGPL | Możliwa przy dynamicznym łączeniu | Sprawdź sposób łączenia i warunki podmiany biblioteki |
| GPL | Praktycznie niemożliwa przy przekazaniu kopii | Wymień komponent albo przejdź na model, w którym nie przekazujesz kopii |
| AGPL | Problem także przy SaaS | Wymień komponent |
Kod, do którego masz wszystkie prawa, możesz też udostępnić na dwóch licencjach jednocześnie: GPL dla społeczności i komercyjnej dla firm.
Warunek jest twardy. Każdy autor musi przenieść prawa na firmę albo dać jej zgodę na sublicencję. Kod od zewnętrznych kontrybutorów bez takiej zgody blokuje model podwójnej licencji.
Jak uporządkować licencje open source w repozytoriach?
- Zrób inwentaryzację. Dla każdego repozytorium lista zależności z licencją i wersją.
- Oznacz ryzyko. Zielone: MIT, BSD, Apache 2.0. Żółte: LGPL, MPL. Czerwone: GPL, AGPL w kodzie, który przekazujesz albo udostępniasz przez sieć.
- Ustal politykę. Lista licencji dozwolonych bez pytania i tych, które wymagają zgody tech leada.
- Dodaj kontrolę do CI. Nowa zależność z czerwonej listy zatrzymuje build.
- Dołączaj listę do umów. Załącznik z komponentami open source do każdej umowy wdrożeniowej i licencyjnej.
Ten porządek przyda się przy każdej rozmowie o umowie licencyjnej na oprogramowanie albo o sprzedaży kodu źródłowego. Kod z czystymi licencjami zależności i kompletnym łańcuchem praw jest wart więcej. Ile, sprawdzisz na stronie ile jest wart kod źródłowy.