@Maria_Dalhage

Utmaningen med LGPL är väl snarast att den är mindre vanlig - oftast väljs GPL/AGPL istället och därför är LGPL mindre känd. Syftet är däremot relativt enkelt, nämligen att tillåta användning av ett bibliotek i proprietära system utan att ställa krav mer än på bibliotekets kodbas och distribution.

@Stefan-Wallin

Sedan är det till stor del en fråga om vad man vill signalera - licenser är inte "virala" i EU enligt flera analyser.

• https://joinup.ec.europa.eu/collection/eupl/news/why-viral-licensing-ghost
• https://joinup.ec.europa.eu/collection/eupl/news/why-eupl-not-viral-l

Detta är rätt gamla texter, men verkar fortfarande relevanta. Nu verkar det visserligen finnas fall där GPL har upprätthållits, men det påverkar sannolikt inte användningen av EUPL eller LGPL som båda uttrycker att proprietära system får använda mjukvaran utan vidare licenskrav.

Jag kan också konstatera att näringslivet i stort redan idag använder mycket programvara licensierad under s.k. starka copyleft licenser. Så jag ser inte det som ett stort problem i dagsläget.

@jenniferskoglund

Tackar för svaret! Q2 är ändå någonting att förhålla sig till.

Jag är en av de som var med och tog fram synpunkterna för Jordbruksverkets räkning, så skulle det uppstå några frågor är det bara att höra av sig.

@jonass

Fast vi kanske vill vara försiktiga med att föreslå krav - eller iallafall formulera kraven på ett sådant sätt att det inte ger merarbete för intern användning av profilen.

Som texten är nu, så är den visserligen redan riktad mot externa API:er - men som jag ser det så är den minst lika användbar som vägledning för interna API:er som aldrig syns utanför myndigheternas brandväggar.

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.

@Stefan-Wallin

Kodbibliotek kan med fördel licensieras under LGPL eller motsvarande licens istället för MIT/Apache. Detta ger fördelarna med en GPL/AGPL/EUPL licens men ger ändå möjligheten att använda dem i proprietär programvara.

MIT/Apache ser jag snarare som primärt lämpligt för saker som:

• Exempelkod (vilken kan inkorporeras i andra kodbaser)
• Mallar
• Övriga fall där kod är avsedd att direkt införlivas (e.g. inline-funktioner i C/C++)

Det finns sannolikt fler fall om man letar lite.

De långsiktiga vinsterna för myndigheter ligger sannolikt med copyleft-licenserna - EUPL, AGPL m.fl. Dessa ger som Maria skriver en garanti för att utvecklingen förblir tillgänglig och därmed att maximal nytta potentiellt kan uppnås.

Maximal nytta i det här fallet handlar såklart inte bara om vidareutvecklingen i sig, utan även tillgänglighet - exempelvis om en annan myndighet (eller företag) har ett liknande behov.

Så ur ett brett perspektiv skulle jag föreslå

• EUPL/AGPL i första hand
• LGPL för bibliotek (alt. EUPL här också)
• MIT/Apache 2.0 om det finns en anledning

@mattias

Nej, Codeberg är ju inte kostnadsfri att driva - men tjänsten är explicit kostnadsfri att använda ( https://codeberg.org/about ).

Sedan kan det vara värt att notera att användarvillkoren ställer kravet att projekt skall ha licenser godkända av FSF eller OSI - så på det sättet finns det ett visst krav på motprestation.

Finns det en möjlighet att följa arbetet med API-profilen eller annars någon tidplan alternativt uppskattning av hur stora förändringar som förväntas som man kan ta del av?

Jordbruksverket är i ett läge där vi arbetar med att låta API:er ta en mer central roll i både applikations- och integrationsutveckling, vilket gör att behovet av förutsägbarhet kring API-profilen ökar då vi önskar utgå från den.

@mattias

Nej, Codeberg är ju inte kostnadsfri att driva - men tjänsten är explicit kostnadsfri att använda ( https://codeberg.org/about ).

Sedan kan det vara värt att notera att användarvillkoren ställer kravet att projekt skall ha licenser godkända av FSF eller OSI - så på det sättet finns det ett visst krav på motprestation.

@davidlars

Det här var en bra fråga - jag har själv ingen direkt erfarenhet av sådana lösningar, men det slår mig att det finns vissa likheter med tidigare försök att placera datahallar i EU.

Problemet är väl egentligen hur mycket kontroll som ligger var. Har det amerikanska företaget möjligheter att göra något av exempelvis följande:

• Installera/uppdatera programvara som körs.
• Konfigurera nätverk och omdirigera trafik.
• Lägga till eller förändra autentiseringsinformation.
• Åtkomst till administratörsgränssnitt även om de på pappret bara används för övervakning.

Så kan det vara ett problem - konflikten är ju mellan europeisk och amerikansk lagstiftning där amerikanska företag kan bli tvingade att bryta mot europeiska lagar. Vissa delar av detta tror jag är otestade, men med bakgrund av att det redan är bekräftat att företag som lyder under amerikansk lagstiftning kan tvingas att lämna ut data under deras kontroll oavsett var den är belägen så är oron förståelig.

Det finns säkerligen möjligheter till hybridlösningar, men min spontana uppfattning är att det finns en stor osäkerhet idag.

@jonass

Fast vi kanske vill vara försiktiga med att föreslå krav - eller iallafall formulera kraven på ett sådant sätt att det inte ger merarbete för intern användning av profilen.

Som texten är nu, så är den visserligen redan riktad mot externa API:er - men som jag ser det så är den minst lika användbar som vägledning för interna API:er som aldrig syns utanför myndigheternas brandväggar.

@Maria_Dalhage

Utmaningen med LGPL är väl snarast att den är mindre vanlig - oftast väljs GPL/AGPL istället och därför är LGPL mindre känd. Syftet är däremot relativt enkelt, nämligen att tillåta användning av ett bibliotek i proprietära system utan att ställa krav mer än på bibliotekets kodbas och distribution.

@Stefan-Wallin

Sedan är det till stor del en fråga om vad man vill signalera - licenser är inte "virala" i EU enligt flera analyser.

• https://joinup.ec.europa.eu/collection/eupl/news/why-viral-licensing-ghost
• https://joinup.ec.europa.eu/collection/eupl/news/why-eupl-not-viral-l

Detta är rätt gamla texter, men verkar fortfarande relevanta. Nu verkar det visserligen finnas fall där GPL har upprätthållits, men det påverkar sannolikt inte användningen av EUPL eller LGPL som båda uttrycker att proprietära system får använda mjukvaran utan vidare licenskrav.

Jag kan också konstatera att näringslivet i stort redan idag använder mycket programvara licensierad under s.k. starka copyleft licenser. Så jag ser inte det som ett stort problem i dagsläget.

@Stefan-Wallin

Kodbibliotek kan med fördel licensieras under LGPL eller motsvarande licens istället för MIT/Apache. Detta ger fördelarna med en GPL/AGPL/EUPL licens men ger ändå möjligheten att använda dem i proprietär programvara.

MIT/Apache ser jag snarare som primärt lämpligt för saker som:

• Exempelkod (vilken kan inkorporeras i andra kodbaser)
• Mallar
• Övriga fall där kod är avsedd att direkt införlivas (e.g. inline-funktioner i C/C++)

Det finns sannolikt fler fall om man letar lite.

De långsiktiga vinsterna för myndigheter ligger sannolikt med copyleft-licenserna - EUPL, AGPL m.fl. Dessa ger som Maria skriver en garanti för att utvecklingen förblir tillgänglig och därmed att maximal nytta potentiellt kan uppnås.

Maximal nytta i det här fallet handlar såklart inte bara om vidareutvecklingen i sig, utan även tillgänglighet - exempelvis om en annan myndighet (eller företag) har ett liknande behov.

Så ur ett brett perspektiv skulle jag föreslå

• EUPL/AGPL i första hand
• LGPL för bibliotek (alt. EUPL här också)
• MIT/Apache 2.0 om det finns en anledning

@jenniferskoglund

Tackar för svaret! Q2 är ändå någonting att förhålla sig till.

Jag är en av de som var med och tog fram synpunkterna för Jordbruksverkets räkning, så skulle det uppstå några frågor är det bara att höra av sig.

Finns det en möjlighet att följa arbetet med API-profilen eller annars någon tidplan alternativt uppskattning av hur stora förändringar som förväntas som man kan ta del av?

Jordbruksverket är i ett läge där vi arbetar med att låta API:er ta en mer central roll i både applikations- och integrationsutveckling, vilket gör att behovet av förutsägbarhet kring API-profilen ökar då vi önskar utgå från den.

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.