GitHub-kod i en kommersiell produkt: licenser och vad du ska kontrollera

Du bygger en produkt och hittar en färdig lösning på GitHub: ett bibliotek, en mall, ett helt projekt som gör precis det du behöver. Claude föreslår att du lägger in den i ditt projekt. Och sedan stannar du upp: koden verkar vara offentligt tillgänglig, men får du faktiskt använda den, än mindre sälja en produkt som innehåller den? Kan upphovspersonen komma efter dig senare?

Jag går igenom det här i tur och ordning: varför öppen kod på GitHub inte i sig innebär tillstånd, vilka licenser som låter dig använda kod och sälja en produkt, vilka copyleft-villkor som kan kräva motsvarande källkod för ett omfattat verk och hur du kontrollerar en licens på en minut innan du använder koden. Inget ”det beror på situationen”.

Praktisk information om hur du arbetar med Ailoot finns i dokumentationen.

Stämmer det att du får använda kod gratis om den finns på GitHub?#

Den stora fällan här är ordet ”öppen”. Du kan se källkoden, så det verkar som att du får använda den eftersom den inte var dold. Den logiken är fel. ”Öppen för läsning” och ”licensierad för användning” är två olika saker.

Som standard skyddas varje kreativt verk, även kod, av upphovsrätten från det ögonblick det skapas. Tills upphovspersonen uttryckligen ger tillstånd får du inte använda det. Så beskriver GitHub det på sin egen referenssida om licenser.

Det andra lagret är GitHub självt. Folk tror att eftersom de godkände GitHubs regler när de publicerade kod, får de också använda andras kod därifrån. Reglerna säger precis tvärtom. Genom att göra ett arkiv offentligt ger upphovspersonen andra endast rätt att visa och forka det, det vill säga skapa en kopia inom GitHub. Det ger inte tillstånd att använda koden i ditt eget arbete.

Nyckelorden finns i den sista meningen: ”inom GitHubs funktioner” och ”ytterligare rättigheter kommer från en licens”. En fork stannar inom GitHub. Så snart du vill använda koden i din egen produkt, än mindre sälja den, behöver du en separat licens från upphovspersonen. Ingen licens, ingen rätt – även om koden ligger där helt synlig.

Vad avgör om du får använda någon annans kod?#

Allt avgörs av en enda fil. Ett välskött arkiv innehåller en licensfil – vanligtvis LICENSE, ibland LICENSE.md eller en hänvisning direkt i README. Det här är upphovspersonens tillstånd, som anger villkoren för hur du får använda koden. GitHub visar vanligtvis licensnamnet i arkivsidans sidofält, innan du ens öppnar själva filen.

För att slippa gå vilse i juridiskt språk är det praktiskt att läsa licensen utifrån tre frågor om din situation:

1. Får du använda den här koden i en kommersiell produkt som människor betalar för?
2. Får du ändra koden efter dina behov?
3. Måste du senare öppna källkoden till din produkt, eller får du hålla den stängd?

Nästan alla skillnader mellan licenser handlar om olika svar på den tredje frågan. På de två första svarar populära öppna licenser oftast ”ja”: använd den, ändra den, sälj den. Men det är frågan om licensen kräver att du öppnar din egen kod som folk snubblar på. Nu går vi igenom huvudtyperna med hjälp av de här tre frågorna.

Vilka licenser låter dig använda kod och sälja en produkt?#

Vi börjar med goda nyheter. För den som bygger en produkt att sälja är den bästa lösningen en grupp licenser som kallas tillåtande licenser. Det finns flera, men tre är vanligast: MIT, Apache 2.0 och BSD. Alla tre svarar ”ja” på de två första frågorna och låter dig hålla din egen källkod stängd.

Den vanligaste och enklaste är MIT. Texten får plats i ett enda stycke.

Enklare uttryckt låter MIT dig göra nästan vad som helst med koden, även sälja produkten och hålla din egen källkod stängd. Den enda skyldigheten är att inkludera licenstexten och upphovsangivelsen. Babel, .NET och Rails har till exempel släppts under MIT, så du har nästan säkert redan använt kod med den här licensen.

Apache 2.0 fungerar på liknande sätt, men lägger till två viktiga punkter. För det första ett uttryckligt skydd mot patentkrav: kodens upphovspersoner lovar att inte stämma dig för patent på den här koden. För det andra några ytterligare formella krav för användning.

BSD (i versionerna med 2 och 3 klausuler) liknar i huvudsak MIT: använd den, ändra den, sälj den och behåll upphovsrättsmeddelandet. Jag har lagt alla tre i en tabell så att du snabbt kan se skillnaden.

Så här kan du tolka det för egen del: om du ser MIT, Apache 2.0 eller BSD på någon annans kod kan du vara lugn: du får använda den i en kommersiell produkt, ändra den och hålla din egen källkod stängd. Du behöver bara se till att inte ta bort licensfilen och upphovsangivelsen från den del du har hämtat.

Hur gäller GPL:s och AGPL:s källkodsskyldigheter?#

Copyleft håller ett omfattat verk och dess bearbetningar under samma licens när relevanta villkor gäller. GPLv3-distribution av käll- eller objektkodskopior av omfattat eller kombinerat härlett verk kräver efterlevnad av licens och skyldigheter för motsvarande källkod. Det gäller inte automatiskt varje oberoende program i samma produkt eller på samma server.

Ta webbtjänstexemplet. Att drifta ett GPL-bibliotek på egen server utan att ge användare kopior kräver inte i sig publicering av hela tjänsten. Distribution av en omfattad kombinerad applikation till kunder kan utlösa GPL-skyldigheter; kontrollera integration och licens innan du avgör vilken källkod som ska följa med. En webbläsarklient som levereras till användare är en separat distributionsfråga.

AGPLv3 lägger till ett nätverksvillkor: om du ändrar programmet och användare interagerar med versionen på distans måste den tydligt erbjuda dem motsvarande källkod. Det är mer precist än att säga att drift av någon AGPL-komponent öppnar varje oberoende del av en tjänst.

Granska omfattat verk, hur komponenter kombineras, om kopior distribueras och om AGPL-nätverksinteraktion gäller för en proprietär produkt. Välj kompatibel tillåtande ersättare eller skaffa separat tillstånd om relevanta skyldigheter inte kan uppfyllas. Kommersiell användning är tillåten; frågan är efterlevnad av faktisk licens och integration.

Vad ska du göra om arkivet inte har någon licensfil alls?#

Ett vanligt misstag är att anta att om det inte finns någon licens finns det inga begränsningar och du får använda koden fritt. Det är tvärtom. Ingen licens är inte ett tillstånd; som standard betyder det att det inte finns något tillstånd. Kod utan licens omfattas av upphovspersonens fulla upphovsrätt, och du får inte röra den.

Regeln vi började med gäller igen: som standard skyddas kod av upphovsrätten, och utan uttryckligt tillstånd får du inte kopiera, ändra eller distribuera den. Möjligheten att visa och forka den inom GitHub tar dig inte förbi den barriären – den ger dig inte rätt att använda koden i din egen produkt.

Vad du kan göra i praktiken om koden saknar licens men du verkligen behöver den:

1. Skriv till upphovspersonen. Fråga direkt i arkivets diskussionsavsnitt eller via e-post om du får använda koden och på vilka villkor. Ibland har upphovspersonen helt enkelt glömt att lägga till en licens och gör det om du frågar.
2. Leta efter en ersättning. För nästan alla uppgifter finns det ett andra, tredje och tionde liknande arkiv – bland dem hittar du ett med en riktig MIT- eller Apache-licens.
3. Använd den inte. Om du inte har tillstånd och det inte finns någon ersättning är koden inte din, och du får inte lägga in den i en produkt du tänker sälja. Frestelsen att tänka ”vem kommer att få reda på det?” slutar illa just när produkten börjar tjäna pengar och dra till sig uppmärksamhet.

Vad händer om Claude själv lade till någon annans kod i projektet?#

Det finns ett andra lager här, och det är lätt att blanda ihop med det första. En sak är att du går till ett arkiv och kopierar en fil därifrån: då är allt ovan om licensen en direkt skyldighet för dig. En annan sak är när Claude skriver kod åt dig som svar på en förfrågan.

I vanliga fall producerar AI:n egen text, sammansatt för din uppgift, snarare än en kopia av någon annans fil. Då skiftar frågan till ett annat område: vem äger den genererade koden och får du sälja den? Det är ett stort ämne i sig, och jag har behandlat det i en artikel om vem som äger kod skriven av AI.

Men det finns ett undantag att tänka på. Ibland producerar AI:n en igenkännbar del av någon annans kod nästan ord för ord – en hel funktion från ett välkänt bibliotek. I så fall gäller bibliotekets licens fortfarande, oavsett vem som rent fysiskt tryckte på tangenterna. Därför bör stora färdiga kodblock som Claude har plockat in i sin helhet kontrolleras precis som om du hade kopierat dem själv.

Så kontrollerar du en licens innan du använder kod: steg att följa#

Vi samlar allt i en kort checklista för att kontrollera kod från tredje part innan du tar in den i ditt projekt. Gå igenom den uppifrån och ner.

1. Hitta licensnamnet på arkivsidan

   Öppna arkivet på GitHub. Licensnamnet syns vanligtvis i högerspalten eller nedanför fillistan – till exempel ”MIT License”, ”Apache-2.0” eller ”GPL-3.0”. Om fältet är tomt och det inte finns någon licensfil är det redan en varningssignal; återkom till det i det sista steget.

2. Öppna själva licensfilen

   Leta efter LICENSE, LICENSE.md eller COPYING i fillistan och öppna den. Kontrollera att namnet stämmer med det som visas i sidofältet och att licensen gäller koden du använder, inte bara en separat del av arkivet.

3. Identifiera typen: tillåtande eller copyleft

   MIT, Apache 2.0 och BSD är tillåtande; du får använda koden i en stängd kommersiell produkt. GPL och AGPL är copyleft; kontrollera omfattat verk, distribution och eventuellt AGPL-nätverksvillkor innan källkodsskyldigheter avgörs. Namnet ensamt fastställer inte vilka oberoende komponenter som omfattas.

4. Jämför med din situation

   Besvara tre frågor: säljer du produkten, ändrar du koden och vill du hålla källkoden stängd? MIT, Apache och BSD fungerar för en stängd produkt som säljs. För GPL och AGPL avgör du vilket omfattat eller kombinerat verk som behöver motsvarande källkod och när skyldigheten utlöses; bedöm om villkoren kan uppfyllas.

5. Ingen licens betyder att du inte ska använda koden

   Om det inte finns någon licensfil och README inte säger något om tillstånd får du inte använda koden. Skriv till upphovspersonen och be om tillstånd eller hitta en likvärdig kod med en riktig licens. ”Den är offentligt tillgänglig” är inte ett tillstånd.

Den här kontrollen verkar besvärlig ända tills första gången din produkt växer, börjar tjäna pengar och någon frågar om koden från tredje part som ingår i den. Två minuter i början kostar mindre än att hantera en tvist senare. Jag tar separat upp vad du kan göra med produkten efteråt så att den inte stannar upp efter lanseringen: Jag byggde en produkt med AI; vad händer nu.

Gå till Ailoot.