Hvem eier koden et KI-verktøy skriver for dere?

De tre spørsmålene

• Juridisk eierskap. Hvem har rettighetene til resultatet, og hva sier vilkårene dere har signert om det?
• Åpenhet. Kan dere se koden, lese den, gå den gjennom og la deres egne utviklere endre den — eller ligger den bak en editor og et format som bare leverandørens programvare forstår?
• Flyttbarhet. Hvis samarbeidet tar slutt, fortsetter det dere har bygget å kjøre? På hvems infrastruktur, med hvems database, og hvor mye arbeid er flyttingen?

De skiller lag på måter som betyr noe. Dere kan ha alle rettigheter til et system dere ikke kan lese. Dere kan være i stand til å lese kode dere ikke kan kjøre noe annet sted enn der. Det er bare kombinasjonen som er verdt noe.

Den juridiske delen, ærlig talt

Opphavsrett til maskinskapt innhold er uavklart, og den er uavklart på ulike måter i ulike land. Den generelle retningen i USA har vært at opphavsretten beskytter menneskelig skaperverk, og at materiale en maskin har laget uten vesentlig skapende innsats fra et menneske, ikke kan registreres — mens verk der en person har stått for det skapende uttrykket og brukt et verktøy underveis, behandles helt vanlig. Andre jurisdiksjoner vekter dette annerledes, og stillingen er stadig i bevegelse.

Den praktiske konsekvensen er mindre enn den høres ut. For de fleste interne systemer og de fleste produkter er det som avgjør hvor dere står, ikke om en registrering av opphavsrett ville tålt en prøving. Det er hva avtalen med leverandøren gir dere, og om løsningen kjører uten dem. Det er kontraktsmessige og tekniske spørsmål, og begge har klare svar i dag.

Hva dere bør lese i vilkårene

Uansett hvilket verktøy dere vurderer, er dette klausulene som avgjør hva dere faktisk går derfra med. De er som regel korte og sjelden gjemt — men de blir også sjelden nevnt uoppfordret.

• Hva dere får av rettigheter til resultatet. Overdrar avtalen resultatet til dere, eller gir den dere en lisens til det? En lisens kan trekkes tilbake eller gjøres betinget av at dere forblir kunde; en overdragelse kan ikke det.
• Hva som skjer når avtalen opphører. Består rettighetene deres til det som ble bygget, etter at kontrakten er slutt? Hvis svaret bare er underforstått, er det ikke et svar.
• Hva de kan gjøre med koden og dataene deres. Brukes noe av det til å trene modeller, eller til å forbedre tjenesten på en måte som innebærer at det lagres? En klar uttalelse den ene eller andre veien er greit; taushet er det ikke.
• Hva dere får med dere ut, og når. Dataeksport, databasestruktur og kildekoden til applikasjonen — i et standardformat, når dere ber om det, uten en supportsak og ventetid.
• Om noe i den bare kjører der. Proprietære komponenter, et kjøremiljø bare de drifter, eller et byggesteg dere ikke kan gjenskape. Dette er et teknisk punkt, men det hører hjemme på samme liste, for det er dette som gjør en god kontrakt til en dårlig posisjon.

Utgangstesten

Ett spørsmål avgjør det meste av dette, og dere kan stille det i et salgsmøte: hvis vi gikk neste tirsdag, hva nøyaktig ville vi tatt med oss, og hva skulle til for å kjøre det? Leverandører som har tenkt gjennom det, svarer konkret. De som ikke har det, svarer med beroligelser.

Et godt svar har fire deler, og dere bør be om å få se hver av dem i stedet for å få dem fortalt.

• Kildekoden, i en vanlig form. Et ordinært prosjekt i et utbredt rammeverk, som en utvikler som aldri har møtt leverandøren, kan åpne og forstå. Be om å få se et ekte prosjekt før dere kjøper.
• Dataene, i et format noe annet kan lese. Ikke et proprietært arkiv som bare kan importeres tilbake i det samme produktet.
• Databasestrukturen, ikke bare radene. Data uten skjemaet sitt er et stort puslespill. Ren SQL for strukturen er det dere bør be om.
• En vei til et annet sted. Hva som skal til for å drifte resultatet et annet sted — og om noe i det er en tjeneste bare den leverandøren kjører.

Det er verdt å merke seg hva denne testen ikke handler om. Den er ikke en plan for å gå. De fleste som stiller spørsmålet, blir. Den er en måte å finne ut om det å bli vil være et valg eller en konsekvens — og det er for øvrig også det sterkeste en leverandør kan tilby dere.

Hvor vi står

Våre svar, siden det ville vært rart å publisere dette og så være tilbakeholdne: applikasjonskoden er deres, og den er vanlig kode i vanlige rammeverk — React, Next.js, Vue, Flutter — som deres egne utviklere kan lese og endre. Dataene og databasestrukturen deres eksporteres i sin helhet når dere ber om det, også som SQL-skript en vanlig database kan lese. Siden med spørsmål og svar sier alt dette konkret, og Softeria Studio er produktet det gjelder.

Vi vil heller konkurrere på å være verdt å bli hos. Det er et forretningsmessig standpunkt, ikke et moralsk — men det er det som lar oss publisere denne guiden uten å redigere bort de ubehagelige delene.