AGPL – hvad du kan gøre, og hvad du kan ' t
On februar 12, 2021 by adminAGPL er en ret ny licens, der var ment at gå til GPL-over-netværk. Da jeg ikke er advokat og faktisk ikke har læst hele licensen, kan jeg ikke forstå, hvad du nøjagtigt kan gøre frit, og hvad ikke med AGPL.
Min usikkerhed tilføres af dette indlæg om MongoDB (som er AGPL) og endnu mere ved nedenstående kommentarer.
Hvis vi følger kommentarerne, viser det sig at du kan bruge AGPL-biblioteker med din lukkede, kommercielle serversidesoftware, så længe du ikke ændrer biblioteket. Er det tilfældet? Eller er du nødt til at distribuere hele din applikation, når du bruger et AGPL-licenseret bibliotek?
Sagen med MongoDB er, at den bruger Apache-licens til klientkoden, hvilket udgør et andet spørgsmål. Hvad sker der, hvis du bruger AGPL-software, men distribuerer den som en anden applikation end din kommercielle med lukket kilde? Tag f.eks. iText – det er et AGPL-bibliotek:
- Hvis du bruger det og ændrer det, skal du f.eks. open source hele din applikation, eller hvis du kun skal omfordele ændringerne i iText?
- hvis du bruger den og don “t rediger det, skal du åbne hele din applikation?
- Hvis du pakker iText i en anden applikation, som du starter som en separat proces, men bruger den fra din hovedapplikation, skal du open-source alt, eller bare wrapper-applikationen? (wrapper-applikationen vil være HTTP-baseret API, der tager pdf-filer og returnerer resultaterne af at bruge iText som JSON). Kan dette bruges til at omgå AGPL-licensen?
Bemærk: Spørgsmålet handler om AGPLv3
Kommentarer
- Se også dette relaterede svar: opensource.stackexchange.com/questions/5003/…
Svar
AGPL er baseret på GPL, ikke LGPL. Det indeholder ingen undtagelser for sammenkædning, og ethvert arbejde, der bruger AGPL-kode (linket eller på anden måde, modificeret eller ej) skal også være AGPL licenseret og distribueret.
Brug af separate processer kan omgå (A) GPL, men dette er mørk jord. Hvis din slutapplikation afhænger af på den eksterne proces, således at den ikke fungerer ordentligt uden den, vil det blive overvejet et afledt arbejde fra AGPL-softwaren.
I de fleste tilfælde, hvor folk bruger separate GPL-applikationer i lukkede kildeprogrammer, leverer de GPL-arbejdet som en valgfri udvidelse eller en alternativ back-end til et andet stykke kode osv.
(A) GPL-arbejdet kan ikke distribueres sammen med den endelige applikation, selv ikke som en separat app (f.eks. at placere dem i samme arkiv eller arkiv), selvom det er fint at give instruktioner om hvor finder du GPL-arbejdet, og hvordan man bruger det med din app.
Kommentarer
- Selvom det, du siger, er sandt, er den eneste forskel mellem GPL og AGPL er kravet om levering af kode, hvis det ' bruges interaktivt over et netværk. Klausulen, der dækker dette, siger imidlertid, at den kun gælder for " Ændrede versioner " af værket og " ændrede versioner " defineres som enhver brug, der kræver copyright. Blot at køre den ikke-ændrede version opretter ikke en " ændret version ", fordi copyright kun dækker distribution.
- 1 . " linket eller på anden måde " er forkert. 2. " det ville blive betragtet som et afledt værk " er forkert 3. Jeg tror " I de fleste tilfælde er " forkert. 4. " (A) GPL-arbejdet kan ikke distribueres ved siden af den endelige applikation, selvom en separat app " er helt forkert, f.eks. Debian distribuerer ting med alle slags forskellige licenser sammen, hvoraf ikke alle er kompatible med GPL. Proprietære systemer kan også gøre dette. Se på sektion 3 på denne side startende fra " Der er opstået spørgsmål ": ghostscript.com/doc/current/Commprod.htm Don ' t læser resten, det prøver at narre dig til at købe det.
- Debian har faktisk 3 separate arkiver på grund af licensering.
main
består af DFSG -pakker, der ikke er afhængige af software uden for dette område til at fungere. Disse er de eneste pakker, der betragtes som en del af Debian-distributionen .contrib
-pakker indeholder DFSG -kompatibel software, men har afhængigheder ikke i det væsentlige (muligvis pakket til Debian i ikke-fri ).non-free
indeholder software, der ikke overholder DFSG . - Ligesom … wat … så nu er alle disse Android-telefoner med deres Linux-kerner ulovlige …
- Der er ikke noget krav om at offentligt distribuere kilden til software, der afhænger af AGPL-kode. Der er kun et krav om at distribuere det til brugere af softwaren, hvilket AGPL definerer lidt anderledes end GPL.
Svar
AGPL er den samme som GPL; derfor, hvis din app bruger AGPL-kode, skal den have AGPL-licens.
Hvad AGPL gør oven på GPL er omdefinering af brugeren. For GPL-programmer, der kører på din server, er du brugeren, for AGPL er de virkelige brugere af appen brugerne af dit websted eller din tjeneste. Derfor distribuerer du appen, hvis en anden end dig bruger den. Og det indebærer selvfølgelig alle de standardiserede GPL-krav.
Hvad angår Mongo, antager jeg, at apps, der bruger det, ikke bruger sin kode, kun noget API, som ikke er AGPL-licenseret.
Kommentarer
- generelt set bruger jeg ' heller ikke koden til iText – I ' m ved hjælp af dets API, som er binær java API snarere end en JSON API i tilfælde af Mongo.
- @Bozho Og under hvilken licens er den API?
- @Bozho Mongo DB-drivere er alle licenseret under en Apache-licens (I ' med henvisning til det websted, du linkede).
- godt, det ' s dodgy – hvad klager vi en API og hvilken API-klient. Btw kan du besvare de tre ovenstående spørgsmål?
- Der er ikke noget spørgsmål om, at et værk, der bruger AGPL ' d-kode, er licenseret under AGPL (undtagen GPLv3 kode, der specifikt har lov til at blande sig uden AGPL-vilkårene, der gælder for GPLv3-koden). Problemet kommer i definitionen af netværksbrug, der kun henviser til " Ændrede versioner ", og definitionen af " Ændrede versioner " i definitionerne betyder, at det kun gælder noget, der kræver ophavsret (dvs. distribution). Så det er ' stadig ret mørkt.
Skriv et svar