AGPL to dość nowa licencja, która miała przejść na GPL przez sieć. Jednak nie będąc prawnikiem i nie czytając całej licencji, nie rozumiem, co dokładnie możesz zrobić swobodnie, a co nie z AGPL.
Moja niepewność jest podsycana przez ten post dotyczący MongoDB (którym jest AGPL), a jeszcze bardziej przez poniższe komentarze.
Jeśli podążymy za komentarzami, okaże się, że możesz używać bibliotek AGPL ze swoim komercyjnym oprogramowaniem po stronie serwera o zamkniętym źródle, o ile nie zmodyfikujesz biblioteki. Czy tak jest w przypadku? A może musisz rozpowszechniać całą aplikację, gdy korzystasz z biblioteki licencjonowanej przez AGPL?
Sprawa z MongoDB polega na tym, że używa licencji Apache dla kodu klienta, co stawia inne pytanie. Co się stanie, jeśli użyjesz oprogramowania AGPL, ale wdrożysz je jako inną aplikację niż komercyjna aplikacja o zamkniętym źródle? Na przykład weź iText - jest to biblioteka AGPL:
- jeśli go użyjesz i zmodyfikujesz, czy musisz open-source całą aplikację lub redystrybuować tylko zmiany w iText?
- jeśli go użyjesz i nie zmodyfikujesz, to czy musisz otworzyć całą aplikację na całą wersję?
- Jeśli opakowujesz iText w inną aplikację, którą uruchamiasz jako oddzielny proces, ale używasz jej z głównej aplikacji, czy powinieneś otworzyć wszystko, czy tylko aplikację do pakowania? (Aplikacja otoki będzie interfejsem API opartym na HTTP, który pobierze pliki pdf i zwróci wyniki użycia iText jako JSON). Czy można tego użyć w celu obejścia licencji AGPL?
Uwaga: pytanie dotyczy AGPLv3
Odpowiedzi:
AGPL opiera się na GPL, a nie na LGPL. Nie zawiera żadnych wyjątków związanych z łączeniem, a wszelkie prace wykorzystujące kod AGPL (połączone lub w inny sposób, zmodyfikowane lub nie) muszą również posiadać licencję AGPL i rozpowszechniać je.
Korzystanie z oddzielnych procesów może obejść GPL (A), ale jest to mętna ziemia. Jeśli twoja aplikacja końcowa zależy od zewnętrznego procesu, takiego, który bez niej nie działałby poprawnie, wówczas byłaby traktowana jako pochodna praca oprogramowania AGPL.
W większości przypadków, gdy ludzie używają oddzielnych aplikacji GPL w programach zamkniętych źródeł, zapewniają pracę GPL jako opcjonalne rozszerzenie lub alternatywne zaplecze dla jakiegoś innego fragmentu kodu itp.
Prace (A) GPL nie mogą być dystrybuowane razem z aplikacją końcową, nawet jako osobna aplikacja (np. Umieszczanie ich w tym samym archiwum lub repozytorium), chociaż można podać instrukcje, gdzie znaleźć pracę GPL i jak jej używać z twoja aplikacja.
źródło
mainskłada się z pakietów zgodnych z DFSG , które do działania nie wymagają oprogramowania spoza tego obszaru. Są to jedyne pakiety uważane za część dystrybucji Debian .contribpakiety zawierają oprogramowanie zgodne z DFSG , ale nie są w głównej zależności (prawdopodobnie spakowane dla Debiana jako niewolne).non-freezawiera oprogramowanie niezgodne z DFSG .AGPL jest taki sam jak GPL; dlatego jeśli aplikacja używa kodu AGPL, musi mieć licencję AGPL.
To, co AGPL robi poza GPL, to redefinicja użytkownika. W przypadku programów GPL działających na Twoim serwerze jesteś użytkownikiem, w przypadku AGPL rzeczywistymi użytkownikami aplikacji są użytkownicy Twojej witryny lub usługi. Dlatego dystrybuujesz aplikację, jeśli korzysta z niej ktoś inny niż ty. A to oczywiście implikuje wszystkie standardowe wymagania GPL.
Co do Mongo, zakładam, że aplikacje, które go używają, nie używają jego kodu, tylko niektóre API, które nie są licencjonowane AGPL.
źródło