JobTech Development forum

Frågor & tankar om Öppen källkod

Här skriver du frågor och tankar om Öppen källkod.

Podcasten Kodsnack diskuterade licenser för öppen källkod. Lyssna gärna på den: https://kodsnack.se/360/.

Det intressanta tyckte jag var att GPL handlar om att skydda användarens rätt till att använda mjukvara, medan de flesta andra licenserna handlar om att skydda den utvecklare som utvecklat mjukvaran. Det är ju en enorm skillnad!

2 gillningar

Vad intressant, tack för tipset! Det ska jag lyssna på!

Jag har flyttat inlägget “Internetstiftelsen erbjuder nu två nya tider för gratis workshop/utbildning om öppna data med mig” till : Frågor & tankar om Öppna data

Var det tänkt att kommentaren skulle hamna i tråden om öppna data?

Ah de hamnade i öppen källkod, jag postade där jag blev hänvisad:) Går det att flytta inlägget eller ska jag ta bort och posta igen?

Hej!
Jag har flyttat ditt inlägg till Frågor & tankar om Öppna data.
/mvh Ulrika

1 gillning

Bra tips! Angående licenser tänker jag att det kan vara enklare att komma igång med väldigt tillåtande licenser såsom Apache 2 / MIT. Ställer man från början kravet att dela tillbaka kan det vara en faktor som gör att det är svårare att börja med öppen källkod. Misstänker att alla inte håller med mig om detta.

@BjornHagstrom, nu ligger inlägget rätt, d.v.s. under öppna data.

2 gillningar

Håller inte med - om en part inte kan tänka sig att återgälda tjänsten med den fria koden, så är den parten inte till nytta för projektet som tillhandahåller koden. Tillåtande licenser öppnar för attacker som copyleftlicenser skyddar mot.

Exempel på attacker är när Nvidia tog LLVM-kompilatorn (permissive) och omvandlade till en icke-fri kompilator för deras GPUer. Nvidia tog kompilatorn som den fria mjukvaruvärlden utvecklat, och omvandlade sedan samma kod till ett vapen mot samma värld som utvecklat den.

1 gillning

Nja, tänker jag. Det kan eventuellt vara enklare att börja, men det kan å andra sidan krångla till det senare - speciellt om det resulterar i proprietära utökningar av standarder/protokoll.

Men I grund och botten landar det väl i vilket syfte man har.

BSD, MIT etc. ⇨ Bra om man är ute efter att koden skall kunna integreras i befintliga proprietära kodbaser. Optimal när licensbilden eller andra omständigheter förhindrar andra typer av öppna licenser.

LGPL ⇨ Bra om man är ute efter att tillåta användning av alla när man bygger en gemensam komponent som inte är fristående. Exempelvis kodbibliotek för läsning/skrivning av öppna standardformat. Optimal för spridning.

GPL ⇨ Bra om man siktar på att alla inblandade kan fortsätta att utveckla utan att någon part blir dominant eller kan stänga ute varandra. Optimal för samarbete.

3 gillningar

För myndigheter i EU är nog EUPL en bra start som licensval.

@Ainali Har du något bra exempel på ett system som använder EUPL?

Håller helt med i att det landar på syftet - vad vill du uppnå med att släppa mjukvaran under en öppen källkodslicens? Först ut vill jag vara tydlig med att jag tror det går att skapa säkra projekt med aktiv samverkan med både tillåtande och copyleft-licenser.

Dock, utifrån min erfarenhet från de jag samtalar och forskar med inom industrin tror jag mer på “moroten” (tillåtande licenser) snarare än “piskan” (copyleft-licenser). De tillåtande tillåtande licenserna (MIT, BSD mfl) är bra där man vill möjliggöra spridning och samverkan, särskilt bland företag där copyleft dels triggar oro hos Legal och ledning, samt att det i många fall inte funkar då det inte finns någon affärslogik (som kan bestå av flera anledningar) i att dela den anslutande koden.

GPL-familjen ser jag primärt som ett bra verktyg när du vill skapa en affärsmodell och försöka skapa ett värdeerbjudande med open source som ett komplement.

Från offenlig sektors perspektiv tycker jag dock det finns ytterligare dimesioner som är värda att diskutera - om det är skattemedel som har finansierat utvecklingen av mjukvaran, borde då inte ev. ändringar och vidareutveckling av denna komma övriga till gagn (enligt FSFs principer)? Eller ska den offentligt utvecklade mjukvaran komma alla till gagn utan copyleft-restriktionerna? Intresserad av att höra era åsikter :slight_smile:

Tänker att det finns en likhet med öppna data som brukar definieras som information som är fritt tillgänglig utan inskränkningar och krav på motprestation. I fallet med öppna data har få röster höjts för att vidareuttnyttjaren automatiskt måste dela de kunskaper, insikter och tillämpningar som tas fram. Jag gillar copyleft, men är osäker på om det verkligen ska vara ett krav.

Instämmer i att BSD etc. är enklast när man har befintliga kodbaser, oro över licenser m.m. att förhålla sig till.

Mitt perspektiv utgick främst från läget där man vill bygga en öppen mjukvara och vill välja licens innan man börjar. Dock är jag lite tveksam till BSD-typ licenser i vissa fall, nämligen när man implementerar standardformat. Där tänker jag att LGPL-typ licenser minskar risken för inkompatibla utökningar (den gamla EEE strategin) - men det är mer en magkänsla än ett underbyggt påstående.

1 gillning

EU-kommissionens Licensväljare beskriver de olika licenserna, och rekommenderar vilken du skavälja utifrån de kriterier du har. Testa.

https://joinup.ec.europa.eu/solution/joinup-licensing-assistant/joinup-licensing-assistant-jla

Ja, du har nederländska OpenZaak, finska Oskari och Digitransit, EU:s LEOS bara ur de flikar jag råkade ha öppna just nu. :slight_smile:

Open Source Observatory är generellt en bra resurs för omvärldsbevakning av OSS inom Europa -> https://joinup.ec.europa.eu/collection/open-source-observatory-osor/knowledge-centre

1 gillning

Jag håller med om att copy left är problematiskt och inte bara för öppna data. I den rekommendation för öppna licenser för immaterialrätt DIGG och PRV håller på att ta fram rekommenderas inte CC-BY-SA av den anledning att det är en onödig begränsning och offentlig sektor bör heller inte lägga resurser på att följa upp efterlevnaden. Skattemedel kan helt enkelt användas till bättre saker. Konsekvensen av detta blir att om man inte tänker se till att krav efterlevs ska man Heller inte ställa dem. Rekommendationen omfattar inte källkod men jag tycker resonemanget håller även här.