API-licenser eller användarvillkor för API-användning?

[Maria_Dalhage]

Jag har en fundering kopplat till ”API-licenser” som jag vill dryfta:

Öppna data har vi lärt oss att licensiera enligt Creative Commons, Exempelvis CC0. I ett
Källkod licensierar vi enligt källkodslicenser: (EUPL, Appache 2.0, GPL m.fl)

Men det finns fall då man vill reglera själva API-användningen, d.v.s. anrop mot gränssnittet. (Varken källkoden eller datan) hur hanterar vi detta?

Fall 1: Det kan röra sig om att begränsa antalet anrop. 20 om dagen kanske är ok, men inte 1000 per sekund. Datan är forfarande öppen enligt CC0 och källkoden är fortfarande öppen. Dock ligger begränsningen på API:et.
Fall 2: Datan är inte öppen, utan det kan röra sig om individdata, men man får i tjänsten bara åtkomst till den data men har rätt att se. Det rör sig alltså om ett öppet API men innehållet är inte öppna data?
Fall 3: (jmf Stockholm Stads skolplattform). Att anropa gränssnittet går att göra, men ägaren i detta fall en myndighet vill inte få anrop till sitt gränsnitt (API). Dock går det. Praxis är att går det så är det öppet. Annars får man hantera tillgång med nycklar och användaravtal. I fallet Stockholmstad är det ju inte aktuellt med användaravtal eftersom de inte vill se externa användare på API:et.

Så till min huvudfråga: Hur reglerar man användningen av själva API:et? Själva tjänsten/ gränsnittet (API) och inte innehållet (data) eller koden?

[En före detta användare]

@maria_dalhage jag pingade Öppna Skolplattformen och dom svara se tweet

[Peter_Bengtsson]

Att reglera själva användningen av ett API är en bra fråga hur man skall göra. Ett API är ju i grund och botten en beskrivning över hur man använder en tjänst och inte någon artefakt - i motsats till exempelvis ett system som implementerar ett API. Så om licenser överhuvudtaget är applicerbara på API:er är vad jag kan se något otydligt.

Den uppenbara lösningen är kringgå problemen genom att koppla (eventuellt anonyma) nycklar till API:et, antingen för att exempelvis tekniskt begränsa antalet anrop per sekund eller för att kräva godkännande av användningsvillkor innan nyckeln lämnas ut (då har man en teknisk mekanism som man kan knyta till användarvillkoren).

Fall 1: Att använda nycklar och att ha ett öppet API är vad jag kan se inte nödvändigtvis ömsesidigt uteslutande så länge man inte principiellt begränsar åtkomst till något i API:et.

Fall 2: Detta är okomplicerat - åtkomst till innehåll och åtkomst till API:et är ortogonala problem och påverkar inte varandra.

Fall 3: Fallet med skolplattformen är intressant eftersom Stockholm stad vad jag förstått verkar försöka undvika den uppenbara lösningen - nämligen att använda API-nycklar och koppla användarvillkor till utcheckningen av dessa. Att inte ha en mekanism att koppla till användningsvillkoren blir rätt underligt, för att hitta på en liknelse:

Om vi tänker oss tillbaka till tiden när Televerket hade telefonkiosker med telefonkataloger runtom i landet. Tänk om en person med en nymodig mobiltelefon hade

• Gått in i en telefonkiosk
• Letat upp ett nummer i telefonkatalogen och sedan
• Ringt detta nummer på sin mobiltelefon.

Om Televerket då hade sagt att detta inte var tillåtet och att telefonkatalogen inte fick användas om man inte ringde med telefonen i telefonkiosken - då hade vi haft en situation som liknar den med skolplattformen.

Min gissning är att den här krumbukten grundar sig i att man blandar ihop olika koncept. Dessutom är det ju om jag förstått problemet rätt samma användare som använder samma API - men med ett annat verktyg.

[Maria_Dalhage]

@peter_bengtsson sa i API-licenser eller användarvillkor för API-användning?:

Den uppenbara lösningen är kringgå problemen genom att koppla (eventuellt anonyma) nycklar till API:et, antingen för att exempelvis tekniskt begränsa antalet anrop per sekund eller för att kräva godkännande av användningsvillkor innan nyckeln lämnas ut (då har man en teknisk mekanism som man kan knyta till användarvillkoren).

Gillar din liknelse med telefonkiosken Peter!

Ditt och även Öppnaskolplattformens förslag med att koppla användarvillkor till nyckelhantering är ju hur det till stor del regleras idag, men hur ska man formulera sig om man inte vill ha nycklar på öppna API:er?

Vi har tidigare på forumet diskuterat om det alltid behövs nycklar till ett öppet API och om nyckelhantering leder till begränsningar.

I fallet öppet API, med öppna data har vi inte alltid behov av begränsa anrop eller hur innehållet används. Vi vill också i större utsträckning länka till varandras data, och då kan nycklar eventuellt försvåra som jag tolkat det.
Så hur kan vi myndigheter signalera till en presumtiv användare att API:et är öppet och fritt tillgängligt?
Naturligtvis i dokumentationen, men kan vi komma till en standardforumlering, eller liknande som är begripligt på många språk? Det som har varit bra med vägledningen från DIGG och PRV gällande öppna data licenser är att det rekommenderas att sätta CCO för att tydliggöra fritt användande av data även i de fall då upphovsrätt inte är tillämpligt. Bättre en tydlig signal som säger varsågod än att det blir superkorrekt ur alla avseenden.