GitHub-kode i et kommercielt produkt: licenser og hvad du skal tjekke

Du er ved at bygge et produkt og finder en færdig løsning på GitHub: et bibliotek, en skabelon, et helt projekt, der gør præcis det, du har brug for. Claude foreslår, at du føjer det til dit projekt. Og så tøver du: Koden ser ud til at være offentligt tilgængelig, men må du faktisk bruge den, endsige sælge et produkt, der indeholder den? Kan ophavsmanden komme efter dig senere?

Jeg gennemgår det i rækkefølge: hvorfor åben kode på GitHub ikke i sig selv giver tilladelse, hvilke licenser der lader dig bruge kode og sælge et produkt, hvilke copyleftbetingelser der kan kræve tilhørende kildekode for et omfattet værk, og hvordan du tjekker en licens på et minut, før du bruger koden. Intet med ”det afhænger af situationen”.

Praktiske oplysninger om at arbejde med Ailoot findes i dokumentationen.

Passer det, at du må bruge kode gratis, hvis den ligger på GitHub?#

Den største fælde her er ordet ”åben”. Du kan se kildekoden, så det virker, som om du må bruge den, fordi den ikke var skjult. Den logik er forkert. ”Åben for læsning” og ”licenseret til brug” er to forskellige ting.

Som udgangspunkt er ethvert kreativt værk, også kode, beskyttet af ophavsret fra det øjeblik, det bliver skabt. Indtil ophavsmanden udtrykkeligt giver tilladelse, må du ikke bruge det. Sådan beskriver GitHub det på sin egen referenceside om licenser.

Det andet lag er selve GitHub. Folk tror, at fordi de accepterede GitHubs regler ved at offentliggøre kode, må de også bruge andres kode derfra. Reglerne siger det stik modsatte. Ved at gøre et repository offentligt giver ophavsmanden kun andre lov til at se og forke det, det vil sige oprette en kopi inden for GitHub. Det giver ikke tilladelse til at bruge koden i dit eget arbejde.

Nøgleordene står i den sidste sætning: ”inden for GitHubs funktioner” og ”yderligere rettigheder kommer fra en licens”. En fork bliver inden for GitHub. Så snart du vil bruge koden i dit eget produkt, endsige sælge det, skal du have en separat licens fra ophavsmanden. Ingen licens, ingen ret – selv hvis koden ligger frit fremme.

Hvad afgør, om du må bruge en andens kode?#

Det hele afhænger af én fil. Et velholdt repository indeholder en licensfil – normalt LICENSE, nogle gange LICENSE.md eller en omtale direkte i README. Det er ophavsmandens tilladelse, som angiver vilkårene for, hvordan du må bruge koden. GitHub viser normalt licensnavnet i sidepanelet på repository-siden, før du overhovedet åbner selve filen.

For ikke at fare vild i juridisk sprog er det nyttigt at læse licensen ud fra tre spørgsmål om din situation:

1. Må du bruge denne kode i et kommercielt produkt, som folk betaler for?
2. Må du ændre koden efter dine behov?
3. Skal du efterfølgende åbne kildekoden til dit produkt, eller må du holde den lukket?

Næsten alle forskelle mellem licenser handler om forskellige svar på det tredje spørgsmål. På de to første svarer populære open source-licenser oftest ”ja”: brug den, ændr den, sælg den. Men det er spørgsmålet om, hvorvidt licensen kræver, at du åbner din egen kode, der volder problemer. Nu gennemgår vi hovedtyperne ud fra de tre spørgsmål.

Hvilke licenser lader dig bruge kode og sælge et produkt?#

Lad os begynde med de gode nyheder. Hvis du bygger et produkt, der skal sælges, er den bedste løsning en gruppe licenser, der kaldes tilladelige licenser. Der findes flere, men tre er mest almindelige: MIT, Apache 2.0 og BSD. Alle tre svarer ”ja” på de første to spørgsmål og lader dig holde din egen kildekode lukket.

Den mest almindelige og enkleste er MIT. Teksten kan være i ét enkelt afsnit.

Med enklere ord lader MIT dig gøre næsten hvad som helst med koden, også sælge produktet og holde din egen kildekode lukket. Den eneste forpligtelse er at medtage licensteksten og krediteringslinjen. Babel, .NET og Rails er for eksempel udgivet under MIT, så du har næsten helt sikkert allerede brugt kode med denne licens.

Apache 2.0 fungerer på samme måde, men tilføjer to vigtige punkter. For det første udtrykkelig beskyttelse mod patentkrav: kodens ophavsmænd lover ikke at sagsøge dig for patenter på denne kode. For det andet nogle flere formelle krav til brugen.

BSD (i versionerne med 2 og 3 klausuler) minder grundlæggende om MIT: brug den, ændr den, sælg den, og bevar meddelelsen om ophavsret. Jeg har samlet alle tre i en tabel, så du hurtigt kan se forskellen.

Sådan kan du læse det i din egen situation: Hvis du ser MIT, Apache 2.0 eller BSD på en andens kode, kan du slappe af: Du må bruge den i et kommercielt produkt, ændre den og holde din egen kildekode lukket. Du skal blot lade være med at fjerne licensfilen og krediteringen fra den del, du har hentet.

Hvordan gælder GPL- og AGPL-kildekodeforpligtelser?#

Copyleft beholder et omfattet værk og afledninger under samme licens, når de relevante betingelser gælder. GPLv3-distribution af kilde- eller objektkodekopier af et omfattet eller kombineret afledt værk kræver efterlevelse af licens og forpligtelser om tilhørende kildekode. Det gælder ikke automatisk ethvert uafhængigt program i samme produkt eller på samme server.

Tag webtjenesteeksemplet. Hosting af et GPL-bibliotek på egen server uden at give brugere kopier kræver ikke i sig selv offentliggørelse af hele tjenesten. Distribution af en omfattet kombineret applikation til kunder kan udløse GPL-pligter; kontrollér integration og licens før afgørelse om den medfølgende kildekode. En browserklient leveret til brugere er et separat distributionsspørgsmål.

AGPLv3 tilføjer en netværksbetingelse: Hvis du ændrer programmet, og brugere interagerer eksternt med den version, skal den tydeligt tilbyde disse brugere sin tilhørende kildekode. Det er mere præcist end at sige, at blot hosting af enhver AGPL-komponent åbner alle uafhængige dele af en tjeneste.

Undersøg til et proprietært produkt det omfattede værk, komponenternes kombination, om kopier distribueres, og om AGPL-netværksinteraktion gælder. Vælg et kompatibelt tilladeligt alternativ, eller få separat tilladelse, hvis relevante pligter ikke kan opfyldes. Kommerciel brug er tilladt; spørgsmålet er efterlevelse af faktisk licens og integration.

Hvad skal du gøre, hvis repositoriet slet ikke har nogen licensfil?#

En almindelig fejl er at antage, at hvis der ikke er nogen licens, er der ingen begrænsninger, og du frit må bruge koden. Det er lige omvendt. Ingen licens er ikke det samme som tilladelse; som udgangspunkt betyder det, at du ikke har tilladelse. Kode uden licens er stadig fuldt beskyttet af ophavsmandens ophavsret, og du må ikke røre den.

Reglen, vi begyndte med, gælder stadig: Kode er som udgangspunkt beskyttet af ophavsret, og uden udtrykkelig tilladelse må du ikke kopiere, ændre eller distribuere den. Muligheden for at se og forke koden inden for GitHub bryder ikke gennem den barriere – den giver dig ikke ret til at bruge koden i dit eget produkt.

Hvad du konkret kan gøre, hvis koden ikke har nogen licens, men du virkelig har brug for den:

1. Skriv til ophavsmanden. Spørg direkte i repositoryets diskussionsafsnit eller via e-mail, om du må bruge koden, og på hvilke vilkår. Nogle gange har ophavsmanden bare glemt at tilføje en licens og gør det, hvis du spørger.
2. Find en erstatning. Til næsten enhver opgave findes der et andet, tredje og tiende lignende repository – blandt dem finder du et med en ordentlig MIT- eller Apache-licens.
3. Lad være med at bruge den. Hvis du ikke har tilladelse, og der ikke findes en erstatning, er koden ikke din, og du må ikke lægge den ind i et produkt, du har tænkt dig at sælge. Fristelsen til at tænke ”hvem finder ud af det?” ender galt, lige når produktet begynder at tjene penge og tiltrække opmærksomhed.

Hvad hvis Claude selv føjede en andens kode til projektet?#

Her er et andet lag, og det er let at forveksle med det første. Det er én ting, når du går ind på et repository og kopierer en fil derfra: Så er alt det ovenstående om licensen din direkte forpligtelse. Noget andet er, når Claude skriver kode til dig som svar på en forespørgsel.

I almindelige tilfælde producerer AI sin egen tekst, sammensat til din opgave, frem for en kopi af en andens fil. Så skifter spørgsmålet til et andet område: Hvem ejer den genererede kode, og må du sælge den? Det er et stort emne i sig selv, og jeg har behandlet det i en artikel om hvem der ejer kode skrevet af AI.

Men der er en undtagelse, du skal være opmærksom på. Nogle gange producerer AI næsten ordret et genkendeligt stykke af en andens kode – en hel funktion fra et velkendt bibliotek. I så fald gælder bibliotekets licens stadig, uanset hvem der fysisk trykkede på tasterne. Derfor bør store færdige kodeblokke, som Claude har hentet ind i deres helhed, tjekkes, præcis som hvis du selv havde kopieret dem.

Sådan tjekker du en licens, før du bruger kode: trin, du skal følge#

Lad os samle det hele i en kort tjekliste, så du kan kontrollere tredjepartskode, før du føjer den til dit projekt. Gå den igennem fra toppen og ned.

1. Find licensnavnet på repository-siden

   Åbn repositoryet på GitHub. Licensnavnet er normalt synligt i højre kolonne eller under fillisten – for eksempel ”MIT License”, ”Apache-2.0” eller ”GPL-3.0”. Hvis feltet er tomt, og der ikke er nogen licensfil, er det allerede et faresignal; vend tilbage til det i sidste trin.

2. Åbn selve licensfilen

   Find LICENSE, LICENSE.md eller COPYING på fillisten, og åbn den. Kontrollér, at navnet stemmer overens med det, der vises i sidepanelet, og at licensen gælder for den kode, du bruger, ikke kun for en separat del af repositoryet.

3. Find ud af, hvilken type den er: tilladelig eller copyleft

   MIT, Apache 2.0 og BSD er tilladelige; du må bruge koden i et lukket kommercielt produkt. GPL og AGPL er copyleft; kontrollér omfattet værk, distribution og eventuel AGPL-netværksbetingelse før afgørelse om kildekodepligter. Navnet alene fastslår ikke, hvilke uafhængige komponenter der omfattes.

4. Sammenhold den med din situation

   Besvar tre spørgsmål: Sælger du produktet, ændrer du koden, og vil du holde kildekoden lukket? MIT, Apache og BSD fungerer til et lukket produkt, der sælges. Afgør for GPL og AGPL, hvilket omfattet eller kombineret værk der kræver tilhørende kildekode, og hvornår pligten udløses; vurder, om betingelserne kan opfyldes.

5. Ingen licens betyder, at du ikke skal bruge koden

   Hvis der ikke er nogen licensfil, og README ikke siger noget om tilladelse, må du ikke bruge koden. Skriv til ophavsmanden og bed om tilladelse, eller find noget tilsvarende med en ordentlig licens. ”Den er offentligt tilgængelig” er ikke en tilladelse.

Denne kontrol virker besværlig, indtil første gang dit produkt vokser, begynder at tjene penge, og nogen spørger til tredjepartskoden i det. To minutter i begyndelsen koster mindre end at håndtere en tvist senere. Jeg gennemgår særskilt, hvad du kan gøre med produktet bagefter, så det ikke går i stå efter lanceringen: Jeg byggede et produkt med AI; hvad nu.

Gå til Ailoot.