Community på Sveriges dataportal

@Ainali Instämmer med att EUPL löser en del ständigt återkommande frågor, som du nämner (Europeisk lagstiftning, finns officiellt på svenska och flera andra språk, explicit lista med kompatibilitet), till skillnad mot AGPL kompatibel med GPLv3 osv. Man har också varit tydlig med vad som gäller vid länkning vid "derivat" (där om man använder t.ex. GPL så kan det var lite luddigare). EUPL gör det och annat väldigt klart. Dess största nackdel är väl? helt enkelt att de inte är lika känd och inarbetad som de övriga. Annars har den väldigt mycket fördelar IMHO. Känner du till några nackdelar kring den förutom det man borde känna till.

@Digitalist-Fabian sa i Leverantörsbyte för dataportal.se:

@josefinlassi

Hej!

Jag heter Fabian och jag brinner för öppna teknologier

Jag jobbar mest med affärsutveckling och försöker hjälpa myndigheter att maxa nyttan av öppna teknologier. En viktig sak som jag tror på är att inte försöka släppa så mycket egen-utvecklat som myndighet, utan snarare att bli en bra spelare i de projekt man använder sig av. Dvs gör inte unika lösningar, utan saknas något förbättra istället projektet som helhet.

Jag tror stenhårt på Skattebetalarnas pengar = Skattebetalarnas kod!

Att få jobba med DIGG och dataportalen är en fantastisk möjlighet och något jag och många av mina kollegor har drömt om!

Välkommen ombord @Digitalist-Fabian. Även om jag inte jobbar med öppna data specifikt på Digg, så jobbar jag desto mer med Öppen källkod, så övertygad om att vi ses i sammanhang framöver!

Hej,
Kan vara intressant: Havs- och Vattenmyndigheten har i samverkan med Försäkringskassan, Digg, lagt upp en jitsi-plugin för outlook på Digg's GitHub: https://github.com/diggsweden/jitsi-outlook. Det finns förbättringsförslag och framtida tankar, men den är redan i användning "skarpt".

Förutom den praktiska nyttan har detta varit en övning i hur flera myndigheter kan samverka tillsammans praktiskt i ett avgränsat öppen källkod-projekt. Förhoppningen är förstås att vi ska hitta form och flera sätt för mer praktiskt samarbete och lösa frågor som uppstår. Enjoy! och var hyfsat snälla mot denna första release

Jag arbetar på Digg och det är och har varit oerhört viktigt internt. Även om vi inte släppt mycket konkret vad gäller OS (än) så gör dokumentet att det alltid, i alla lägen finns något att luta sig på i ämnet, oavsett organisatoriska nycker, olika intressen från anställda etc. Precis som med säkerhet, precis som med att jobba agilt etc, det är inte saker man kapar på, de bara "är" (bör) vara naturliga delar i processen att utveckla lösningar på. Men tills dess, alla myndigheter/organisationer borde ha ett motsvarande imho, så att Öppen källkod inte bara blir individdrivet, utan organisationsförankrat

@tove sa i Öppen eller "Semi-stängd" data om sårbarheter eller cybersäkerhetsanalyser?:

Så undrar om någon vet om vi någonstans nationellt öppet använder API:er från National Vulnerability Database (NVD) mer känt som CVE? Kanske kopplar det till svenska incidenter?

Utan detta berör bara hur vi samverkar vid en incident och/eller hantering vid kända sårbarheter.

Hej Tove, viktiga frågor, och känns väldigt aktuella. Har tyvärr inte hört något (och kan ha helt fel, då säkerhet inte är mitt specialområde) om att det finns motsvarande Cyber Security Information Sharing Partnership (CISP) som du nämner, men det kanske är en fråga som skulle få gehör om initiativ togs, och någon/några hade långsiktigt engagemang att sätta fokus på att efterfråga ett sådant utbyte. En semistängd modell, tills lösningar och berörda fått en chans att ordna låter rimligt.

Ja, kan iaf bara instämma med att det annars är ju väldigt aktuellt ämne inom Öppen Källkods-världen att söka igenom projekt och/eller beroenden, både efter sårbarheter och licenser både på kodbas och i container-miljöerna., där de flesta av lösningarna i grund använder NVD och sedan kompletterande källor. Tror vidare att det är en flerstegsresa för många organisationer att formalisera detta (när man inser hur mycket kritiska CVE's man har:), hur får man in att löpande hantera dess resultat osv ,men inom en inte allt för avlägsen framtid är jag positiv till att det är del av grundpraxis att dessa CVE-uppslag med mera hör till standardpraxis för de flest något mer seriösa utvecklings/deployment-projekt.

Förutom de alternativ du nämner är en annan del att fundera hur man som organisation kan uppmuntra och göra det så enkelt som möjligt att få in upptäckter om (icke kända offentliga) sårbarheter från allmänhet/enskilda individer. Kanske inte något som händer varje dag, men har varit med om det tillräckligt många gånger för att funderar på hur många gånger någon inte orkade rapportera in något-

@Stefan-Wallin sa i Licenser för öppen källkod:

Jag är ingen jurst, men som jag förstår det så är det problematiskt för privat sektor i de fall det skapas företag med affärsmodeller som bygger på att källkoden för det privata företagets system fortsätter vara icke-öppen.

Jag undrar ibland om inte copyleft från GPL fått lite oförtjänt dålig rykte när det gäller dess användning i privat sektor för kommersiella behov. Nog för att det finns en del att tänka på vid användning av copyleft i dessa sammanhang, och att den inte passar alla tänkta affärsmodeller som du nämner, men att det också finns väldigt lyckade exempel där företag bygger kring denna modell. Tipsar om den här presentationen "Why GPL is great for Business" https://archive.fosdem.org/2020/schedule/event/gpl_and_business/ för en intressant vinkel där man tar upp flera exempel ur startup-perspektiv.

Hej, lite sent här svar, inte inne så ofta:

CLA,. DCO och inbound=outbund

• CLA är inte att rekommendera - jobbigt, ostandardiserat och komplicerat för både er som skriver den, samt den utvecklare som ska följa den. I diskussion med juridik tidigare så gällde för oss: Ni är fria att bidra till projekt som inte kräver CLA eller NDA:er. Och det kan ju vara en bra grundinställning (att inte kräva dessa för egna projekt). Man brukar istället i öppen källkodsvärlden ofta använda två andra praxis för bidrag-> DCO:er som är en enkel underskrift och brukar användas som ett intyg på att "jag har rätt att bidra med denna kod genom att göra en git --sign-off" samt en text om "inbound är lika med outbound", det vill jag säga - det som ges som bidrag här kommer att få samma licens som projektets huvudlicens.

Vi har med exempel på dessa skrivningar i vårt projekt för god öppen källkod-hälsa: https://github.com/diggsweden/open-source-project-template/blob/main/templates/CONTRIBUTING.template.adoc du kan kika på.

• Licenser och om att specificera dem enkelt
  En allt vanligare specifikation är REUSE som gör att man förutom den traditionella huvudlicensen för ett projekt också anger licenserna i ett standardiserat format (SPDX) i varje fil. Syftet är att man inte bara ska ange vad som gäller för koden, utan även andra resurser, tex bilder o text som delas i projektet. Det blir dessutom maskinläsbart så enkelt för konsumenter av projektet att följa licenscompliance. Det finns ett verktyg som gör att det är enkelt att lägga till o ta bort headrar. https://reuse.software/. Också stor nytta när man släpper projekt själv, eftersom man ofta hittar en del copyrightat material genom att tvingas sätta en licens på allt. När jag jobbade på public service höll vi en gång på att dela animerat material i ett testcase, men upptäckte detta tack vare RESUSE-standarden - vem äger materialet helt enkelt.

Vi har satt det som ska krav på våra projekt nyligen efter tal med juridik. Använder man verktyget är det ett litet jobb att lägga till i ett och man kan ha en linter för detta i sina pipelines med.
Se igen tidigare refererat projekt som använder REUSE också.

@Ainali Tack för PR! Bra hittat! Finns säkert flera här. Vi jobbar vidare med Contributing, tar med mig den. Behöves ej issues för bidrag, allra minst bug-fixar - (men gärna för diskussion om man tänker sig större ändringar feature-tillägg, refaktoriseringar)

@lfvjimisola sa i Jitsi Outlook-plugin:

Härligt med ett öppen källkodsprojekt där myndigheterna samarbetar.

Tack, instämmer 100%. Hoppas att ovan och allt annat bra arbete som pågår i, och kring myndighets-Sverige - NOSAD, dSam med flera kring detta ämne (ÖK) är delar av helheten som inspirerar till flera släppta samverkansprojekt framöver.

Det hade kanske varit att föredra att bidra till en redan existerande om det finns tillräckligt många likheter?

Kan tyvärr inte svara precis på vilka argument eller framtida planer som varit avgörande i valen av Öppen källkod-lösning istället för en annan - just den här härstammar från Hav- och Vatten-myndigheten - även om jag nog skulle kunna komma med några kvalificerade gissningar direkt. Jag tar med din fråga till kommande samverkansmöte så återkopplar jag senare helt enkelt. Men delar generellt din uppfattning - kan man bidra till ett befintligt projekt så ska man göra det, men att det ibland finns en mängd anledningar till att man väljer något annat.

Uppfattar det som att DIGG:S plugin är ny

Vill lyfta att det är ett gemensamt samarbete och inte bara Diggs' plugin, även om den ligger på Digg's yta. För Digg's del är/var tanken med just denna att man hjälper till med yta, plats och projektform (uppfyller det licenser etc) - samverkansaspekten. Vi letar dock form kring detta vidare och framöver.
.

@lfvjimisola
Att man inte valde att bidra till det projekt du nämnde beror på att den bygger på den gamla standarden för outlook-plugins, och att man vill bygga på det som MS numer rekommenderar för denna typ av plugins. Så en viktig del var tekniska aspekter , och då också möjliggörare av eventuella framtida planer.

Sen får jag ur min roll tillägga att det finns en viss mognadsgrad för organisationer att jobba med öppen källkod, där det är enklare att börja med att releases/producera, och sedan gå vidare till bidrag - Det är inte bara anekdotiskt från mig - liknande mognadssteg finns i diverse modeller för Öppen Källkod, t.e.x kan man se liknande i EU's strategi för öppen källkod - använda -> producera-> bidra-vidare. https://commission.europa.eu/system/files/2023-02/en_ec_open_source_strategy_2020-2023.pdf
Med det tillägget skulle jag vilja säga att för att nå en bättre framtida mognadsgrad så kanske det (även om det fanns tekniska skäl för just denna plugin) i framtiden också är viktigt med att jobba mer med att släppa en del projekt gemensamt - även om det ibland blir överlapp.

@lfvjimisola
Först, Jag tycker ticketen ser exemplarisk ut förutom att man inte får reda på hur det går p.g.a. ni tar diskussionen privat i slutet så uppdatera gärna där hur det har gått (fick hjälp, fick ej hjälp etc), och har du inte fått feedback alls återkoppla i issuen också så.

Som du är inne på, har tidigare i tråden nämnt att issues bör tas på GitHub, bland annat för att nå rätt personer (och nämns också i projektets contributing-guide). Det är olyckligt om leverantören känner sig obekväm med det, men då kan man kanske hitta en mellanväg och göra som du precis gjorde - att man försöker ta det från issues och diskussionen vidare privat (men se då helst till att lämna en kommentar i ärendet sen så att man som användare vet hur det gick och kanske något övergripande om hur det löste sig).
Övrigt än GitHub-isssues för just öppen källkodsprojekten från Digg är inte något vi bevakar löpande i dagsläget tyvärr. Och det finns inga resurser till sådan bevakning heller just nu.

".. jag tycker det är oerhört viktigt att DIGG visar vägen för open source inom myndighets-Sverige."
samt "support i andra forum (än GitHub issues"),

Ja, inga av dessa kan jag tyvärr påverka jättemycket i dagsläget även om vi kör vidare med de resurser vi just nu har, men jag tar med dina rader här som exempel på behov utifrån, försöker spara och samla in sådant för framtida sammanställning.