From 565c7a5951f5f8b73685ac1afca6ce41c65e4dd7 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Mon, 14 Sep 2026 14:48:30 +0200 Subject: [PATCH 01/58] Convert Markdown and ODT documents to AsciiDoc Migrates all guideline documents, the index page, and the four OSS checklists from Markdown/ODT to AsciiDoc. Internal cross-links and .odt checklist filenames were normalized to kebab-case during the conversion. Along the way this also fixes several pre-existing content issues: a duplicated content block in em002-1, broken .odt link filenames (typos/trailing spaces), and a couple of malformed footnote markers. --- README.adoc | 45 + README.md | 38 - ...1 Checklist OSS Preliminary Assessment.odt | Bin 52027 -> 0 bytes ...Checklist OSS Analysis and Preparation.odt | Bin 53701 -> 0 bytes ... Checklist OSS Release and Publication.odt | Bin 50777 -> 0 bytes docs/en/Em002-4.1 Checklist OSS Community.odt | Bin 52751 -> 0 bytes .../en/assets/em002-2/md/README_template.adoc | 72 + docs/en/assets/em002-2/md/README_template.md | 62 - docs/en/em002-1.adoc | 557 ++++++ docs/en/em002-1.md | 1430 --------------- ...-checklist-oss-preliminary-assessment.adoc | 175 ++ ...hecklist-oss-analysis-and-preparation.adoc | 138 ++ ...checklist-oss-release-and-publication.adoc | 147 ++ docs/en/em002-2.adoc | 627 +++++++ docs/en/em002-2.md | 827 --------- docs/en/em002-3.adoc | 697 ++++++++ docs/en/em002-3.md | 1134 ------------ .../en/em002-4-1-checklist-oss-community.adoc | 211 +++ docs/en/em002-4.adoc | 923 ++++++++++ docs/en/em002-4.md | 1585 ----------------- docs/en/em002-5.adoc | 327 ++++ docs/en/em002-5.md | 343 ---- docs/en/em002-6.adoc | 808 +++++++++ docs/en/em002-6.md | 511 ------ docs/en/em002-7.adoc | 717 ++++++++ docs/en/em002-7.md | 1213 ------------- docs/en/em002.adoc | 423 +++++ docs/en/em002.md | 797 --------- docs/index_en.adoc | 55 + docs/index_en.md | 48 - 30 files changed, 5922 insertions(+), 7988 deletions(-) create mode 100644 README.adoc delete mode 100644 README.md delete mode 100644 docs/en/Em002-2.1 Checklist OSS Preliminary Assessment.odt delete mode 100644 docs/en/Em002-2.2 Checklist OSS Analysis and Preparation.odt delete mode 100644 docs/en/Em002-2.3 Checklist OSS Release and Publication.odt delete mode 100644 docs/en/Em002-4.1 Checklist OSS Community.odt create mode 100644 docs/en/assets/em002-2/md/README_template.adoc delete mode 100644 docs/en/assets/em002-2/md/README_template.md create mode 100644 docs/en/em002-1.adoc delete mode 100644 docs/en/em002-1.md create mode 100644 docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc create mode 100644 docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc create mode 100644 docs/en/em002-2-3-checklist-oss-release-and-publication.adoc create mode 100644 docs/en/em002-2.adoc delete mode 100644 docs/en/em002-2.md create mode 100644 docs/en/em002-3.adoc delete mode 100644 docs/en/em002-3.md create mode 100644 docs/en/em002-4-1-checklist-oss-community.adoc create mode 100644 docs/en/em002-4.adoc delete mode 100644 docs/en/em002-4.md create mode 100644 docs/en/em002-5.adoc delete mode 100644 docs/en/em002-5.md create mode 100644 docs/en/em002-6.adoc delete mode 100644 docs/en/em002-6.md create mode 100644 docs/en/em002-7.adoc delete mode 100644 docs/en/em002-7.md create mode 100644 docs/en/em002.adoc delete mode 100644 docs/en/em002.md create mode 100644 docs/index_en.adoc delete mode 100644 docs/index_en.md diff --git a/README.adoc b/README.adoc new file mode 100644 index 0000000..9a3147f --- /dev/null +++ b/README.adoc @@ -0,0 +1,45 @@ += Guidelines to open source software (according to Article 9 EMOTA) +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +This repository contains *evolving drafts* of guidelines and tools to support the Federal Administration in publishing open source code. The *official and binding versions* are available in all official languages on the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Swiss Federal Chancellery website]. + +For a complete list of documents, see: link:docs/index_en.adoc[Tools for Publishing Open Source Software] + +== Legal obligations and responsibility + +As outlined in https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[Article 9 EMOTA], the Federal Administration is *principally obligated to publish its software as open source.* Each federal authority holds independent responsibility for ensuring compliance, including making the source code publicly available. + +== Contributing + +Contributions from the open source community and other stakeholders to these guidelines are highly valued. Have a suggestion for improvement? You can: + +. Fork the repository +. Create your feature branch (`git checkout -b feature/AmazingFeature`) +. Commit your changes (`git commit -m 'Add some AmazingFeature'`) +. Push to the branch (`git push origin feature/AmazingFeature`) +. Open a pull request + +Alternatively, you can simply open an issue. + +NOTE: You can also write in *German, French, or Italian* and refer to the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[official language documents] where relevant. + +== Changes + +When *major changes* are proposed, they undergo the Federal Chancellery’s standard review process and, upon approval, are translated and published on the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Swiss Federal Chancellery website]. The respective documents are then assigned a new version number. Mayor changes between versions can be followed using the https://github.com/swiss/opensource-guidelines/releases[release] notes. + +*Minor changes* are incorporated regularly into the official PDF publications on the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Swiss Federal Chancellery website]. + +== License + +These guidelines are licensed under the *CC0 1.0 Universal license*. For details, see the `LICENSE` file. + +== Contact + +mailto:opensource@bk.admin.ch[opensource@bk.admin.ch] diff --git a/README.md b/README.md deleted file mode 100644 index 7bfa73d..0000000 --- a/README.md +++ /dev/null @@ -1,38 +0,0 @@ -# Guidelines to open source software (according to Article 9 EMOTA) - -This repository contains **evolving drafts** of guidelines and tools to support the Federal Administration in publishing open source code. The **official and binding versions** are available in all official languages on the [Swiss Federal Chancellery website](https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html). - -For a complete list of documents, see: -[Tools for Publishing Open Source Software](docs/index_en.md) - -## Legal obligations and responsibility - -As outlined in [Article 9 EMOTA](https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9), the Federal Administration is **principally obligated to publish its software as open source.** Each federal authority holds independent responsibility for ensuring compliance, including making the source code publicly available. - -## Contributing - -Contributions from the open source community and other stakeholders to these guidelines are highly valued. Have a suggestion for improvement? You can: - -1. Fork the repository -2. Create your feature branch (`git checkout -b feature/AmazingFeature`) -3. Commit your changes (`git commit -m 'Add some AmazingFeature'`) -4. Push to the branch (`git push origin feature/AmazingFeature`) -5. Open a pull request - -Alternatively, you can simply open an issue. - -**Note:** You can also write in **German, French, or Italian** and refer to the [official language documents](https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html) where relevant. - -## Changes - -When **major changes** are proposed, they undergo the Federal Chancellery’s standard review process and, upon approval, are translated and published on the [Swiss Federal Chancellery website](https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html). The respective documents are then assigned a new version number. Mayor changes between versions can be followed using the [release](https://github.com/swiss/opensource-guidelines/releases) notes. - -**Minor changes** are incorporated regularly into the official PDF publications on the [Swiss Federal Chancellery website](https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html). - -## License - -These guidelines are licensed under the **CC0 1.0 Universal license**. For details, see the `LICENSE` file. - -## Contact - -[opensource@bk.admin.ch](mailto:opensource@bk.admin.ch) diff --git a/docs/en/Em002-2.1 Checklist OSS Preliminary Assessment.odt b/docs/en/Em002-2.1 Checklist OSS Preliminary Assessment.odt deleted file mode 100644 index 95a9d9014c7358e3572cd70ba91ed0f7d13ed403..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 52027 zcmZU418`(r6lTZP#P&oJ+qSKVZQC{{&cvM9wkF9W6Wf^BcJ}?dTeY>jsp?91Qr*?> z-FwdYbd_WwAmKs(>xUGiKf;1Y1-$t00Si3rtnAEOy&TPq935?~OpIKu9PAn0?M)dR zj9jc-7#tkU>`fg^-0aNkT^U@>JYAK555oXK|IfFQg4+9}kjue9AV_Es2od-&7c*B^ zD|-tU22VTNShYV2gG{Jh z?&idey#C&}RlnkC10QNgD~FTS#^D&7*Vy-O_nQ4FFvTt?I5&TV`_hpxPPK9>_SiKm z$$2}~jSu6g#YzRkqw^T9TdgIEI!?Gu_Yt(hYhg@yjOR$7VgDiL=u>$=E?d4um1U*4 ziapn>bP8^O785!2ZKwYyL-d>$l2tD*`oQcSJ9~jTF%UtR8cbUx@hh+fi%v#CWUMZ2 zxEYnV65Z3_??3(vs+Cra)7sP*q7Cv}&hXePz0dM>fwdB)s& zzt_-Igr6)*R=;#M>ZkpFXCJU`^eVo@k;{8*MbH=5=P4Dp-OS-#u7)o;tJjR&a&h{a zol?q`N!uuljj=sR;ge!M#{JAi5_}QO&t72RTj``}mIglb;le0gw96L&6=qUjjrO95 zV5uFFpuIv3_wy8WL8)ptaQ-Y`R((`RHDyq!Pu`TJl;7``Bm#uhz245$4pj*+U~-{|x0{>-GdVxIb6q1L*8y$7CCg#y7_H$17htpP(C%TahX6)Fl^d%`%=UDxh?*PkB#pz z3&k0E6MX6Lh>p7%T4|~$`g%m=b7TDLE}qyz7o!|@q5kS;K2|P7T6e+dcg|K$4zj_& z(n~p3#72D~<7{0SXSCC@z401bf&&_^g22`P|MzDKRwZ)>5(N5!_P@)=%+=_>ThgVa z?6Agx>Q7wvNn%-BAg_`l23OxPVmF;HjX$voe^-((HGV)Q3oZWp_;W>Yg?LRmO@&H` zxh%@&RQxxuzem@eN3nvzMzzeP#@fjI!VnetnNLS@Gs}YU?kBgP$1M71 zrTv@cN^S4YMRB8I1$BB(Iz8^DSp`of?StI*N4FjGku7y}s@q(Tl_x4he1cOb^XYN*P zs7|IeMY@UH}HJ73iS%yT_fsSpre~$NC{M9*`bCqszjh=e!#j=$#QJ)1Z zbjl)_&G$b#YHgOWmBS%s@_2{3UXSi;4`mo!g8K zbV=zt&zX(*8=@Ce84&x%?$dv{Qfbhi|=$zmkJu)?twIF#ZT zWJt9XQ7-*AZ%>k@j zdedrF!5R+?$B<%Fi4+$PRikBSk9MolPeeiv_8Efi8`~lHO^*+`?`7+V`ql@% zw78z7!gx2Gme4l9E6_&qd+J}+)<@Db81Yb%U21_I&aIZ- z0TuLUgds{O9$M$1FW*5hAZFz-1j?&hycyy4fQJW0@i`nWkOxv{-nq;&{?YTH+j&zC zy|^q=9|P$g6s1;8a2vGPBKg$Rko`KtPAXj_;=>Vr=c;P3Z=sHS zRBU0a2r;>m$}s)COyY#0E5zCiGgC6heQGI?WXWWKtY8O@a%RlCBJe|Ss?#NGCd|D4 zLFde=u&Ib^_L(l_l0;&CYNP~ehP((@DUthBPq%@;!fl2U+{!~{1+ftXAx5sYNw0hZ zh9hkFf~O#m87d_%YM^cEr==FN$K`zwP*~`&G^)}ELB8roHT1e|NGJ`7gTEsbXwwJa z;lA-8GUFxsPb{tp;~~Cat`oM(9(hjcNPz-uiNuU%^(RN(&3d4oAKZzhs6J5sPaFI{ zC_>4?q~*{R1p4oR3N%VPGgB)gMk_lb3o~X0M|+DXB?U<&c)b7KfFvy?rUC+iZ2->$ zV1cm$rt;eR0lWZnQIQk@)%+zm23|l~2+IqDK=la-Z$?nSYdA+KZ5I%Tbm6}T8062U z91zIWS6WP1%~SupJ3Xdz}3jpX4~V&D=#fB#oPl>OofsrXL>rLLGqO5^~=4@%)JRJt31ql*ra%l#`kKJ zmKKid>+6~t26uOk{k@|jp?Kg6Z*y{TQqj`F$7f{Vy!pS}{R;T>pP3O2MU7q?yCy`X zN%+?p#QkAGYL17bI#J*9a>yB{8YPIbkP`#0xY~@V*L=O*?>AEd$*GAwbI%@2#Ggzs zkK+&7%Np{Qu5rkdKc zm4X5?cMn8wqqpz#Rl&(-cSYxO-c}D~UTLg(6?O{2t{YQ*HXZY6DxKzN87U68bLf#u zV5>*~LA0FB(!R<>(?E+kH9bu~BTKi{oP@5fuBs~f&(&oukMmV=Cq2gq_exn-%gmNvE;qa97H6AUTE^8axoy8tQAv7uaH6B{U0n%a z;5gQ`qU#x#R>oQ7OUXJmvards(W#{hMipn{K}rt>jtC#_A5bEZYZ)^SjzSLoScOc_ zQUdK~w1%JC+P%HMkN^2I=zTYuB`8SE zgqn-LSX)-vcY8RMnFQ=|V`FQ?ThYSZtDA~Za(=lGbaaW%?GG7bMw-xArMIOT9yU){u84aP?BZw z{ZEtQS;YKe8C$HJoY@?1v;-R+?m<)pLfIVEk7p}L5uKf<*L%OWuWqaZuC|4vX?c17 zEDUSImVxAhAsFBlUFrFK!uypqG+I0^^>xGS9PG`bN0ai3i-*qFTD_VbU=#@n&nL4v z3tG7XKGu)t%C=1`^Lzc@dAPoPn~0!pfFb`JirRBI{M+BH+hXf~cSL%_WbtqohJfAU zd2M`CEZqjx&-Ap?<^(~InVETeU?$*wS8n16^OK{p!>>~!WdVi(6~65^`0k91WYg&O$I0l!qDWrPt14j)14Ms#Cvh+ZKOVUAB3m@L+ zONpZ1VTV2V!RYsV!`Azhq2?KEwvqZZ9D*Mv`%4tl0kpW7R(N{ZD?DkKtdPSqu+fu4 zg~ymhi+J8>5hj_p(HRj-KqFW6`tpK-jjjAgUV(@hXB#CVrt%iJ$J1)Eva(nVT7jg8 z8O$crh!7Z>Fo==sO;+dxK&girAwPs>*I6%A3`U>~25Bh1&D9zhydCWC|K!VzxTXm& ziL?NUVRS8?kT=xFpI%J$_5>t=uc*N^>+rCMTtJKNA8 zo-^UM*>#B2fbo>ECny4fv+L7~gXk^0wH7oKmEM`fA|(G`#Q1{#eEtxaCa;)u8WDSaD_nhR zsxTnNo*3r8uA%A-rgNokcQ;DY6iWS z{_N~f{vl(qpV86qWhZ6VfoY}Cd^}HLPrMYiM`%~Vi=*{+#IOFg2Ou| zqvf(+ZxfF1>kHJZ)$cd5H4WXW)@>y_w6><-v3F&Q&o}eM>{Xb?>567RmW(Gr(~Cp0 z=9GttBeygLi7ri8BDbhJ&F53ZuSPiJdUT*JzQ)+MEv>%m(`Lz(8cSt>*@U> z#uXcj*iR+Kf0|o={UzaZV)?y#wPY7B}2-6`0e?2MluOgZca#zuOX$oYZX8lSn&dW-iL>Wyu7^q z{GM0&CX!Inz&w~P>GZhmjBpK^R)zt=;pGs$t#kSZ8kd=`^g^M$E!lwO#Y(Z59%&z{RnQt`%JEx~1 z1IY&$YpqMe!?=6jL`5M|$mr=Y37ctYrZDqTX=Sywrqv`*r)Ot}7~>iOrGLy``&_JZ z^N5cr6YURfOfD>rWI<1wnGL{BYhO1Ns+PrHm60+&&vm$a6Y)82gWkZ4|KPOjU_TJs zuM~SaLL|b1k{dcYn97U7Y)mChhPccpaLRGiy{xQg{Ea?6slUQ*_4vgQJRqS+o;YUU zARLpSz}6PQPJtkzh^Sa^f4XLhIhdPQ)Zi$tuEOhx{Mp0%Y8GF5`~_tn&a33Nc-@pE zJPh;5^X=g^uiFX6n?g1RQm@Cwx`bgx?4g+%PD;^g0k32NQJ5eN$Dw+Ox8rDGy7MM!7hKQfk__XVHyUjPoHlO>GFnpsie(yWjF=cudnmhqNJluRQ zl=T?0M1?-AiHV6&b17)vQ8;=-CJvTjM2Z-d&F+9tfu}^|6`Eq-%T4~FK56ZGHB?D@ z8U&O|v4CWDy%$2^A2^?|Vl>zl?AZJ#eSe~UVW{w>U(;J^m@dnt-AqX|-qcG6Kg~ma zRKN%_m^tPhy*w7+!sZQ0#zY}}+-_mAQq8ctT8Di;GtL;C3&P$y7jkVd1eKIPdFRSj zvi3h?KGt9?3n4>`4)6M(NO_7D6HlaB%eaV&Kg|aj~9exo;|lQ zq*BjjCy@FnZZg`Eb&;w4BT0O~IFd-<7!@HqZnFGHuda@Zi&MAyrQ{hL9?rwp>3%FS z3;C0P@JKIqU_j(8xi_YWscUV(an7R9!B zG%KD_9$GR{94l+`8y2B{w2tyK17~=EcR13^!;VJK{|y!i%Gk}rV~{59(J|VyoK*te(% z{r2x<20PQwGzoK`>gAMX+kajkyCUfx;VRAXp#+W7-Y*hmGOu<9o}*(kccmc=jqIUi zL((WJA#G`9?)8+cM#_g4t98-Z>L31Eek)JA;S?qdhC*lnpgjV<$!3=qSBaHGK!D)e ztcvFHFp$bWQG{&lY=Keewe4=36GC9 z9ql^4dD8o2err#o&w73G^f+FRGAD$?5$j_W5Qx`y#=<(l2}$H-R7B;J&J3(aEJlQp zuOwr#H>lQPp4$GUbsC!V=l*nQn}p`|`2}{VqVl_ZHKo06ttWqQa*IdZpA5>b)|n$q zNE!$xWjb0~hVN~l$N68Xzuv}G^y`hEJ3THf*@vsMIoFzRL&?bsKO<0x^Rwl~mumD* z7pv(As&$U}HNPDda>7l@$vZ|HQv5@RR3fXpS1`ATTSYbtc z6qzG6=E9&uQ`k;fxTg zQ(B?=RJA0anJaAd7TS2}#fl>_YmmczI9ri-*fyQS*4JQXMk_rvG|4Xlh9t*&R8*7_ z8;*-;#K>NX1|xt`2?_aE?55Y>-h8#Z+iEpx0lk+r8V+-v40i!`{eWjoL zyb#b31A7%^Wp$Ql?cm!kC;MZ-y3W1wajCa2KUx%_6@SA`Ma}5u^K^`(EL&_4my^3| zb29PtS(zS1&22n1Ws?27xEOACEG-K$s((;|2(uCs`de;a<07!jMM<00`tN9RisBl`kI|BfkAJ2wGM7czga6f#T3==e5|bT3@1_ z)WaZ%ptDs_scvhmwQFi1U@x~20)tZ@jW(WmjWAPn@=%ReqSnmUB`m4OIba}(9v+mT z(;e9Ce6%gR?9<-fUd5R5AHY0f9R5Mv7YLTr^l<%(iZeY8=i=JkHMt_R-r;tt#6DUa zEX3oE@qn`prrI}ur}=H>1IqK`%}XV@ZRt`IjgX(BN)koq6HEwsU#S@?L1tlohT6JB z{d9URIsDh2C9FERXj7mbF3QE0p!Xg1WW7PVvl#%TskwcZXJ2n_oHdC2HL*%->&^^A z1%00q^+aq@#@i**#y)M_s4$NiV}m;x4m{l4Rv-?s#}MTOJcAY4SI%Zl?UTQ z!ZB;@`@a)&J42EkvLcdDJwJOe=ywUB$)I9m)2$TZ?L2prXotQbz;N*c&_T`wu}`b1 z4GlvGfg9Fgvnz-yb{*K>EJ2{Qe=IW2$7D#Hux4gvK>e6E5=3%e4#DAZe%b8y@z@_l z^T&f+5dJ|s5ebdT-4OJoy)T6q%;SEBlZuea?*GO`5#da#01wd@hhNa9MmCQ(9$$d! zj|Oq$0w6pz^6(uD&C^#Yh=4jMW<&!4zpCazXxD2!(b;m=Glixm_N+NcNZ_DpGlPc<}H}?idJAiLqtfrGR-!>L&#cvzFpA znYFOZM=y`GT850nY|PcIr*JewoK9nx+IdEJkWEKg5PY&X9t!POZGb9BH) z8Xqbc={HrKWk%JbMKAXDws~ND3H#bFsi=s}kK#4^MG1WOH)C*ndq;lV`I=Y5exItj zxp`aqrjD5I_{2o9EDqNU{=0~Dr~7amKuekCjWpoTnMH*%T8Qk9_&d$>a``Ju0#4}l z8Fg>GkBxUU9k)H0{kII#9>NU-0{pu@3&;Y=_z0pqbHlI=d$x>H?VbNF@3Xz-7=0cyxvXUT?vKexC0{jjpuuBFzZ(V(3ZF?Hj^TxdiEu|L z2-(A0#<(XjN6!dW+o} zKxtRDx6f7@aS~@(bZ$u14-Edi0e=MWRzqW>BX+M3J~U;f%V9$SQSb&JbD7XAmfzgo zva*;H^0-Fc1SWR6U&!I`p8!jG1y-YnzNm;E9UaZW!UCY&XwOj?cRPSrD*Scdk035! zA%RBRGoSiv*e>pLCGtpBPa& zyVp0RhwK}-+7#y!Z<#XlEq;ruYSjsrd!Gh$FP!^hBC7W=3oo6`v$GQ_As*hi`_kj> ztr>b@(>iP*iXGDHiF#OB8P_j09i5YduYZZ_#|{9gVJ48U)$pf6E?+*i?S#IPQs38A z)La3)Fi=xH2`LLpaPGj_a(xKY1t4%b)w^yTk%|^REcl0v_X*`;U?(-|StjyZcS}dX z+3FJrnJ=qB^si{2dG-BE&TJ6GWItsS(A1EbPZI2L3$Ni*&iHD}l@F<)5P#>U0{6rp z9U+DUZ8ngUnmU|zg-pbjIGK90T2)dKWr@3e3see2&M-~&Qmw(<*AY;YHexZz7Zq-e z7!35U(Sk=Vd!{C(8TZ8^pRp$h3{df--J>TaCkrU;gw)h9KApKyu3AgOd5$Z4{OM>B zyh-(jPp3h1<^up;yt}_2LKo){5$Tv2L_i<*V27Qj{qUUEaSIi}*3Fc?OO9_S{{XOt zXJ_+EpwD62K-z#i-uQ1`b>cyLSO8)FNM`9@`VGT3dBCWQ&T20Acw>!HZH5v7j3-GH z@E}TAEY>;W@%=Hm>>z-RdinUcoh&D1f+_71@q0hLysWo5@iQxXzQgpM z#uAU3RR_r|@)u|K_HGqPqLk5b^pV}2F0}%*x|pGfAIs?PPi`qrmO?=pF#&8weM3d` zbOya~!5Gp$aN!yrH$(;+Gy^$6Z4i}`(rlXglg=n9i6TsU^}UWHyNR2ZckTCYUTW&P zd?BVO!`S{foEG~Pvh^zJf%SF~j>N%EB#vi)oB3JufwlGT%8aLV;pzknq%rhzhE0)Z zK%v?ch-Ab4v!Y=ir{z|&Zdb0H68uE}#bP=i!qc32^>LP|L;Ht#fkzK(#^7I#3Q+RK zzT(;9zRx$;*Lzu#;qd(aMA&mjGKi|R4qJ|P^zy)fHJ|rK|5{pdzR{V!1yw~f-HMNo zP-nBC(?W9E;uN$~)Y5_#uU@GUr7xqTY6Es0MfIt{CYK!`kPnHB{P0FA5B+_7Y!U#{ zf5*oM`Xc$Ja(Hz$9&Bfe?{)?wW@2*t2A~iClz%vpDSy2^0*r*=p&{GNu1p%-k(lG- z<7oEZX0|=JnoCvM=;(yL|W}P2)Lb1oo_r_43QwFMI(@F^g6N33K9ap0Lq)7-^(4^V8re1E+QOU z5v5PN37a%87C2C9CFwFrY*x3x)Jmi?-0YHjG0m?-YB*v|c(4%uI`vb45F5MGbnMF_ zG*d>8|GT%ZF9GHbu%d}7&dv?vE7zq_rG=BJsi|(0oNKfKoKnDKRg@hrSXpaE;FoEl>jya6W2e(a~KEq|!0>S{oP zgd`^?Pdjun`8|7aAE~-{a0zMZvE3I0;1dNI#op2LSKs~7q|ne%`D_kmr;yoP0d(wR zfHP+;qj9+&p(-kSd3i}oM**(K*$RxY&|?;#KVMU(zz>DxZXeDU*E(!@J@PO9Z~^KI zFw_P*I<&4?o5aG=*_?K(ZB9j3txgcyc)G3jM(2mX=Kb~SS7YcDQMBqG0HW}Et2LQ! zj~)C$TL9!-W(80|GD^Zga4@&aK|aPE7(KL-03Al4&#!H!%1{EhWykx9tCHLGb%Gg_ zy%Amyv7R>Pe>YFpd*%}ve{*F3Gk|HP03*_IB7+%#&7uXPjmJe+R*i_bg5cWOW^dey z&DtY*A*Cggzy?2=|5X&$4qTCyYtvOwume=}jdHuUH11pUG%<{=e9USd!7DB-!YOI3 zLk)twc(yd=Qyhk8EFtg6*ckJ-Z?WC0J^U80AuuSbt&grQE+yLPBxHrXK|%frLQMa zc(&eziA708#rf%q^yYWq<=wHWqoJ0x=#JOzf$~YW&;3tU$z>5V@j>cFz}mXgCkbx{ zWF!$=IJkkwZ=Xn(w5#7HIA4El3eP94Ns$7;w;I;0GU)a3vdlSLK~nP7js1wVpxkiP z4L^|T`~lR~(Wb;iLLmklC{1yBsdE`aNOE5lGPQMM5XV< zL4fdnr{uo6^y4>RKmh>w>7U!hh5hK4-KE9FLMai^&PHwSZNPuK!}Qn& zbn3Ha7jV4KZlA{%+ZDbax+qUDMQ~0omX@OhqGXuYOotClN2|>U{Lp)c*{3>NatSz| zU4E}=J%8Z?&zI-WaX9u3g(%)$%z1fr7ai`Z%ufNME2MV}33l~6|CTSX_1SHP?2Nr1 z5KUIs+hbgNv?&J$U+XT0mzMBzKy!wrlac7%E3c32-MCGeWxhDJ`+;h#EdJvj;8}QC zX&bS4w18zeHU@SH*ug-Zbog)ZEJGJ#fwa=-2^pxV4O5YBL*%o-BTeT@<*5{Y8q&t& z0Q0TU@6~;MfM~G~eYMekgXiNPrME?BAjp!B*ZnL|kiVz@{D=~V+Mi1c8E^w@Gq$<` zkbn@4{=g7}E|)--m<@(>0Lbj4_%+e`(V12P6l!V45XUOBpza`On}{u81a4t$r?X|{ zr$(xs0FJCQjz5Xl)+c`-6IeX3r41GWh;n}}4lN0Z3a`dtnt3JzKLhy;A4^87v_@@p0w zf)Y6L1Ox0XEtx#0NqEA1rNkyFvX+j1uMs#A`n|XLJl2GTam&}ttcs^Hv9mwN=?8#f zJO0ttlZ$lrhF>yr&>6QC5d16w;gsdi;u zevC_j0&rAmjYVGq?+zY^P1qNHK=A>{WoTN{8I7ND!5pj_rK+Z+HY6(Zu@uStUrS2%Dnj`Hz9li%@$=0Jq0 z)%{$j!nM31CI$f#N=1|w1JRn_0%x|gvL?ZKuGMP{f7l3K z2RlHCu)iO1MEp7;aU`@Y)M$jVAWU(mgg!CkzGWOp+iLlN-JP(}QVlaK=(H=9Yx+AoikGc;x-KiyoU2<@~Bn$zQ zmX_9VQwR&Tu(dNeHWoy^-3BN;0Js=+8Hqi&j1m zd!^9=7UiQXfQ{39q=8R;CT=<^a3t;QOjtf*KIE~ z+*^|^>BfN`B^|4Ju3!L>-z$VC5J&6M)m__p%he>F)WVyS{UKvyL;3l zy3h939>3Qw2J4+3*v}S~`H5gkJ$bc^|Mmg0X$hjBW_6j%WDO&PE9gAy96ZW8+9OI7 zG8GFzMZ(45y1!2HhY>Y0gq?)eT(OC_OlzSIY{tBZi^F`)>rmI0v`W@GE>}&(?;F3Y zz-Hhe5Nox}u_eV1(Y~)s&@>~VwY~y`_^}S8<3*%-h5oBG{bLuFE?QBKoQh|}K-{^~ z=DW)FU|JUgFw-hIA=~1j(Yl*2lpJS!>h0n&y{H-M!*9Oq$_4 zimGp6c7#}J?e|}}{h}=+65-TPDVXo{JlI}Oye2=;M9wsyHz&yAlG`) zCWyFQvr6*ejgDWo*D@_ZG-*_=Wi-$%iNomQYI$=V?W#Bs{M}aGnlZ)aNlJdFLs;KMJRj}9xt)o%Bn!7$; z42TGd#o*I$=%*r8s&g|lgW*Z{Kapa9Rm66P-J??H-dU@MQxlw>JCe_aK}m1eekO;=r&%qq>qHuMi&2SJjt!Ff)S$3xgvab=2>{ z$8HLpw8_o@6k82=jb3-OQCg5cozix(^p8>W ze#7F94lWbV!?Uv?zK~#W_W1=NJzH}S1h2DDJ1a{l8c|@PzrX+JmnxTWrWC|4Aqjc4 zC}T+cplE1wv+Q{x$@6ntG-%^u?|w>4CcQ8)`N44@17vAsWocv8;PDsDNK7n1SjoGC zjTZv3`-(9Fr^7OgeS+>estkM$DG|GfWA`dd;~+SOv>nXE~*H~vtLhFxLa0W zR=n6IFr5_{ewQL;BF;{G`F$cEZu*9|4rBz-mV4nRbKQ^CioCL{r^sGrT4yVIv%mVH zo~t)IjqJT2|5zZFH`$WceFO9`B~STKos&Gghl`w8Vlh)wF@UxcFlA=YU)PE>Vv9mA zS>~3mR`Lj#%sFDTyj6Y`p?Aaiz6*uR;{P>EeIi%8$Sat3sq6gKue@ZuL+9qBg~cB! zOZ{R^*JOjEg%(>k!~Yl2;D2J~%-P%=mE0}fMjy4C%ZQeIItD9Y|CM8xtYm~adE4a9}oX!IY-;4o831f}#t!#ITdu9<8w&IP2GLy!@ z=+7s{$6>D%Mr7|Nlw|+sn*sb}5ucUVj)4dWo^kWO_j9;#;9A}xN$zI`5EiZluuN~j z=LZnUb*N0Y=O6&GOmToO&!! zcdi(h)9w(UQCUp=&1ZZaI2?|_etkH{XQ7Dp3&QDW2GW|qKAJ{X23G@QuN8o+X7jd6 zq*hi`EY=$I0uE4Ve5=D&xDVh8&U2F-BjGPvm`z$FtSjURRF_r$NcRZNg%$9;3e*!h ztTP%6KZ6=|oP<9H6as)QA>$tO=8r?fk+QP>cyJz}iB{G4sxVe$L>{qU+8hsRU<>%@ z0${0X?sX@SeB4i@KM$K)ZMISN_4a=JEvod7v8%o6LEtRtxk`r#YJfMVL)f*=hMN)go}Ak3XN}B%;9Y@sXj`7S`z4V&SoWH>)R|HTG65%wOIn_DwrzmX4`j8M=7 zOn`Y?YX&5YV-{h=;1hC^qNAdejf{-^{RRG&Y1ZZfDkG4* zEvCZMeTJ1=hWSd@3839kVk@Ex1#4^rKF@tfW)C4zN#=PM;0-GC6SWZIMY!}&a5$i zD3J3tnMXL=?9SFmhZqb;Dsn3Z?A(DrzM~YY6uoZh zY59GiChIRtfJitwIka1(M5UOkwthz?s%CaI5@X~fher9^qweO=;b%ab`?+`ZdPny|GPul_%Z*;QK*+#trkt8b0%8Ds{Cp-u&B>Qb9 zH&q>1=mc;A)_M(mEznzw#OyGAfX&v44T1Oss!|Hzs8GiZetN2};s37IyY{=$*)GSw z+WJ}fJ+P{%5L%Sfa(7o<9Lf?p9@w|R-^U1XamRYXRMTn8N}?+e;UkjdP4ZtKhdp$d zC1N8{zu_*YLa2D&dn7BI~ppl9Dp$JmV8M0kG{Q zSC2^W@_18X8HSCG?RLD5i)-${0A{G+EW|#u0LUF0NRh<#*IWB*9c~D|(*qtC%fjc7 z`I=${znM;*Fe~Joakz~k6_}q)oCot!jg*$1Ol&k9KKp?|CZs(@BuCSG`E(~TjBx#* zM<=EJEUTXSbfstvBRgrl-~idPQS#yy3TT7)D(cXHi-VPoE9=^{sQlZq*0|;>4iT5- z1Fc-iY}-X#JjsYIsx&¬=0|<0$>uYIhR&M0BO<@xH^QS}*zPTP5nd(-Tf~v(cwA zr7{4WW&e43tS)J*h<{wzdQK+YBNp?kkn`;H(M;;85%aTJeryuWuVeO99YEiS@hHP* z!PnB)|I5gleBHTsT7l^Me0S_6r$(>7ID_gA^|blC*YTf7jgD>tSPOuVo3;7*Rfrw1 z67uCG#A-X30pdL{FtWb94GcKj716zcwKX70JvTDaQKK&Wc(IYqEV_JnvK0&ct09ol zK%m!4mD%M5z1E$WLC@Be61v0foW-N2j+6uA8jz{agmng$0jJ^ZDZHmOS=*=kCIMo_ zUJCt117O$bDH!AjoC~~|G@?n)dsOc}1^pFoKb&?3!s>{2Er=*V{EAZ2MBK(tK$J== z3>Y()0Ivq(ra%mXath}063DuCtNz}eXm=SaYiM9$XLp;(pm-?9{QyE4@iB4Qjpp+1 z?pUh-$`teB@z||ri(Ok>tpFcdDW^bm&&o|10BbTb<3QxJMj!Km65QFjC1fec>z3v5 z0#o2NTFo+uGVsG_rZ9||c}BO@*2qi0*Pif;jEtNVkzj7FE&AU)!GvJIoELh&z5(!m zHs@!|FsQG)$y*OJz^L5-iA>@5@w2V~mjIBGBx*D zc*yZ#<`0lq0wVflWr`D1*o&g%xv|=fi2)DW-N!}0%5RR8ijvxgrMM7 z4EFFsMphOcAfN;TST$^|B?|vk(C5JxP*wINa%ecFd=RRwX9~I9CJ(3bZq;q29-ppF z=rdm7)x#TrBU2=x)!58maO&>B{J^)VRLl$Q)^_S}*b;aHA6ejaVJR*xB~bB2eE{Tj zpvjRd0`f3$%lqqr;|4nSV6Nw@nJr(!h#Kt<03T-+u;RHGfQSu8;2s(l)?%-L;Nl2~ znAl+)NEo45QYms-lFNr{*3wdBONwagwz@|^Jg%;;D&4lUv=mCX0SQ@PL`Vf1o7?<` zLBboYCA1s2q^+1Z(G3RTDgA+8AAz710ijKcE@i6s^)9!Z^v!-cIwl5&?P?nuCd9YV zzomXpJRTRLY1E++kEH6kycT}}J(}9IR-a$mN+N-17>gMlIJ_ccJ|h~Q?-r#WOr|d? z<;)7uwikPjp!4lTX08mZNm9}l;i94tej3!Q#N6B(85^9YxRDn3b37jLKPw&TTGlMK z%Sz+bfCA=?1Slu(=&03U?cCK7JpgK%E)c~WesA!9@3317Eh$zqYq4VmYbCh>F273W z-e;nT15;h%anjxJkQoq>>0==9n)KUsQjJIh(}WCN6KU6+Pg4u}i^s_&Vy_-HXU}qkx^q;t91uY(@Y0hkTUS+4)p|-=UUS ztr>1yzoCpfoyw|kzR4e|hC4#ptuh>9u50P zt>5*23Ik^e3?$O!D`G$NMD@;}Z&{v1HK}#JfruOY1@QF1yj^bg)p5hQxPcY;2ZX;#zru?+P~Hg90P0)}hSBjrsWCka zR#J1bnYde{X$4{@alLYlWi^NMznz(IUl1)J-Yn3u68SNLs*s~-O?-pjKy?)>fA{4H zZAE=11}u&6@B1U-$B<8!aq~i{;vUT1)5FyR6U`;H`J3Nq6XQK-O84Oduus z*cCwe9Sp!nNaY0FscPL8zU>Dpp=w3oT+=}4zUl%avR;>GlErswZDZqIpaKd+_j^r# zBO@Neilvo%vSErlf&qt+6r`l`(MZ9@CwC_%t21#yr&Lr_irGA2lT=Lku|5xHM4a~D z;0F-#LE+!<&%ja9*qzyW<#EWU>i~Q82?K*~q4+)BFI=#Q_cp;n_Lf6JqRdpxHVx+85It zz7%*m(%S|sYk59h_0N_J@HFQ|A01t8LB32${13j)Dk{z<>e7w76M{RzHE3`rxVw9B z5AN=e;C#V?OK|t#4grE&a0%`nu-No4ls!61>X44 zF_wEdJ!_2Za2KYWBjkcjHBUTZ-*tSX+3V7>&ErJhz+eGAqq{o@rnas&`@d{TDyqm3 zP{O~(o*AE>reI?F>YH1-wq^+G>dhRp@&EV-7Z>>$7;F}63u9AQ4O$mk8?th8PA?C` ziem7XnSki}*|ku5+}iBhH~XZBljVLZyD#q)4yUPbrNNQ4H$ECV397=yI>DO^-#~lx zuh|0V7NXgt_PTYn3j(CV{wq}mdH^+kIJ1|x^^0{$%48o}7$LL}cr|M)dYA zP|BM{E5lm}4-^2F2W(Q^P>--h{e4lNuKFH9Zzd%b4qC>lva*@^`S1AX#JnPC@YA(i z_)h$MeB}7Jy|c6FK>X-~{c&?*BLC|kg>kDaz=vN?w?6PL33Cc`nOQtxT%^4&`8!*L zsEx!3XLd)T|I8j!Je0r_8zz=Siy;o<$FY9E!_0i$xrKtymTj%@o=y2&$H*N1n+%El z8;e;!lvAB1!q_b7w2s0 z3owu&Sbd@G%H9XXHCP=H3^1T6?(jUP6!7y64dcg!=t`Ce065=?IxH4o05+U9voei{ zNP!F@p8!uh*Y4PzN!tAp6L{rMsaL&t64XLG_oFWDj`Ze(E_^=YdQ*XaeO&S-f zh=PpV8WBo<0305R9z}L>q!6U^tc+x02q%U=If_)k&DB91(Qm!_I}};ghnE&`nh5}k z^>Qyv%bR-RR!fScT>po@t(vYwfQ4Jnlol~i%j%~PQWUuYi>{VrU_Ne8Sy(aBgo|v(4z0 z@vPB`C)*m=Jw*hBM^GZ>DfR6~OBox#6&DWyOK`oF#tvC&1i{*->wS{)Lr=UO;7yMPDqs1l_Gg z1!_c14Hi@C%E}6NrQWaII^aNPbXX0Jg))y80E&kpA)GNhlR+!BuyB_`);#Il;^pnF zS=pFjq^U?NnCD2HvRh3M$I1@l5J;787$HTe`^LaN0MW$t!kko97!bXm7{oXA zn)lQ7E@86)w@`DxX|mXN-$x)vjfYFdfZ%f#6}S&p)1~8j zqIc(wj7`Esi6WZ5F|Nujr79m;UCoIoDjeZ3_vQJ&H|SiTAyXj2HGbtlNN8W*^x7dN>7#*iipKb`J>eX4GGDpTKzktxk&iG28nCK^FGG3 zt$1W40WLvUpZC@By6o+FO`*Ns+k?`V?DZe~ZVj@6%kB7huin?P=Er8DJ!vDd<{G=U z1fYXTvc3Tp)6WqYDc478cHfP@7c*~4ygVka`&$3L7c7uTc_4o)Bw2E$bDR${PoHQ3CJe4$l(p$b!l zuRY)ViQsRdCFuG5a2@@I5zvb7zKvQ#ix34#{m18;8Nhx2C(twy&2l0e3v+{vl(fnv zL7sHH%wa82m6T+?uS_^0fXJzRHHlIFGbeU8Ip|LQ&ayA`_O48<%>yO7qvOA%q#iH~ z?Q;J#0UBF*1%)E{j1^owG4SL|OG)+hNz_>#cVUC-9~~9dILn*|4;&eGc6OXD+mQqI zk|UnLA1EdkoEOyD5|#mcPW<}W|AD@3)EmxC0GRUsF4X+d(tv9c@P8T_8>_FnRWyI1 z5;63yIDp@A|k zwE_JCD}YbwrHZWJy6Nb5o@gZ81AA@*c!Q~-At&$z=4-(Owvp=xHYf#$rqSaYJbcWx zi=-8X!tMH=&M@6=42jw)4|+o{7xK|Fqj##%d#W4PD=_WPmMIq(*Mc1GI>HD=GCXEV zO9s7Pmk0r(NKpT!wl z9u~i5Ctc@k6&J+8$D_1w7*R~t_hiE-Mtp}8=6^0OVhP@Nk1jW%JT}f#S?i0vdVm!G z2F(Wthc>pho6-gbl}b5lcEj&I7sqDJ2gVLSAL`=aF+V*o#uiEdq$7APCKtDqljQ~? zevbd$;LVL>lXMMR!HpRNJB*{3;K3{gyZadAN)lf4P@^tviZDpveYEPsdy zT>^~vtu;|lqZckfFBi#>YYe5oc!#m5&|`iFUI@38z;ud@8FS8OCu$}m`;cRh6oyKqvn!YDU~AfV^EzUSg1{lNKm0L`S>^PCW2 zN_jB8$I$RZr1Pl+)?rq##Tg0K#?-DJ44>!kRA_SH6V(AGa!>B-;o&igHx8(P!C*nJ zi@uQ==s3Kuuz&vR2LUZ6rlvrxm1zlv56qfsmqsN+r^#j8XWJdiKnq{3v*NjjC^v&v z@9LOfKwX)@nzqCH`go-UXOw75I3q0rx1gY4F`QoputTVz4)IrWJ2M6o_T1oH%PoZ! zl&Lu|W9Q}N%@*`YRSW`Rd5G#FEgIx&(ibLP|jiF;FOR|+;;x784PF4*_ngMknn2;=;*+OsEHg%14~{GiZW<4kT6rj zCQ}bkkIqh^t12WY!eDfy`jo7!(OJm(zvvQ4i#HKWmAVZx3qzO6)i@7)*B7s8qYE1nUC1|InKMX}c85kJcaD2sN zFE~}NO-o7t>w|88Ep`om>Efbla{2l!%Kx9>7vHu|W>gm(Fo*tNZ`h!x5{H>u{3pqg z6!Zc?KfY7t9tKsQdvxjoOphoTrseWP_V0U)ni;(58+#B@Q4x``*KH)r;dR_jX5icc zovYf~mO<=-GZ;$STRS+wFGn~?48`~Kkdl%rbK%RP0#ZAe)a_^~OvB^3J+`q1l<`-0 zAphjgGWIMwAJjCte?1=iO>i)PYwH0TbGFeldkJHGX(A|A3FuUwS^VzN_y#Y6`j{tP zetrw{G2l&0?dz66$>wE8tEnLsqY?Q?{`tzaU9lh&(15`XpY{~b-K{o2_QH79E0@{8 zRdDd2DFLns0{jRJQS{~^L<1HcY9k5E&FWw(-+ru1Egc(eu6NmyU1`qu9>j&_KyrPP zvF$}*_7zxy#hI|p$W8(PyR)x;=YR^se+O1^_>Z@k2;R~G0Rckr^vB*f7Ft?q zz)LwGl*lKK_I;w95vnE#wuko^yA0K`A|~dt-75oMT&4`exyq<(ZFZKLsX`jW;kYI2 zi9&vo?<=`oVOqzeyHi|BwzTl2rs6$GyMS@w!SOM#*9`S}J0aLQC10jBBKMGkQPBU2 z5Qg1(alt1-X}=#zmVGuC(L_Vl?P=VQ3-tk@b)3JKpp`M(ZqP^xNb#ad?Y@dUrD#xrX`e$POb`#DE)NRh|U{2Mf- zj9Qakx5L@#i3xNj`T@g`Pu7z1kJJAsQBq9IT-A3YHykkdIGWf}t{|df>N$}%-5P|v zoCpXe*^eQtV)?4-6_T zhbn$xz_DEaDTLzfLTb(Xa6-1%5PsP4{0H(v4fVlnKGzBQPHzQ~r2n#sQ-sZ%y{{P- z7~7r2fhP5Lm1wP)2R@UnOglWu4I~3h6Udk|LUEw_WQ?=o;Im#n^L&Tx7Z)EGg8cl- z-{e?OLoN)4(&FKf%iHXMY4-MAQE85=3^VqzZ${S5S$U9If1NB5o+^F|+>Nezh0Xns zRlm6#)O4>enU&HejCn8CKE17H3hk)I=2o`0&&P{uKoa;}r8C~V+YNj=pCvk zqxenrt(p)bg0#j!*zi4er%1@TH>JCL{BGX`w zHg+1^FFByX;8+pv9)Ho#h_RLw6ma?6FkPrbd3!EabF;2DI~y1oVH8Yz7dan7o!4sq z^lVYEHw-7Vwk`<@P|?{&BHspxg!N&2M=Ydzefs*slH6%;!XC$r%574BwIKH0zyM%E zaVL-9Jr@V}j@o0H@~YTF)5eCOttPUis-$A^C+gl{OyvOB3Asu&CJ-1RGBPq1bGYLa z+0l;(=6{aQy;)Kea^KYR%7EJG$LA#P&cVgjtpQ|aJ-qf zNKXn1f~o~G{(aPU@&F(NgP-$fsCt|N0Vgt_+z4twQ&TMgrMu_uKW=*l5_0dW*JC~m z)d&ihU!bHV{HY@O1WY1S((&f+Cm<^Zt#084Mag%XRr)5jwyq#n>Ri8u+1At)`sxkA z8t{Sr?T0u4eqqZ(vV~k#W?^8!vNse7s5ZdUI|Y)AO!U~z&HyC~P^+Ke1D9^O)FtiXkad^s~SbAwv(1`w}AC{9R@9h}-=g8C?UVr!Owb6z2u8-w3@zCs6xTK@?L z#P5Xx18Hc|7-CRbUMncpwtP@L#e%SCuVCHd%5>U1&{lRWi+~l`)HygM_tWt3A7Gyg zX9LMzA#1uiI<===Vv92~GnSLz(A41ZVB|gDzTHC?6_qc?(oj)R@$@8fE62b7C#Ia| zQf`32r*~38xTqpYAb$!g#M2PX8k&$S6aPQTUhqZq9!h+6zuL!AX6v*4WP08}(hDn^h{}ienDvA|NNoO61hI9bh8{EYDZs zZ|242!o)=GPpSt)u$$_uMdo7mh>ab4sv=U*>?P1G7E`DZy`S|B>hm1P!SXp8f>ALlCvZD_QTF~;2BDLcl!U{Nqs7|B8{U*6JriXcK7l+b{rAEB zYy;{E4-c1aFrh6m^db%-8=8JkNu}-Vtl}Q7RBG-DO^sTB)YCnh$hL*WN=Mmqpf@oE zNe?||^mgvn(55R{1faJ8`0a`Vy#w1s#v|1*mF>^2Q4pAHWm4|X0)5%Uq(zMrDfd9^ znnim`AB+|j#`qpE8QI9p8pr0V3r&i^ljB|K0TO6WSbJPVM=W&9i)$llR>Shm0cAOW z$OS&%Fde~pkvD>1fG{EAP_E~#Ft@}|{k(Y*?Zo%ZQWge~NQ5vkwm#Pb)yfeXatM-+ zzz=vklI@%(n@tubCIP<(+}Q75XfHiSrJ&8>y{JfObaehihT(}}1AU073rCci`8PW4VVp2wV{Rp=@xp!vJU#R?OR3w1FC z%onGH9{0g~U%B|9g>slBwiEOsDLMK0(=+3nX34z1Cy`{bV804C8?;9*zIu4hkrf^R`f7Btcq7iYU@eS~60|OheP_(CNC7J1Hdw za?#LTCB@lAM7dV9LLBm97NK2+#FwTtxnuh^qmHtRo-m+CnLia_-Wa{8UT=Pk5JB2O zis&A#PTNzP3P6TtEic{Ov0D8QQ1!>T@qb>bd>r$7f4NN3f<1y0|88>B(X}x^rGcRw z>m0ZmLE$gtb@9Ev{tCdm3~v*k1<3n>ejEY~pq^(uW?ecR-=BfRot`ST7-F(`1gY(eK)_b#wrEbpTe|;0>*KxNPJ)Bk&IX!4Y;u zIzqY}J!JmoeyY#TRcSgC+8UoW#_s&oCUCB><9)Vsxi|96&!{?x%u~b|e~7P6{OeZ^ z{QcXq2Fx48%KtiOUxae}37vuDXL7#PUsN=}tk>w|?tZY$<2#ib1UfIU_k!}|`OL(R z)sG8LBnI?mD5$6qJ@&}oWkK-5F58HVjO94A@r*{5D6V^B&hE~;pCdNUfr*HR=XYYF zgWcPBDTD`Z^E+VAN*4G@W(r~ovoAi(uj7I+r=g*tjkHBz7ST`-kUktuYvTWmdvN5^ zS4{E2`lPyOpKex}@oTmXl2DlLA>83Ocs@i*^FKo{y0qEKQ$$;_w40+ythQu%Z)68V>@5L&cQL3`HEJ@gMR^rNyP^Ilk=6U037Y; zSmyt*6mfe{@B~*1cmu$|ft9~RRo_-zOl!BReWPc zMro6lPoEdaNg6Q4-*sGV?H?Q*TpfRtxw!+7g3EgV+yxOUCu<$R{JOlh zRs{t5*!852zP?b8Z{G}0mZ`MB1dN+o6NHB%H(W%l{(WL%Hpu<$^?A{8SVTk}*j+h*n>*x5#rfsM-_XzyFc>D#undfh z|7;NFl=8~P^ajXG`v>F48I-J2J^pu0q=t4 zBdI4K4J8#S3)`}Y96_z?PZB5KA_Cj>eBT3u0ARB_ljd%rC?vq^gP-e?0*OJvPI)MT#9?%Xbziaj;EE?~PcI@{w`drN_rNQhx!DI}w{P z1ZM+0F$ieH3k|kfA2bF4Z!tx~q^D`Crc4TKGr;YZGX$_@DizlfK zPlCIPoj+e_X*{@Np}IEj2A;Q(yFLfRVk0akB#^$Ks=^!B_ofD2Q+(rrREJN=P-nSA z8Bf;F;&Q6{7yJdeyl80Gz^8Jd(3+ngjGe;9@3}ZR$pccf> z@?Z*#x6NmVu<-Hd9CIWf@7Dk(<|QX9A6h6t%`gJ=aHa}`lgn;pZEZwD;GyW0H4H}^ z@+64mHVdz|O?Ke{98tulUqzz5KDV>S(OFqp1we8E7QN2*A;w8x!2Ibg9-?0HJj@Cl zRHMh|y1E7e9*69U2^)y#;*@9b>i*gZT}UALPGZ3T!813mrl{QQIdD*w&!U7T`O+8gitm$3tEX}vWe z`;GJQn~Nq|mBZbqP2cggia2!Kfa!cm1owyd1A~A<~ zWS=G+7x2l7b94y+4Hy=9Sbpb;o7%zlc>!9LJ0LDQ7N5Nxgqv>1`Qo!hDk^-Oo}ZTp z1WqNOwHVW-J5Gz|_j;G??o_~^)#ktb*x1mZ@l8BJ2{^L8M`8u;7j9VC+gAe1dDI>< z`87!Cn%~&@K7vEmivhOF+lKv{G&22LdLUn8*Hw0^nK#6<@{=7%D+dBp%~Os99VN{g+|^*5@?w zkx}SQ-_ln1@`YY`^Pli_dpzeZq6U}v?zCEVpKdmnxXhJe_xB+477u-#3;Nal)ONky zbquwu|L;RT zn0l|9p=$jwXtT7o-q7?Rg<&$Yv`kJ)%99W9&F&lRDf7IaDU_431%%g=B03%62T1G> znq(l8TLV45qAWR$<`SP)X;()(J%N~AU(65$KZp8)+G4HiM@A+B>(Ok_XmH00o8fMa z)g-A~6`0XlVnC**LBxxd`PkMX&<~y(NlE`TtW=aXK=y!{XOWG_#GXt^1eRtKlcb!0 z2*uOgJs;2dsK`j=DnEh%RP}R?vz^i6iwi43ahfshbR1 zYtqSwo0qFyG>&%z7w>_B$@e8SwXD1#E;T$AqX1t@0ZcT2+XM~{zIxIIVvNT|BGrlb z&lHlL9~D)=uB_qP#-t}k0|b@Xnb|;%(R6f(ZFiZAySrr(%jUr^+LL9Jb+eRun-vt< zlbOQ0@NjRDzyR-uzK;h7Ls^xTBAAsQypvR?efbCIo zZ6N-m&94EHfrAR2I!`1j>JRu=rB7c!1fu@{ZUV)4bff3YYp}zDP@;n=3OX7Z3qWZC zzhbz0 zru8SAHHg%ZkyEI&04K2y{ZvQZC~OJH!lJ@5A>E>kgBaWBL)1gX9fy%6Gxr~yUzy_XT3c5X-2~GCJiL8)Y zd-ew%&mX60i5wW5)gvP#V2}dlFu7vsV%A#K2>0QG5T8RpUul~c78X|HXf$H3#K?^Z z#Hbs;$T;-S3rw48yhHH4Be%1OjivB$q8k(uaWVD{rKhJ4KaXb{8URzyuP{^;63}}1 zg^>5b6V#y^`i}ggGw3Nsv#e(o61q4vm1T zSs40ex{R(C78jc!q#{vSM~6UBXU)^tSjAulJDH*O_Mw4Ot3)TTzk7=|PV5OAiHcMm ztqf91g)zmmgN2%>OK5sRmGUE1ao{xg!4m`xj-;rvDj}(GU#Q%!^n=dI{2Mi!(#)GI)l=Xatu4l(z)su#}#c)VDvt^V;QUn-0nVkcRbZWTtm%#0IR^xCTs{lcfeg zS$th5ar{8X%9;Z#*r0H}<1$wu29v9>^dq;0G0{)ZvqFvoO}`86u?Iq zk!A}aYArilJujFnD3HxQwzcGQVyK?1!_+-&7r6?^dfMnHd=#e^-!-)a-zzp&_L_<}w_OXv(4A3EAA-99YzPA3WUL5Ray*xGcm# zvMVa;H3-xW4Wom{zLDo80i@jEpq`f2;LOa*`Z_DyKe0Tb0xI`XMp2RbJy%a55>E2t zHCj_`{r>t7*6>%{K#2H1N7AmPB~Z!#h0q7UT#|j#IMq|93s?L4&jkzO+C}LfZjSib znVH$hyGNEd7#WX9n%Fs)HUZfN{$_DeVBpqmYrFnC7ZYIhL7+V$B;+|)6h=+;9WV}1 zM$q*G=16;j0@M8G!8eJBFfDLT^y zSo+-pze-^c5hfUeGNr>$uXQnt!|4|=X z#fe{E?2RwL=n2ie0r2V^3=*R75>jH}TwBPfPA)F$YPNj#Wp@+L;0ppL(>OGu2`;|_ zm;(c7306a@XG6Qww*>$r5l3m5E1}F*FcK`;1!N2 z5?-h7wFx|`5YW?sNC8-c&mgAYU*3eocMg9{4%Xk$yw<=D1lqhUFPK1;;)ayDboP(Q z^!)&i$wv!Bn|_k`arm4DsD=qg%TSNGPCx#sLi3Bv8)nrtCG?)|B@%x4OE96h9$6k` zq+<)z=`rpG6>(-(20)Gh6U%uA3O>!sE9ytqpExZv%lcOjkEdXhT3phmO(2^TNcz(E z9Tv^~8W{G_vJH^XPK1m_Bn&PukQMbE?d{<_a5~DobPNpafvvNmhw4-8xq^Hwh0_H^ zU_}oK2)2trC&BK()r$dR#>J^AV^HD6{=u9Zh$EUla9Gu?dnLB90twKH@$q&6>Ki{F zZ^2d&a(*wUdn76;*$)y{K#KuH-)>FNAxc;E*&>r;fNxC<5=u>mYXxu&_=if5lckSB z5YHBiQM_vbnLvCM?JKh6xD3x+iF(^3aMo)JC?7{gMuI{kk>>&m6WhDIxcHw9?48vR z6x{9k4a42iw-U(TVDPoi(hwyN-H8sh>!WPcmXy$8B+Ms!XkdWs7C%3~khjy+CsFyv6?5cwdEi$@Wt=I>*pxw=z4;Z$xTF!1~XIFS+VZxC1V#4*EJ zlb=)mIUr<|QMT^a1Hg_zn93vt1S31Fm=618z)P}!pPHT?PUn)N?0A5>Cnv?|w-g6Z z-Bv?M?nX^onidFPyHK~AJLPgVB{ZNBsK`pAhyde@)@EKa^LLB2@ld7W4Iq>XgxKH5 zlZh0=;qY^CKzmc-sj75=!F_1hH(;ZPLO+atvAa2rRm%CU0P%vPthc+ng2)e$kjj>7 za=g5_SXSPoUuW5XFC%3pvb&=jxN9O~Yi=EAsgpKNDe9|Fe0&6~BVb^ot(Q~3d|7CY9pkxYON;O z@b{=-MM~vyo13bh({&2@D%fn!meTiF*@iv5qNS<0;uJh#J2?z*hf#T*9oU)AAJ z^Y&l#7`U(%u|52CM+B^L^V#~m0c%CvtY!;U~qb>@AGK`0*xtgoz808OfYyAcNK?}pdf5wF;I zk`Um%r1=hWhKBu_S*Nydwr?9?)%j_?u3#u>OgSttFij;bqV0U{JjVHsT{N)rP)$o zAS>6b8_$^786`UlI3>A8yb-d$>px z10f?ZZb+rS`HM}Aoq=$N)lLbK*Aa){z7#$>#ju%1#Wj7|L0=}Tu5Vn ze*V^<#KZ)!Qw?EDLBKj6R0ht8zsDK)p6g2^Gh<_YzkmN8Ef);Pm6(kX<=xl;8#fr~ z^`Ibs1T%hozc)5{z*quIE0C67w?fpYh#~0TiLtRMGX_O;Kn6LU`R`=xY9LX|3`|W` z2MALv0k{d=y+gG(lAH#CDpJatmsNWE1`B(pQaVA|8pTHVgLfpgTqxLl#nar}-Id|; z-y(b^OapO{_^coX8eHEqIx@n+Mjn{<4|3mkqnCGZV1dphIxA;ZH8RQpmp@cfk}F=h z;)_xEU|~J0^n)tYiOQRQ;S?7h!Ycj)I9fGX_=C}idAqws($j;#o}r*+2nT!%5-kry z!HWzs=Y$7q{$D9x1ecL!0VW9rpG0>p{*4N(b-{1@ugcHF`+vM-XB`5_-vB^ZYW=q3 zA~q_!Ey9`v|9|=``Q?Sy8E8jP_9n?d0PT8b2T&MVK+Ydf`}_$Cc6N3$GVza&nru$~ z3V}UPZ~h?!+*K0(rJ!I0u2BINcpJeG{qJI(w7{!q2JEq21-iyS7wo?pKzrl-npIzyUG$ZY#nn*xFQcKc)LcWYcozY4q&Y$T%46XPmm1f}MTwHOOTOoq7B_&}|o zlP$F&(1-~+u0DL5j3j>oxsViSeagDJBe2j2wZ+*u+faPlpXUPW?_7F<)Fhn?1BJi5 zkpR*3claO3-G|$9hk%VmX(Qlr0IkgLJUCVu`rp@)IUY;!D=rq5W*Ko7W(8VpX|8{9 zWyNl`LP;zt_|xWo0q;{(&^9LY{)DKw#MZQB!nWoG3Lo-RkS=?2o45zm8Bs zbq7X8Apy6a!H3U=)#N_la03PA_4zrepv_nFR|~e@jQ7Qrl@-J!#K67_{6y^LGGD({ zO#nI4YXoMUq907Kr6kcn?JklIYVgHpCz{x%|F|rl&C991@a`*EAH8pJl*dMpW#nM3^ zfrN^>4@xLyWUVIQSYtw2!ITcFdM|Kz>1i zy}jKN%u@t<+%m}bFc4#B_f~5UAj?Wg32Tr0C>xB7l(omTi4ih<_wHYLRh>XdN%{2j z)OQI_PHWZH(n7D>+4n8X9o{A~Hg>~4VFSnURW9MODpaJe6S3%0@Z?c}x zdC)1z*3;g;gh9-kTUIt;C>{zPG5}A&%;Q{sl)<;RwY|JMr@DZeDg)z~Fw0|2pY?nI z4lZizffh7Y38g4sn&|Tt<``R_#@W~K)}@E*BkFMAF{kexJFaH5{+ zH+eAM&%%74lU4fcPO^MXUIw(Q{euG#3!h9dO&8qQSR?_w#V`mGvTh*=>b)ytZdNDb z>1?RAH8oPwG3ZiPW$?-HeP3+;dEUn2zw20gQEdN>Lp{j3E~rT4Xv-A zUfa^2(xLv;(bXj^R{VzBQFi-<--{!`QFo)F$NiKxt*kz01$+X%M(ec}*S*LWfd@F) zyQ71H?VTMJwuM&<1@-_ZCD5vfdL*M+M&{=Uy^IOO760*s(}CuD z@1PeDRzjUc0IIrA(cZC4B{wk8dn;kw5))Jgg#;vWbSa+5wu*{*UqKf7Q(A=CpQAGI z7#|;p-Aip>ckVCyFI$6>^O;Npy+y*oxlj->?Bl)u>YP;m`EfBvNTQfA#c{AUm>%!~HyY=KVDq57ArridsWF74rH1`I0p z0Bv!f+jF{qU?4Q?Yu8H5{NHGe<$W zTy^*LfNhTrLdVv4=XTWwXeIG*)J=`QU|?G>S~4~o@b8p_-UUW%S~N5?< z?xUs|y*f*@d&m%AG;Q_jtyvZW?t8;70q0nK*DVTOdB+=-#_yrt1DZsm#)g`I`7KH# z0C<@D_3KDu*)V)MTGU(L?idI_+G7G6A20DoZ70q2JG|$>@Q{=C8)KjYB-Q=#=9}+O z_-WUQNUjYVxN)N96D5c+c>f-2w{~m{*n!IQiTeelm<^>W!FhLm@aqu_>=|M(BHINF z;8=l?yKknKSRCzKpZ%WO<9K0r+`{L6GH7hH3ozEClAF^O_r22tNFPW{%Y} zGtH+F*G)tpE6mL$M?mnwz`%HGMLRVJoWj6e_bwyUpwX?gpg_=cmx$VvkHW-FMusO! z1t}UxRv=;beF_n6tg{n~CjvppPE0%$fw*RqUFo$vYH0`ysNBJ@*kDzEWp#CG(cIFq z7ySeiw{OybQaE?%)30KH@k<-yFR{>tf1#2$c)2XVl+)F<0l7jJ4^q0l-NF?S|5c)4 zi={$CKm9u?91Sha&0(8fUBZg3^rR8MO!#g+6}=ZEZ!Nxz!ok5MZUT1JQ4$fg_aO}Ewh@$ldY%#i8=KVW38{v}J|57huy z6((FCiWz}m#&@x4BoHG0Yj_%pi_U964qw0%lck0*l(^OH098;_GO{0!W+RA#@R5)J z8zdncCjM6_U@iWm-S^&Q8`(vQOB6)?e}$Tv7`kixVK{7E`~R!S{-qs%2mhaUXY-wC;(#a$$ix{0f&yM;=IG$|@7{E9J@m1Gp6jxV zhrg1>3rw_H>9u+Ww&WUW8+i@k-9R|l@b#Tfo~=c7waf3>>U#axygcGVqPjak=$agUV zuA7T10!gmxPX>FWKAC=g1l)f2a>p2H6pfx8JyPS(D>i8+v!3M#i%f`3)25rY=Bw-L zWUETNtpf$q+xXfr9uc2O+g=qnZBM8ff1%vCc{@L$I9!l*JyqmbMg4NiuocJ(V_B%$ zW3qYR?jfYb@Y+UX`Sc-lyA+kkjuJ1#lGlfmgyvDvgRh3jD{DZ2=G#O^*G;w7xHiK; z9nDp*^Q>n!rP!ag0lPS9IT6U{L!!laYA@Nu7KMosp;^+m@y^FEUUF_MHadS_CI`l) z=UUl$slSjKrG$Hf=aN&n9EG3J(g%OLlebfnZfHYnX@=4g*MAoNsoe~2@%McW$+hq! z&<(WCg1w*HP}t@Z!u`2=Qs@hLd`>jnOR)Tl>ZsFAiQ&TDdApUaj*K>tv)~zplG^FY z_O4Mfw$(Y9%~Jf)hONL%DhIr?xs!d3vCG*E|H8b zJ@ms5`qhy)RDKd$E(d-lDC{mCr;|bL^y{8t+aCq9b4cee6J_527gQ0F9%RvlYUbV~ z(;WUg+S)+@zIefxNO^glZ^$Heec}l5mQ{J$+oaGTXClX_z>nbR)j`F(^*7qAq@gVz6+bK|I#0{ zZ5UcGN)?lT|7Q>VDZ}$`VqJ@-=2KI4e&!-_W*kmZRxcR=GPB1Y8vS)AiAt098tZ0f zhm7{;(PP1O3VNAl#b!cd+&yj=ZbmvqXK5n>2TEQZl`YY0rk|r;ec6*g`9gXldcT{f zQBs%Zp79#l96$4aYnbGY`j%GDVL;j&=Q1Q-kQGYF&i`5}ve~tr7ElDw!St$?PN^S* zBKE1Hw*hC>yN3;lM=NA{`ffJFc(8Y8$1C0V%l^c^DMwGofXI5b7UUU6?}MIjMya1C z25jjdT%`dTVuyEttg}LSC!r^}7qn5SC9FVYQ*X@?^(ppo)O_VC-Z|>GgOiYk3}@i; zth2wFtq_;UYtR-pyHC?v1s!hQd<#YmtXKSI`$xBeNSc5E6c{|ATgvu`%P}fye?&)) zs78HU&OaMOZL-0FmkmiBuiRHnN8R6!k5N`bU!^{)Sx)GWAuCg$_W$g@4>pChk}kH| zJAuWBb4Z9w#1$DD@@D_+JcFwBV2AX_Rbor!E;*6633JD-BTSuoLn!?ACJL+51b6MN zabF5*JfU1QQRY7LrQhSMz?T@Gu+n{1OO~qFUc^SBwAX^V(zn{q`#vZ~ZCI~LalT|; zNXM%b8A{zUobtQ+QFhsIi#@U}vG3Fh4QENB<_f00&g16=R4Gb%C{H~ki71Rd#U^H~ zhT(DTQ%o@;g`O%FUlqgAFK7^6WQ@YL$p#7CHfVfWwCdz$;cBiYwT&xuXIgziuJx@r z2_~k7+q}Luzh9`Z^-kRR!}0vk^lo%e*N;%Xzlc;NqSlvtUiYRHGW(?whtz@bhaBH} zX`TW-2nzl9%*~taQ$BspQz7+!OPle(Y|JOZE$#9fVrnHRVx_Ued<16!dbOkg+bz$0 zt__?df1FCX9AptC1rr5tRc$3D;qM%7`CO8UE+mxV($Y6qvHHIU{7an1TA~Em^uimeN>Ha&iTC7`#Kk~FR3}q}6)b@>B95A?ny6jl)1XO5F9@B(=xDg+wKTt;W znq={QMW-e(Q~6r8xmlLiZ4#);6R+c?A^kO8itBU~{|ml|6g*LQ^8l3?M%aXUw`@eS zhoc2~Ep7kpj7XYiO-*RVe{OltxxA9`OrxsWc(x{ZhxZ@{gUAj)`PQPjScL9!Z96mEZP^rlx|1 zK;Dk?gS^>CUsv72F^o0-g)tvk$xQK_0iHxZ%^D9K_yNW@=ux!UJpsZEdKvDplcn76 zU2go$0(2CY^zQpJ<~#WAyd$x4KG|pFl*TPTDttA{cF!|Iqi+-Rlw<$sC00gq>xX(e zS^sXr@p8>MRn5nHCi8@D!lmeqHEA+8>~DqaLi~V5{xVfO<%2HE{R-J~G8_C%Dta;2 zR4i{IM{c>@nZ-F9RnMQw3JfRFU%bsQo%wtBu8Jx{-+HU%Wpla>eynF#wX)Jk9m>1X zM4dO6ZEd4!#j~B`?!BzNnygQ;2z)fQJwHhAuXDAhCcs<5V!y%s)5`bzT^iKizdR-Q zP$SW+Ri=`A2KY+d;q3W2!ca37&F8!NS(57$n%0ja;CmcWeh1m!TcED8WaeVh zjqzJ4hj4(t#S3C9rJ9jT-W!u1PT_6d3F}&EsO~Us8ka=Qc!c4PJ~0Re*3X$CKO#J* z!sa9IGnSh7)+Ge?^OXcM-78;P<8U1BMXD+n$A{Bbq&9au@C4YCJ3z$Y1 zW5KpfJ@6_m`yhba6ZVPh6RfYzQ-s_YABk9w-XVs&+N^ujOiSiu3Xcx@yd^TQCV3S@ zWe}TFtC?0mx_@E1K;3Vp3DT)%>{)ncy`;aO)Zl)NXlqXeXQgI8eubbz7L--m7>DX4 ztkh+_RGjk5Y{OF5Vp!l;<v7cV%phRHJmX z2)c6Lo*^qrPyGODH5O;&wREINj)?U@-gS9iPMtGfcRYXe`ObBL!gqD7yhK%*iZ-vL zMsfS5g4^diGZD-NLYBR({OzBmrIgBrZyfWCj};`b*RgoGTMU)lYr_w>dUXPIztFAV zAG~Mu)GZp_x+D`4U4B|x>+Q7Ihd0`x1`3akiploe$(GQPWh?>E)cxg{p*`eHi zCuoz^Ad9^vS$sr{Mbq`hWnRN!w%B6wU_Dv6L9SnjxN$uaoVoBsTRl#TcNjT6`d&!% zRoiM)hr%iPJSi4`>s4L}x(Ur~>{u~#K(LtRXkkLTe7_x`!^&<@C^NqJM5*+AL2*fl z1!F|cE<)O=?O4tJKc7QO!$3uTA{-r-2mDSc-0 z4brjWe}3D4PDVQYSM{!T9qZ5D<8ovs3r+Xt9eyV;PP1v$3Ems{rY`xWRr-~RSN(n4 zm(CC)i}&@zrp8-)tpp#EOtjUcp_|Ei)GcHLM#qO94m+*{S0=S`(#P|P)!x)NhWs3O z5Vu3M2x{9mzOz@Cbel1*-q&HIip{c)gDGEZ9}PlpxltT##qozby^CpZQr?MJ+fX^-^we09L5wzR?X*OyeTmRRAAC!WIi@^{#$%|p+Psq21$K4L@VQ2lbhd`Tc?%zIxmgr zeFONKS%HXSUtenAJk%dO*AS?5WBEoLfA6}a?HvpAG6(fTo0o!t&b-a2{Df;Pe z<3e8WlTgM0WwF7-EE?J9o~4;QPrBr8zv(?sw6y@hlrGoTnNI1(1F~c5 zO)^HEHP_v~Aw&a1y0dwd)(`F=Ls^-grRkz!f-UA{<2OTD8Lu{T+`B|Wo~6iy9GnF< znJmNxyAbPJd6;;!b6WSGmXc+#5l;l%>&-e`O%`iH!3y`~-#pTI5?chA{hqI`(wi3d zpcP(pKI5LHndN8lg||yy^W)%TW3{@&xkv4Gu$)c#MC}H04mmB1dV#>XJ+#See9{7s z#)tkcs0MJnzK2~F(R@EBHP1Ki3Tu!09F_R%Rlkiy^IWsY&pDmP(<8T!)k$^i;HE6{ z@o?Ggnor7p;GDdc)r-eBKBq3yU8<;??Y25GP~dUUUOv6Fk}8=VHlgkVhKMti(nUe- zLfW>@&?t3Zp-Fr5F2c47An}x8+x;vJ%wV`KFxElTBSCg&$#-F@wIE&XD7<ky2nw@A zCtfkNU=mFxarvL&(Qa|@Y|7E-OVjQcJ|QOGn2j9qIEviJoeF0kLSKE5Yx~yIm3sXqgF zB&+N#NT^I{1YM;HBZ`OOD!iuL4naC6J2>#k5vt(@V2Ino(ZLv+gp8+KoB*010<2U=_@X|5PP@;8uwheaWtB^n1NRY45=WHsq`_ZAT6$<{UT^$7Eo6TuLI^n05Ms| zH|MZWdlZE``VdIf1uJN%>BK{81^1lozh)g1e@G(ZS69fY5>C=_mhCE?Q6sga5IB6M zR$&{C$<^zM(dnZrK|76n+V-8DZ{K*U`@*Z^SgAej_C@?ged_=aS^eYAG!Zw0>QjT} zg|Lk&^>>Y+y~{nDOpQg>~4)N2||`^Z}0(FOSZ`gj{+^8jUg zd~G-)gT>q&y)JiKV0QlyJQPlY=Wn@3x_ngef7I;+DI9=|7e5)KFCeQ2mq{QXxy5q? zDd#~?y4^&1B{}lu8#(2yuy?p0rrE) zgZ?3nRUaKCoi+j+2uLG=tZL^WrPLSb0xfPg5S|j44K?(Y(w9DlG0~w#ez&;KP1P{z z=K*KN1DQH^T2S-z*yvVg9nsqN4!fPc=~2ai26I{G$5#-uR}2D2b6)>vtg~4Pbq=PP zmhXv!dBu@;r?`*AKcN@DX^v5k`By;i8YzHy8_XGmwHLpnpgnxzk>VnPcS^-?xQ-IhW=c^miCHHtg$(k9v~) zwV5g22u-boBF>0I);s@*G>L7l|CKGQ7DtR8gt}XbBi!(nc*KM-3rSI*m|)o9-41^H zBbl8~lbB(TpZQ);eLV1q zGRii)FS4C*FxzI2WNz?=R{609fDtU{9xP*>C|qnJ_9p(}h2(05%EcL)>28tl+vOA4 z#|s{sq)BxKxA6u8h8sR2B{Mh&xeu)E1t~9P%Tf$K3(8Wg5mUsA)KUyRbz(D1jT2>)$(d3CIU!`$P36LoBQ^fgZY7@y5}ljU3h8B*GTRw*uQRJJxGOUZ<=rnO7%*F)9cQ95pH|2l#=O#&~tDw_o7xQg7Y+!pGc~!mO?+Bg+~RS?-Yi z;|ZLRf6SKxCM>;upZ~kjv0869N@Ig+n!VupMY77a0&N7ejL}*eI*{dG@6S_iyNZ2@ zaMQloK0=SCEm7DD`DLIFonBc6c4%^Ce8gd2v6ET+wlS@3h;kKjsgBes(q&Rgp2N>> zr~%UN_SUhKJb7}SX2uTkV2p1TVE|%L080w|)S4{tp4U|qBy+DhEg|%6rtzPymgDya zHBk1?3<#fl9fr81fNQWyHGPABKEY1Z$@JVK;QPJ3Ehn2p4|jZ@`cR^M@@Osq+~nuN zrOas_?xThej)IA3e5bY>!7y6~IvxB#Qa14gQHNIc3I2U!i%EcxpdntJ2}jJSsdo%B z>nREST#OsxFMV0_KofKU!NqTN5!|-+P|xo_--o@?m!8-)`(VV?ah3 zZe)yeVK1x3t2|djXzed?$3w~n$>D-H=EI-oPLh6^v?L21B~nwbfpGJGfp>|m?BZjo6KkN^l#vH5lo3MWd?yIz z3tt^hDV49~Lhg}BQk9l7G1_;PI%CCIlZNaXw{Yr&D3Pc%5_F(C02hvHXNXK9K+w`K zA@BCb64}5$TQRC+i$olJEtKyF-%NB)$|gp#{o zFDKwXU4Xh-D&tkmko?U&B9p9h^`o4Z)qquJF-)%*>ya}tc{5q6%1~18&}!BUgmSNZ z%03Y#(rjbO2~5M01byh2jII!Y2Y^pbU+pC#KxNy*K*7`P^)Dj9hY?^6(=8G~s0!Tw zkne{^QRMvkhsp_blI#{M=>7j>9|eo;hu(JNW{LDtheT&@U4iL63yrzA`}&6F5sNq8gw*-WG%ZKT4)>pj#A zARpaTXjd=UK<~ino#zZ*Gf0f*t+vEnr0-DJG&Y`+vJltvxQ<4_F680Ymme$LqFazA zm!NQ6gG*X>-Wck*Dis9it%s2EgHTK{c4HD%zPh3(v_x!77mvf-cAsEj0fZV=#`t2v?y8l<+W}4NIPZQsm96q0G7621ecMMS=L!8)-d@qm_a*Srz^(3Eu zP8Yc;4bTBo8bD&=k`rd{M?H+-i0Mo@g9wnwa|$*T6Gwx%16GI zWkSV)zyRX1`QalCrIGWSDy!^}LMOJ@fY?`F+z~J4VcshzMq87$16%c>>0^EUO{!Wg z@p+)Oy7~Lww*&qA)LM-GwvbGVY|&z9Q^lH4(SnnvqH&~vvl=o~wAk?eKz)mWJ!^^7!H zr)ENjMs%(eO_17HQ z?aG{TReM4%ZBAtLtgeR_g1|9l&gAuX)*co4J@~{U3&X3;ZR4ct6$+F05&rh6@epVw zuiri2nD*&X)gbG<;b+_HP>ZS83u2UORyMb#6c&XT{DK~0m-b}j&?w^{jAc6qIWp7B zmBH~R8cZmEE^^nvp7`k5O}^=c`iot_u> zFNm4`>!%7a2k+1&fNcmgCEdJ(Wu$z ziQ1q_#=)diJf$N#xP*e9SOSlyKSIFNF(^-J0L7sM2FJj;PyiZs;U-_iFQr~g_7+Ng zF=NQIFlaso$&77>ON>S1sIn*aASxTmcAD1n$pCah~y1!>Z7I$FrUKuX&)T306mF& zPhI$k8YA1SAPg98&aD-2TjuT$5OOqSM486XlbG&d1Qrtd)3Y;70Og&GilmVOE2o(= z=UBMCJz#=eCXR-Be()Mgz!;UC(1y^MxVt)pDSAY+ijD<=hhRSvUVJ)J28Wa4alc_% zGXy@yPKwaUPO~neE+J=bfIy$)=dasH!&meU`){?PVeLJ3c6Yl-1>`)I^5lU!1RM&t zI$pm-JeK<_NTfYt{k~YqtJXyj{6|0*`Ai^xN{ujt_{|F8(Wq)&U&0e4pfm%SPmjOl z3gVNV(Qcl;9j?F4hQc0F>56ODoOESyL9~~irSs{Uz!kCG3RT7QVOE1&@x%s!t`Pk zDzNg!$gCQiCP5svtqDjrTgJ%HVC%|xo1`7va3-1vSoX~Ir2d)~%(onI=izNf8n-fH;sH z3u-$ul82UTjb)vQts7D^+g8~OrP>y|1f6hMawaYE8M$D3laomh28}Xu4D<0}^J>+Y ziS%e&eHQH~Z69B4X`TkSeM931B~NJF!}KygK~`)^R(l>4JICxU5Gqfn*-}Yqhn`5Y z31|WKP(#s$7(cKRGgl*@wGPBaB^^InOrk<4vZ+?cbSC54@WJxIW+A*R5fR;iF!jFI zNw{1jAxwfbW#zckV^We0a>pQQA9SpA$1nG=3ueX*gycn&;)gAjz;!B5ILffOvp*_Z z6SCA1mJMpel0v18N$0Hmw2K^^$3}Ao3*7Fib7HYXnGk)>F!gv=80tb9V15#oWJLarjPtT`pyNTV=S+{~Ym#ixU zD@XHX4TV*L*pTBWuMrutJ0KEZd8D5ZjG?LMYo890hZ9M$D(WZqWIR=tf9xHYr`Vl4Vq}F{XrifGoeX7qQ6C?uq7ey=K*DL%^0?qvKUcDFWh z`X4{K_jb*uc*~BrUsqtBzkfRPL_$l^S6~W!$MyPRv`c4n{RcC>z}#L6dAN}ziulCl zO=X~yE+IM~5C~ub+n9`>_EhE(=nR!{wMuh@$|s_4G0l3zJf9(I5 z?in#M2pwOhYdDWD+tKx@&-P9Y+0Nds-d5X=Z2AT^r_FzCGff}skexq|2Ylb5cAvuo z*&MD;zAai@nPX6evpL8v`fW09W_DXoO`XuJu06ON``aVBT>CoAo&Q>ALhRZjKQ<7# zzhiP}X=hYj5R!5IIk8uu-Qy4|zk1DKbKgn|P6t-HpPLEj9dh`8sekK!ApTjl(|a|s`$q9t8E7^A z_JHQ+aU0pB{mf%tT2sp%U`(6k5vls!^S^V58gI3BtH%Rg0ream<=r8p8PuN!ys`$z zTEXlm3gMa31?8ch_wHPIpaE(yuo!$^^y#V2T-A9_B~HI}yIiHpi;MP5c#Xk`nzfB< z@#lr4udckQ48R~D)VHP&o4pOZwcyxEu64k>ZydeS z8qLUNXI9z009_dTZF=FzfIx-VYV2wLBEAiJ(mq1b?G0=`=c@iDt}7U@Yzea^%!=N^ zn}1)6p0@$b=UonXT)t1M&!k2L=Xm!)XskWb+{gSeh%e+>4+y4S%b0^zzo9=WW$&Y| zQMpO13bqjVcsP3BiBXk=7tmzyihH58$@mLQrxvWIb1yb>xd0CkUE`ay+j6toF*HWM zvBF%X`iKa`hW~lJxPR>tS&hi?-~MstH|EnIXeGsDJ8U6Nr)uoS=)>=;0?)Sk<;4B$ zpf%jm>lZFOHIWogM<459dV||PrFUEb`wQjfzI9IagVsI7Wp>V$t><$_UQkk&eSuh* zoZ(0lOwb0(0k%A%GN0t@vHBK?U%i#S$1md~)9Io0%}nLQYSFBv4{IES{py+z;nNxY zS@&-Owl(LA!>C~V`Ewl2DhdcxDt00>pkH@+KS+!(HAV6OVUyTBJ4h?Nti7?$H3x=Y z{Z1lOuG6@ye+=?3e{YoyfPgqcyFMY>_x1){%FW0_7N~hx5A=it#wR!*fQ|`4jeek6 z&*}Omf^g#Q4TC+=s|0R|4qaUVc+c|l7RitzJ2B&q)4jb>1~<{6;mTHj;JwSG%mM0< z$d}9zlZ!snm(5X)&127<=;eHN;V2F$SLvHE&<_Ixa$7>q2o^*HEY+w^OGi}zKZa!M7LYHcqZz9`q>O68m>SJ5FJtfZ!3Pi6a|-={J+?2iJ6BppcMyZ> z#qm<|P$!}W{|QyX#fndz4j{$rsnFgUeib-)m&P5~u=>$O zMBF%#@1p+^NhRJa&BOQZRrS{gj)n`*2l1h%T5zOk051u~z=l_s%g*u$wG0+7f_u zKpabO!eF9))->CA*G-`p$uaAf0Ik_hC{?wK+6Db*bWOT=cz3t4B~b%06`VjuY*MhH`p;&GoYHf1_)`qMMN7A`SkL)4Np zhKnJ{dG3?;W1~y(-EKK5ljIu;4l8{Ge)@NPyi{B zckmsl5}fnBnHh=E zPcgv(%gD^iN4UMk#eRDC%LT>)?^c;Kzb-S~$Cd4rEWY!$2fV5rqnOOx#dru+wU%T0 zP*Ftc>;4F{-QqvzdKx0+I_KHQCBOj|mGmHWh+NvtGh`{Q);2Hr+aqf%4gD8;sM)Cm zo*}1v{UHPOy&!PmmyBKXgP6KeA(}1E^mm(tRhYmU>yaaL8%DrnW4j0oex_E)=w8bA z^l~!uJ;lFW{P<{Icv-BQ!=kB?w8Wab9W?fHOFpvl6Ce^Wb}*9r@|eljwW3X>6LZk8vM; zm4EgA**L)JG;DFsIDNV1(`J7lgRjC-Mw9v`#&}wF$~|rX+a}M>;RjP+TTwB4cV?j~ zexVxn-Ugtkqt`~k3iv-Q15nC!L6ei~`$3kxtW;ZGm{olPl>{Y@Olg1{=wQaIlr0D^ zE&AxTFI2$GUe<7JUySU3Tvp+X(PiVCrydi_HK$sb)lh>0BtEvWqe55HP!LvBrM|RW zK-#Ixm$FzGx;BM*hUS)!>PJ|jeF9wxHVwr-J$5s(%Po)2x(zsfw*95%j6XKOo zl{}n0@n8@M_^2-?M0)_m-yp)zJ9<7sXxb}Q8X3x9>S3pf@O<>&yD7Bn7B0z2BXi_T zMQX|amC|qxRZBlN)s!ESR4kThY7e_tL4TWZ-UV8z`w}y=<>6nzwDbQgHOXNL>@TZ<3NmYit` z-pYQs1ZS)K*U_-efkb+NuK!YOP=+L7!3inGIc(3=+P8~P; zZ0sG&=A#tT_LmC@N*b82|Dc`fY6?`j2Bd{^6e|>7$~Y_naY3E4=M>=MP%NJ0v3+wX zkc|T}gBvk6J#&S-%pjJbD)u1K9w`IfFD}!BGv*kJiqO}DosRnqF<2FL1p0oetr1|% zsQPz?f%#@uE6oY7*#IB2Rpr> zhy5G(oX63XSKjh49?v zQ48`oO@mGeI@dwMYebKOw>gZ9LSkziU0j>79$b?+X_%;)zMVFF{0S6!yLn=X{fv*y z63EiPQ3)wAlMXr&C$vmC*o^XGB4wN`BCQm>rwG5v*<3fqh?hp%Fnv{Ycz*uy0%P3@pF#Y0!=e&j> zEpF>Id>N(bzHv8ju&az+;LgF(sBD9zX0v-r7~uCNYVs12Skf6T&UdoOZ}|-*qoeI%u47ui*&e~^PNw7sy{2N?y6cnEV)@{IlZPgC#MTYeK+iPdAR+eWU+7Y83 z*$eFa;T6|C+k2xsAVQD`lvWOe-WKkz4lYO4>oy2#z>x7@paE$^5xJBJg8*Yx3h4=( zXGCy$b@=hm{4TAJtM=@8s`2vicoC*<9T1NpN|<}v*rSjk1=9CRPc1{h_?79VLt3_3 z1w*X9Z;!tHL2&f=Pn`VC_x&!^+G|dymxcA`Ldam0S22|guPpP5zA+jmwKIv!(S@GF z5&)A;iq9f9-FbpUt5i(7RwHiiSps=yHzLVy9)h@;WpHaju-PCI^2o#=tAGlwo~-r_ z38>P9dh~{hZS>kYlj=3pioZ78PTe;x<(JP`6ArtM^PJdBiFS2T+SN1OmUZxn?2(@d zu#SbC(Y|drSTxM=>o`Xn`TMS{N#P%vFB=|B5`63Vg)ior9)Cc`+eYs6kff{c6Xi2* z7e`GEg{E4z@-x1Y%P1ppV^`O-+`&hmXH?g$*P7> ztzifD2=HRIT(;nxJ((t`Y?58?L6Ti0bmN>+`hyVR`$~wya)OexTu$u;F>zNVeIl%d z8d}R4O z$f+D>+_?LABqc=G@k3fhI1YD?D(r3o&8IkI()h1!C7ApzISoiL9z_o!Qx7GF6-B+H z>^|I96Bz)nV8n{iwfstr0&e$>*|~|}VwBKVW{-lDnVf(r#d<)mgc_>q72Wa88Fg8% z26I0=@i6cWheMYjS?~mrSZ6HAI_9|U5M!&prWK9=8xGG^fPU>>mErZI3QEP6IX1+e5E{=F*9aEIu zKm?+-K`ta-T68otv>}t`eJ)tMKnl^*r&zM3Q{bNYmXoHyhyb4)z}(Zbsk3PdD)^mr zXbkQwn~Q5X`In(S9!(p626;GwNbJP7V~W;mL$_}rk#PYuXQ-<+r_xNbRGb&Jn|gUq zVv|Wa!Fs`z$))3yyfCu)5~E*MxN@=UmGskvyheJuwgI5^0eu%ZS*0Tc9qru@(H?Tl;2NloLTyuqyqD{)fDwpGSc8L8PN@qT5PSwf` zZL{p=Vy-7w^T4{vXCj?ho)lYFx10{EVO}}XD1^-mlHi&&z8clSc~0w4%1+hY^QTv0uswx(3|U7L zB!{s3V0LEAnIIJ`tXOj_G3+i$xOGI4zxc_41_|wD_&lKst5(pgN`etXN|{Z*|6Ny$ zg~{O%Pfk8qnaiwn*_Jrjp&AJGy{{-sM%%{!G`c0(02oG&m@kB+W(*OuSwXb*5M8vn z3q{Og7(*&Seg*PzP~L?a$@ecB95wxHmUZ;#HfOm{)pH!j+fLMQo21ophALvR`-lRw zV14;)Uoe-t_O0~DY*~-QVb?+P?=s)xvVZlD+8qTA+1M(rW~nsjB55%Hh#SjKNvto+ zISv1(*ywhbOV*z{*UL{2fve?xTR9Ts<9o=@UM~Cs@Y&qsCH1c9v;L||q-D=nwt69z zZN<3F8`$;s1y!rNKF?PavaW3X-*`y(;33FY_?gN=Fes&?*VBA8qMb`VlY}W268}C_ z2rBNgxGn2A%8yd-WQySf1F$V?1%Gg;ucNUS%uLdQr5#P4$^^?Yw#Wk61D}>&45S)! zrBjaa4oS?l&o&@yRC9BZ3TKl0_u=IxLQ;3xK59Z`AG}yfUpy#j$gUa2nNZJ<5V_Up zn1jL6avjPais!x8l2x}kfp#tME2q%^bg!Zl3BxvNNsLd{p>JeI@zt8#45D3vTT)G` zeOrg_61>iDPcASy6*)7=6F>3iu2nkM1adhcC_L=k65po2HlYZXvYsi&eqWeNH?QxsR43Y2F2&U*-Co80YWrsYc1D^e!?aPOKnYcLQvY~~RJ;%60ot2PPbSwn4p=bG|gLeW`lOnbgdRHcUaEQXQnXWd0-^tslTkWfrrM6 zuao)m8(@4;=IqnGTc@8=Waflpy*%-1cq$TRBt{?vU#(o(Z(Qn#Zw_+mQ0r4`CnV3J z?WSDPN2#v9zOb25A&Edfr=uf*9=73Xa*dCqO^ylcq(1K8v(B3#cSMH1orjG2q-o~! zX~l^bkZysa5-~&7~XH2?ZONVU{0!#H>Yaxc6TCH2+BV05?S0**jKZWhJ#fvk#TipKL6 z7r(2+_o<>Q=DqUYJgk$PgmlY8B}KBbn8dXbUvqNsnB4aTH~p|old#ii?A*TG7SY!) zgUA>_rRIAg{NE^7DPoo2p2UGU^beiSB&T@Id%4Fw)I4QA6FP~WpoW#3V&Y(w+AC3| z4&q}?Jswd^pkOFHiPCXQf{p)Hh5u*;FZT1JZts}ucb9n0kiV~LP9zfTlIlUfL<)PHNAkTVaPvjEJMq~zg%J4Es^TCAPmS(l7*tH znFl4HE+`A<_1f+7y1`pGS>eY?Rq}YP;$+Qfc;XRm(E(iI(yM=U=<>Pem5YoL%A=mO zv!%#mDd?(ho6s7XMm=7+uM0|n#PAYwlFx;CMPHF7J^-tb_D=p1Tv)jpK_X26mx;Jh zKLL~=%Mt!{fjo|M=nQ&@TTOvf7>v;oe4FriK$<|G+$2ewjc=7A*VEXc&G(A`{n)6x zK_0(&B-kJII5IsQ<#UIgNTB^Y%93SCI`!+MkLwM(&w2~F%ju$$aI1{j6A+Z8aW-?B#Ek}wo9e&QQx68@QUfu8F-y|aQPJ zNMZOw9@Z1t3oYMK5h2l>*Ocqu0VkwNhPt9L8*rfo4je%hVz>s2a2bE`_vZE%k%2Wk&?-1^aPl z%5*8zN6(c|#8Y<9q3xC)F}#&H$UrAuFpdSQMBHTyTCP?g7WsS8UinA{seKd55EGfD z;50k-bsv_|L3%jZ;Fa{gxFJ?Z+)Gix!c2jD zkTs-0{zHZ?P6XaJ_XL9vYBdzJY7ySC$X0v1=_mniW(Ewd_{7KID5~QlbfmdjbZUnG zkN4I^dvt_++YZ7KRzy;mors2$yAD*E3`%&L?Tf1&_~&>6PIvc*+x=^{HreAS5H+rZ zQt*#abv7x_353Q`pa>01YIi6~hEKWbD8 z({BbPh=PknY6x1xBCbKatNEc-Ndq=*6@r?h=AXr%2Hu`=z6=f^y(bQ%PdNkjY!$+K zrOTUz+_HFe5IcP-gg=iTK>Nu43I_XLc7L9HSLLU9NSD(0J-M)sZ8)qod{}P%&5JBP zGN7=$#)16W#envHRKWF1mNWoij*r;Bww5bgVC_Eu0(*4<=wIjozgvG4are>`&A{%= z>BqTZ%S<3y5Ag|=oCreF$^eXR3=BVOe;VONq^p<)-5BvsR3vkNM-W`m^rv``Fjnh^ z0`ZV9r|5h9`9|-XHq@37HqiloB>?{;QM#xCzx3}9^BUu`H(XT8gsin){n5NaN) zG;*7YU@jR>7Z@}6faEV*8Q1cwvtjvQIc3{uD6Bxq2lcYDSg&ObRPf7Np+-h}%L*tPyMO?KgWw|3+J8$>kayRT{6vflyKHD||{=dCpz#UlDKmo3`;a z{7pZ=SXl5cRw9cY9RI%2D}bE#U3&a7p3?fL#JS!YO|n{~AgowpnP|>2zuU?yz1%!+ z-#CR}hHDXw%(HnImPRTtf#zW%59kMQv(8!v{96*qre_QBymf3yS$q%&LIDf!$>0Z> zM7?R*cIIN@ya8P;e-x=Fvv73Nq(4G;wJvIl*`mI+zMKemV`RNUj*LN7qG!8Jj%WNZ zB_oldMWg=JX3-+eE&Wx%5JdBqLlf1r?_^6COeDDiW7qo^CYl6jMvTVpquoy{C)dr_ z|6At1LphEV=(8YjR4BWyE^HA62FWt>a47sJ`q*Lz~jK z<9^ZrXr`$t2}Z#jC%HtLBVZZ8V*g2G)p%*9pyj?&f-07VkN21G8PGN+KD2TEERu#9 zK&MmJD`0nWOpc4gh^%;ggLou74BUlm5xMy~O)8N5(GIUO&>v@Fs6_)e2_0dLNGzujgEAj;%OgN$$ z_GIGG92{dRpJ+4-`MYs5={a~z_X;_b$wF?huN6mJ2V&*xb4uN6*MJErU-Y)R>yzkz zWA2Ekx`XA?m({0z4l^FL9mpzPT6P5|yh`zSWug?#P+E3Cnicsoi^*)-x96Nd=fX&JHnZVMO#T8$mU^*jLlCuKHOQ#2VFbDFMBAb6JhhP+u&yXut~(3n9B1>sfp!T z{3hFyjSNg>PjH8GI8*<^u#FeWT3#rYP!?|EIF?}a`$-Wknf;Zo2>>T`VD!JR!tek6 zZI(0knqw>-E;4*j<{jIkBP;rv_p)fqdXmI$tu z0V1X&4^jbi`BtbTVTlud8*m^7KNA^q*r#yr9voD!V+<>$ZlqG|D351!1l9~~lVt|% zeBFxBo+AoM^WJnWeg``D+HVa6zIZaF=aLXwz+hR>) zdgK1u2GgjAJ%0`E971>Hm;OZIVFKl;MC;heDc_JawD(O50LxG{L0+>Z?z2&;h2FF# zH-+=`0=CV5Ny@k;!ca@|rCQpKIkakX*&0w4&H1Xqt!ZymPJz#~lsS$@X9dXy+Fn(@ zPVa!1h*m&ZN~;!sjm_8l@-fv0kV-O86M&`E#$V@{9V?%Z0^F~PeVRqs$J}l*OxTcV zsVTU(bDoS{4U~KW0+p;)k9lbcVij%0Un}F)^!!7oGDkvWf|?s9!cKA9v9tIzbiN-k zhd_2rw~|?w4qPQfalF5j$uE?Zlw9-jc(`9gE!Q1>(@!C5Rn(3}IUV9nt0qHYm`_26 zNcC_tE=TjjmjREfY_w7VmsY*3(CrF;O?$kXPC4!nwW zX|1QT(o9^^fn|xPK})|G_@ALwH_tqy+OkoF*OYe}{jH{}`Tg9^jqKr}S{VIjY@+MH zcDDs&Iir>mjl?z*#w@4BB8psR(BnI@fYk`zb zjIkBPkyNavE~D~_vO{OZw5*zFd=7%Et1arSW7;~R)m?~H4D70Ovrv2fmw^|ePnzzN zbZiANsn8$Y=eNp6dmu9=slPsVr@2zwh@vhC8u&JL;Kvk{KLJ*74kTEew`<6nd(uv> zjZIhP8`&R?+Z*e`jy2p*a|acn7OqxwxZGG(+<H6Je!YWNt z)=`v&-Qbh+mQIWy`fb#nOs#@g*4MNCMBKlAE$RwO!Yrnfgfqh3^c$_$oKrqdr^|gN z7*OKKt592T%iD>e+9Y91=E*)P>+*OnWnoHiQBZgz~k%Z8$j# zluMFPoc}=%*_?FS)VOXZ9!SY#-%ia|x})b63rLSIBKq$Pdmrw;>?35a$5H%?Xk63^dpk z54IYRW1piuO%)2a;SK?>=S_^(7(|Oqax#?5e$m>G6vCz56@%)iF>zSiFOuF z0YNOB)jxAb!r`o((xb}QBtw-t4s%-hNi}?$;pTVqypzh4WJN{AN07Ov@ls|KVrlDD1pkY7hT)IjJ}`K}KBXDn zV;L1;bo_QBh`fEydLCmZ*U!2BU5bM`$0?t&fdpulc>gb;DI|w zDJvz%_VOtg??So^aWwEg zAczdxe|b)p@z>G9#`|($-(+kVFcGl3g@v@eV74Hvn2rv-^+n(#FtoD_f@f3}sb#Sq zEd&kY08~FsCYMo-@rG2Ah0YG~d$7w6qk>U-~ z?KnQwgB?-7#8n#bQqAE0^vZ}DKd!Jeuo424Cq5&QlDG+%g+aVM2#8@lE=Cb6qr#GS zin}+y&3&;|Ebcc2)KalZ3pmUV#Ox$_(Fh;YxyQa_akmJBVJa3r)<2!O$ zN$3}~`jf*RW~Ore#KN#*yr4}+myxM?H&yeMIk2j0korvTN^_)N$Vb z@+X))Zyt-9%h_gZO~Gl(TtrC~c_Qs0bxKD1X9}gRx=9;MMcF6qn26{YI*msVYyF{B z{haOk0G<&A-Uom)rlA>lY`i0LW@MLrsj2zYX=!gDY%c;(gUUgn-uR%Ss!&qfWRQT4 zZ>j5uVg%N!tX`-w zv5UnvMh|jvzOH7EuVGzlO&7v`?qej{T3nb4A~lZpPu^T*N1J6p_!EFunT0S7%@j!{ z#T&*v+oW?U!rm7S_ufnGY`>>lvtQwB_XNElH_EJfATy}zM^sz^bFFq!D&-N@$Ohaz zW`3%&sG_bgyclE7YsZ|N-Qj`k_7`Gx$0VgTl7?n8>Lu1AjK$`>AI$ejTTWv=zBwk$ zXNFDeCl$(cXOw4=z;B!)d_n{yUGZk^i86 z9ARwZr;+_^hUp5Iq+%iapCT*zOmn{R?uBhbLKH7S<%H(M{C*4 zK(K|ZuA-npLIJ#1;R(^hvsPT z;Jt7taO6-dkT?>}0`?63U<(#>Orf06J=#W zR`%_!L4?dBM5C56vg`JTJ>0QZhS_S183=r(OqbN!W1ybwMIP`Uus z3DPBB0_j^OD`yg$`c(HOP`2X8w%BS@Gh?(dCNEtV{$t(pbTrw89yopR1OER5Is*dH z{12%47uO6x0H8a<2t)S!^xp;XU)KLRY%FX{oZanBHn+gAKu7#{adCF2mk=}e`(_X=E#UB3(!c&iqhE_ z*jkvHIQTr_eW&45cM(4G?eDaqR zaSscUM*aXFysBRb^g)j`WR=4y>f>8cl*r&lvom%l-ygtBK#OgnWtO1zxLQS zD=YXo*NqS3tH;TNz+>X z`fxKUePmo#OqJ*fggzw`_d9QnU3EKQc$`_mdcL`~_fK+#P}R`p!r{No#Q z@BLOoR}pc#BwhX5*=Ugd`yc0kO`~`56|O?wQ!9djqyb;4q}|p}{*`L@lJk14sBKqg z>YUV4o-F!CQ5?*jDN5f|i!t689@3D@7(vbgOTS8IE%S8np$}JP*`hsxK&Wuj`f9Y- zuLxE;p@}-Hv~WMpP#2Y}_M)cR2aiE*9(`UnPj2vej-D&hzKcX&=LFe>IOVgKXS!=} zd{VORe6{E8fu#2@Fd)$9Cj{vKy`sUVwTbzwXbh zUALZL(i$G@yz(@d2QsJ>#Xs{i2T(n$E z{3E;k)0)J%FLa!vEAyOwM!q*eb6a>o(@hw-`v3p^Df-*ax&sLUp`rbs@-cTa{_mD_ zX>U8ObD;*1)P0K17>MVj(yF4HxJR$&i+< z!KdQmn`4=~3hpm8jfp8aE#&GZ3}OXM&J!ih8}1f4+u2O&>LEGqU*D~}mllmuE)$jb zkAD{bJXJpPIPa-W!3aFr;3G<0CeTZ;>BME=T`FA+O9F}KWsq{Nh zK`Bk)r*p}lQh7#4`FWlT|Lm!*M!D3d_(!g^+do{AHPu`WYK%%`-k%B;vPMxqny& z@T1$9S0sOX3>F~X>fp!>XtAhw+gjze1zn26a25(f>zMn=u>8e8{0f*z$VCVv=I%V!Rs#gOUi>MOh_ zHtR>D$CNYXEo{~r>v2Fs+XQY5T0@;_F(!3olsGixqwFMmMY6&!LXVdz?o1I*6XOXS zdr;>{=@q*f(^q%Zq^==x-PBrUa2wW2)J)X=z?P$86=&6gE37w@k)c8z7N8+dgxBAx zy`oRf(0$2jB-j+coZggfWcGpEQ0Q!}%M8ddm0>9+b#RUQo;oC+@KkSr_o3Tqj@18$ zkI#1{Tw3BCR_CTMF=PJ8^=fc&)y~7)`Q`8Jrs17o-O|X3Jgnv+97Bo(sVJ-{hcY1* zRBTd&bjtO&83ExQZp()1^QAoH9ZJg|g#zPv3smyTgb}zZ*A(z|3EE@{SJO>3giWEY z`}o3xUw@xn9MwIo=U)?1Uk_u78~;W_7E4z!9mnt?hQ9g(mxYeq8((+?+MGOVPM&e` z5Zw1(#GjFg5XA(Yu!hqzh+&#y=kp}dr`PXgS8ADshVBs8gE_fy{1%|4hcGMmS8g(JaO^sk7wp)@}o?#8|1AUlUzld)shC?6_MDAg)Q;-hQC^v0;^rRr5mc zeB0&~?p!@6N&cD__}Mogo76}tVjM&vLFHEY4K`R?8#bhQPk_!Kx$v3H=?xPLOqgu) zh!PYa$LftINd);hj_HnS5op#f)=OUkp$0{XsStzu2a+ekl>RR*wrYN+GL*iY+W5&0 z!a2WMcnIudv{X2zlR&>{mqEoz=K_nmTKiB$eb|XZT z0LTDg!<${~#GQ+v(6@@@&dPq>FB~Zkr7jr4_b^#l2n zFvuTGKS3ZjKUoP;buWX9?no`HiB`t*!0VCct+uDlH-36N%A+4xDr`|`Xb|+cNoLT9 zuu(cHDlA8Y{XZ}ce+(t1}jFSFlBB z|6+I3JD$bF;Jei6>3DN+)%%l>$j{%us_ILgpl{6l__$o##Kds9<I zVB2`@^=A@JH`w*|qQ|Bi+cyzc&dSmQo7V^1*#}cpc14(t@F~fk zn%}BXT3WbnZfk)UnTC_0A;?G#{uWQX%`pq{x{r8Ko8-^P#r+1`S937c$ zKq{dy3^m-a+j%E}sGs8s;(`*(%tKF>eALuF$1??^Zgy27gMA(DwqyNg9E0HqN8;k0 zTI%XE)=Emqygd-TjXr)a*9E6r-4&fLdD}fyd8Kg{RXC}Hd+sdtISj04X$)GUWn{R# zE@8*2L9JqegfR-X%Ll5HO#>|!w2XB9%xvA(^HO?xdTMGIKh{>XJulWIo%Nj}J+6>{ z|K#@^wH%7tU2m}u75)ict=AdL1m$FXzQSsSezny-zckm>(lV}L#cPL7LnH0!$&G=r ze|;^4iR)C?ilJ{(S{ZMhFC*{N$i|__!JwWd99^7)4=FnsG$ML*a7cwjp>4uCI0`xR zeGM`ri#H>AZ924%I3!|W$@(Bx3CuT~4GId1Ox)X>Mj3RF*&1%jlO?x1AX9H@o{k#6%`x{l7H-BdvZ^xql7u; zxgEaY=r8WbzLNAWvm+6JdWrZTrzR%N_>fGqYrt7&#hu)rF7;=u31?0=J3Y%vOWjnC zIl$e{mhdPf;o~aj%f9|z1S&IW+HBaz!y^G-m2`o={2JtKlOW4vF!C?D{-3 z2_;>Y(EmI&o=qYsk-5#z&7H&LPEWYm;So$jD3Zff{dB&H6xrE%cC-I`=la$r@Onoy zhMu2)VsTgpwhW{g0>K3T)s0cmH=4KR%u>UnV1I8(=6thobjgkN)&`>$TVg+#i$OvRFQz zha=$hc-@%X7R$Cl^|L&$wmCx(W@TmF9hwXI+?Sg=!TjK=?C|fDN?n9uLWOVp4Zb%k zC*3tt(A3n_aC@=&{ys1;05m5=Nh`A!=Y6U7Twd4L+rJaXAQjyok0|ECn+J^T>?GV}2YE)1fp6WWtD<7cVY&eMm1i_aAS=TYSS=oh z?Vk8=c(jngXlRgObc#Xuut?!CJ06gs5UV2T>5O_Y@^o|aP{@z(_DiqIg~Oz4?!bFe+MIDj@Wvjz@-@= zt3{6<@@2$P?{UH({b3AxzToJ8%F*%-HrvYl8V)50m;WV>J^TdB zH?Z0BlLntTn;!9^(K1{*Z?iKpj*w2F>h1Lv69-3SLQ#pB1a}7|GPd##xW_Z<^78W7 zOxi(YN13dqGl&qFS}=%F8%@?2gg~i>8zVo4<3&z z0rqxb!F=bU?{gavX@TRZW6w~8gy%PBmxnRi_UkQZD5|})OGQWlzeos#0|WvfuuR{u z7&I|4G5eBp7$(JL#o3|bE^gj-`XST_%<$33%phhK7s0*{1ltgBI}j4a^Ybr@EHud4 znpL>@)l^|Zj6E|gpmXfX<~znmJ!rTNd+zKF#}>v8?*C4dSk6Pn3i&`rML{(&HNBBP zK=_W=Yj&3OH;2V%p}~A&r%vt5k&`P{x#>hYql(JFzIf&wtb)hKP!q>HxQ|cAHKY;6 zp1NT#Rsbg_R6yt$>}O02eA#K)O;CC%w7@Pd8znq)v3wOcB0fhFAsN}`H31$T7<6Q) zVSn(tq*hU(GbEClFgJHb8xI{FT#C&Zoj{r9;qlDOrQ7MnA~81YqVz~r)^uJ*KU&q! zF(^d~rAXP)s9?TU!HF z*l_qKaN$yAEy~3Hj!JSiMR!xLq+!$kGXf zX!`L;Hr$FZ@f21jATj1}9SeK=aKq^q;%7-;$gSQ$n5XeHhR4fIh{#{R;IdnC2DwC3xcE5c_E)*l@`yKn`y1&e&1ntPHT93k#U^13N*;-{#pl_Ovs@gV%B#vD>7>uT3ca6zvc-MT^b^06$PT%AmES8Ok|Ld2v&5sN^A4~ z+xaMKupEHo;Krfa=bu5ud~OmKnYs>3IQ6#tpsi=CRaM~Sf;3~}=IbLatTZOA`CKip ztefopV=nAYG|IC%7L?++-f}VWp!@ZB#ZGE}59pqS@^H@1^^%g3Y0WfnlUUP)0bHX- z89|yTvudzdssU+f1+b4#8DB}LGMvg&*`VnTB8-C!5E2~pJBbCnKoId!Q6D^ui?buO ziHY2)2>$=BcL$wxH6PFWg8%90++ko~Y;{*|)Khrgm#bW(AR~tui%^UJ-RtORyI-H( z@=u==w5rs@Zw$og9vz>)2>pEj7Vi=xjJsNCA{0M)D;x% z1uF&hegehf%s(Oo)E0-@m!6PlHrqo5$o1YpVI_GvIaIiKBWE0XbYx4KGGKP~2hV<~ z8Q48L3mr%~yj*Wx9v;Tq{~|69kxI_Uh(**)PdAN~mqstIqdlW8eKs>UH^dy@5G4D3 z?#B0WgO^WoOojMhaC2&LX(StZ%G`Vac1Gu>sZgyf;kt~B`DMPt!-rVFX$SNUUOa)@ zvWxRb;;>rmtEM}e&^f}I9IL=)4n-~DjQl5n)JsHnmHy0!+dD>ku@Pi>x1dV-E}0Owuu zTe5E22_A-ZQ;B)r_gf}@+w`i-_@4jP@k+$ zy*jEiBOL-tr9@x~r~WIE=y%*tSP43u3Qios)4qx5Uzn-_88?hpnr16<>9^BTjkoo( zA@>5SZZ_ecFU+%s7s9Z2E`>asOu;23 zP(Hcx6}c&>R<~eIPUSj0e|9eRsXAMo}vT^E(sKawl}j3cQ;u2C`alP0T=jOyz6_;?NLU&>w~5fOX> zogOD*bC5p>iH`N-1_s35Q+i_?>q2bXO@iudGmNt4G{6}n%b>K(w#3HE1Eh!V8UgHU z@(vDTw?g7=df!R*2m5BON`Bn1t=S7bX<)0zpP(1Fx?e^D&YSLyu2{gl!AL^b>l)Mx zv?z|H<2lL9^01Q0;y8KJ->?YvqjglDnYhCP{KHY+p7wOY0q?L#P$ur4o`ZDpPfjsj zRp>nSy$ROCKgtsu6#u5Y%~^IG^Vmwgl;lq8MJ>RH{6|hp-Y_q)F`Ji-WX4`f~&M3fD$%I|96=rmvy~6@DdZ3wI>T< zWb6PfADT{C328?+`=GCEJyJfjRIP{BR{!|N>Pvb0Ew?Cn2oypC0PPV7Ot-qcc}lFM z0t1EL=TyDc$V$u0%f%x}f6P_x{!S!`q!NimHP)TsBi-pXsjuzWyI|nv*3w31A;=Z- z2N!R%{8}JhS|U})dM%Hf%_A-IJ~v787d6^IOTZ=w;&5iMQfpU9PHu>qF(qW`3+#W`G^!@b^o7e+x|_!)^plAoh6 zzFeb!wp7hPSgm^^sP*NzkQ;7FLD4D3i1IH&jJlm&l{0@1Wq;7$#mbnlFvzwOb6Ak- z{LYBB>Dm54}i)qZB<{oRkpNB}@#5_PN`kOZd7H9wz+>Fj{LKVUp) zW1##)kRJjXVqm|btgOxotsQ*F_4Hs2Sl9VC0UnL^l_$$0wBj##X{edq0$xt>RAoyI zk_rmw5GtxsQQ-xfI!bD7Heib)Lt41#gQWPfSChRN{-8hlfQ=o>0E zHi#rO7Jw5OXPupGBiiqlP8{-#1OS0TrDGs#fXdYqbL5x5hQVv9AMY;{ktmL>_TEeF zYV{>L$vsTM2)f$^l^S*?+Iwb(LJkUxp)k1hF=*pSHwd#;r;pY6CF;!rU82(Z+yjQv z7!kply4^v|F2_5fE57aR?N!XF{{hTn=Hc%oeL-N!O^-KksJJsTaIS9MT~n(f8y)Uv z%ABLcAtHPpn2)$SU}}8}_gY_OKcKum-n~^*+Lo`h(1-*ntE5qMKfy$h50sms66F>b zW@&9oG|pz`QzCxtTfu5jh&Ki4yO;w|nwHmZW$x|v)To%@z!5`^zThazc*84Qp<04%ClDBViQp)esy$H~Ln$ zujj!iS^z%eqUd+}$tY-4-iF|3odX&C5I&D{+%$wV&VY9w%19S7C3uLwc!Gj9b@B!L z@q_}@05phOR{-ImQAF%wYMs5wKm^u7u_77@`Bya$Li4BMi;Fj9q2l2INH?mU^Jk4g zcMO-MNf4K>H(X_JkoiRVoX-;i4pW?p-ERDKd0bQ!Y}?b-daM5%7mvkMw(Og4{&f;K zoikA9R>nwRSPHhOK>%g_DdeBM!Nl|jv&Xa6APx?s`x_aT03ioEg#eT`=OB#;w0fbf zJ>5PmhV=Oa`ur_2@ge`gc~!L&JlMqNXD>!ZMSFWjB6~*soX7+v_X9pke;%u2N;HCcdr3IOXpsnv*4I~)eW+*>%LEHRRwx(pbpRbU%d{5A zcH^IJN#!U2==Qm2Wl4COXIx_=#y*r!G&UB;XI3P zu(Z_Z?k*LpXF*H582J$DZ=j}^Qi&IJ!nKNKo#9-A3glF&t}^2l0NdHuvjf|T+63I0 zy`9@(W3-f`!xKf6{bHS)@UpmA!V0(g6r2y*)9b!G!W^!POWgfgYe+>rJba)EC-HK# zQ|*j~N8Og)_~CTX>{B6&Eqv-HYE;fxxBHoT9jn7xIUnsS-aONyv!`yk=Y-~-ZQro)TB`Y<3&M~8+ zjsq`$T=TIB>ZJy?a8uOjl77)`vKm3$<=k`LAGw`G63ID%LI>RzFAvWC!9bT93|=52 zBGM*4-Xs#Ux9{=PD)ggIAelKdxr4^@7%i`@P3+K>cl&wX?6GsYSXo+1eR^sG0Rw;c z)u@?DK7FRd|Lt)W9|UUk_3=Sfq~EZ&t_L$-tVrYI$^O{9Js$n1kKuBTrggsAW<)p}Z-oXr9MUOi6cvb+lu zJ=~p%*~~_Po|9=EjQQ}OXKhm+85Wi_z0vNPWjs^%)iM2!h~MM**y`-`)NbpGGF+XJ zC|3t;l*y5ju|ZSSc~*2iTFg>!Z<{A3dN_5z^w+OAf+*f|=*r-GznMeY+dJ~>F4nyp z4*JwAEG*hGwsa-*#wRC><#Bmt3I2)6c6toQ1GJQ7!B`Xif>m53vxV6HSg_L~FITX# zB=D5cfLZU>=fq@J%W21xHDKE?{V~E&C@`SgtAIR+T!1j9GdDZ})4ItFO$eb{R(oVx zTvisYgPH?kful+1{$EA`UTTAk^mjVL*=2*Duk>N90X+5roQ8HzY-aCvu-hgKE%j#O zTF=c|3qA1BT!DMUFJnnJYGeX}FWTy(saKWE-vY3hX%wqw4>kF$827@VK@qbl!?FC( zFp(Z81;IP5CjB8$rXz8@ZpZmvHJOtpdJgg;1cWSv{2p<=H#wkAYzmc|155Bj3U)zr z8B!sHFAq+&Dpneirz)g51!~!8MMW_=nN=ipe>XS3QDJ~1;>u6`;N3qM6M&>339G8A z+Gw#~2Pp08&d&L2BW}_xo9-={#-ZWFJMc#UZ#6VFI^p#C5!|~_UO}u?uGMsN<#G+X5(kDeQ|L{CBnxa z_gH?qyEDfqY}$YgLa|4BJJkp;E93d4uB&@`Nd1STe(VsC8fJrtT8(}vzVhl85xNy*sQLUISrSL#EdE&+klx!!I2m`uFzaWNotyiX(#6DPS*-zrJa zrdu`|&dz{P#9~DqqJLHA+`I2@N>+m~7UvmH8L?r(p1{*T2)C&v=!dY9Z)GuKZoh6mun5@sYgIfI*7#} zKUBDN5-`x;MoT`0oY|VxX1rI+eCD2DFhIqR@raq6nkt~O7g1No{B+?(xo$0u;5(`8 z31FZ{@FCM5KAQo}TMPhr@&4gq2t$%fOsr#e5CLP@lM{A<{=;iQ*F8)OM=wkMJ|&@{ z`~$!mUY*UaLB2=n1L*@E_~XC%HAn^>U;%{vJ%z1*`8SNf)FHD92D^pA)2$6kwK+;8 zFrK7Qz=NsevDxQM#t+66a)JRi>h0_6e!7yJ1*W`5Ea>z6`nu8PEXbSCrQL2TncKX_%h*$Rc_B!qC7 z4UE2GWH9NE3&)c6fs5Agxg#>sp&2RwYJ<3pj8@b1LRzw^|w0GoF-m={`KF# z`DtnE@qP-nZS+d_KQ;vBqN)Y5{Tpi!wAZ6K$tW(#%_P4lVAp^y_Oln;rF{P<3<2>oq* zYzhFV9w~U1xT@zr_H{QO@$@$;mq^k0Q0Lg=q{8< zw#=qvWtqvKWf~73`BcpN@o705*0#F592qDX(my_qt~CbKfTQm7#56Zbg=r7o;-CX% zK72BKd;j+NNpy+%6a+pvdBLe4-@xwRiO5&F^3|IV>zpF^7xQIdm>p z2m|K?;LO=8XgqGms9#mQy}e~+qXF0Bd=9ad4K)-)fhHS9HTY?Koou- z^(M2OvBL?pML^DFRRR^Hpd=22gz&l^=40N2F+wW~F<=Jy{@P)w3?qbFaeAn@F1g#- zAe=SbAK~|u=xKBLd;5H|Z!wwqCsz(I16XDYFr%C%Gg$%HEM73$cv56--H3=M46c)7 z{?41!tTU1qT3Rv%Z1B^CUq#{Vz!h1$HC+dXI6_t5s+3WKuN`sC*7TB4&tN?zC-92}5H zTwo`81>hy8{o`3qgjYFv`G5cXHaETj3}D>W_1iZ@u|GL9Jx}5Nd%);rK{R1FG%+be zBc&`}k3<>Zz>aWe3u|&hjEXBZ2FP5fOb)Ar>D70~mAYU7!!EBLli?V^7q+x4!*llo z!-G&Po~t)yVN+IBb$PxfyZs$>b$_DfWTY)CzUzH=sB+rv`|yKZdPNLPa*(zWu(s|E zNF&+-8A;3z4sPJ-%O{c*{o0pF?zdlCq6^9EGGqYot%fzP41RmMDszcYl9qmR=R9UF zC^uSjCkUdscm%a|v?;TYQcA!E$y8O@Oxch{0y7_&VORZ%~EVs`^3 zQRzRDU_f}k^?SXK_I%jFSN2$2{{9;|mfyIs!KNR-lWqLE7nzL`<}_MrlZQp^DkyQD*a{iZn_; zjOY_^f%(?x|K_nVK)lq4vDWCY$@lS>%EvM+2xKL|?{OX^EZEb3aZH6v8^EKD47h={ zncLj}NI;0ecw~yjP)H|Te;6|ce=&jiV z=N`JU;h+
BD~n7nU&&9`(p91erJe1q&SV0`>eAnNqKqjn}x$E*6!5b}MxR3R#& zn@2ZuY1FX{v*gg!)b!XJf|EL$VWbx@5y7xDx{vh-$W17@wlmp%rl9Xi>6FRr@`s9iLW;bDDW6xhls9$8_)(FI)(IS_&d z#Llfk0NHI{7G{+Pum*a;I~y8q55~H3xE+<%Xf%X?>C?L_5c7V2GEX6m+(_r4zA=t9 z0eBJ78GKv+56_t68Vgwk)ixUJ9~SX zb`?EA%qyV+a8y~%B|k!+4nD^%*jGV7@d3zXSZhN=F`w^kF$YJJF94LQ{{os6m3>mU z4-(u-y5}C`+vO9mZ8kUc`|&EZY72dnTaiVBN3Q`X%7&On*yrHzG^Rq5Yb9e9Prbs$ z#)jS+TF%nkyx!;G6qt=3r?`YTG=A1ZxI9iqE-q}k`H|8DEf*_*mC)gF;c|N*3xsYg zTACfV9r}V~iqH1WhjOtM^SGJ~dwYP$h?Di>IpQ-Z8S3vAdp*yC!#NN3BvrZbu&%By z$=EOr5?Ih3H6x?@^yOyty_;+c&{a`Tu70xG9s(*ABI5n8DZ>soIB*HB^6?t-K*N76B4URh%9Z(MHholCU^Ru1pK>@oF0f(D2BN@0Y3vo|uf13rEnP zzs$2}Xlj*=kI5R+970#Jff8nym-D!pzh~1?4)=KV8ChD&!^g1D3V08IK}&kwb6TOO z|1CzcIzFE#7+BASM;2EreR_v&b6z-BQ3h{wW_HVdpIs{ZisQio&T3_CLyG%StKS&$ zxEZnmc8C(`@G#7U{3|fYmWZoWc2=B@rzH65Gx}=KLOr5oHo-&W?Uv z*Zu}OtBsbhC?BPI1B2l|^2c?4f|cW{nybUL&HPz{26KYf1>dC$SpY#pFXDk0wTw1; z-}TbMy*JsBZ64}VF|cdo3I`JVzd?8bffPL4$WnM5Ee5*{wk!%cDkjJUB8>=d-ts%?T*dJAn(GuCB%Jl0!YhlY-{b&B>$xmp@Q z-}qGp4igulM61c3t$IB{j`q8Io4S@D7x zgg0N>d|%lfLhot_W>%#jVpm)=T6c?1#dW@~(JmR=i<-GHUT&Di4LH7LV{Hn8dMgGh7^bc%cKSXIQ5bj?v)Ka z$hF?|iDK?I?9u}GqvKcYwJggJOJW{8)!6d z7H&_M17gAwu>^En25Cr@8oaEmVED5A&t#Zj6>%LB52&=c_cj_4w1npuP84(DP_o;; zF!{}OR>@SEBynkIAP;(zeDIXA#1wjnx(zGJcrfg+=&oeQYlO#(HH{TMtgK++!jLE@ zU5y7YMdV#HXtprg9q+qzcnv9mHu!v-@~)4M4;C32@HQf$E_z#fbv)!1FUF0#6zlZVhFKR6$hpii9$;eA?j=V+jIW6Qcr;cuBv9c+Ns5C7AvrOJX;hA zsFbPSU#St@GU?x5;YqS+CbQTH202~C7yD)opiz4iZ9PwIWNlb(rQ*?-%1k$)8H=wJ zgL6*8F=7AAH&&x=jbx9)iNBTi?=8Q95JLeysYMweTI~K!D5f|aVb8PtMVR>*0Gwna z6XQ`%&nK-HB*pDOqcqO1O}wGA5wgU8hC==^+0AT$J=b74_L-_8OA!S5o{&dwHwMjVtB5D+kmUgbK@l8T5P znwVFMGKM4wih;H;&sh+WzPPYMgElGl>8G+{(GLex92^HSKvve)R<_m+o`2AcB_skx zm3=xm_<^v&AR^-9ur#70OS*_-L`p*KM;AVH?D+!%h?+|GBLr%7N=~nHNmWRZ^Jb>P z!>R(S;?*vZ<-Ew~n+zEXNlyCf?^DGHvv>RrAR~ab(hEP8>v5u9=>9(TYJD`UtdntzLp61~{UjB?DkuWop0BAcQOI9Z1O|4iX zjyUwPRc`58C7+P#yc1^2dnL6PqdV@mJt#c30P1Xw$y}Wx?-2Usu8TYW@{;im-P?~A zwg9ATjmvdC(@m}xdK|sXfM3Le|B0Ei=kxP43U~OMeYEbbBSsosq~asfVRZ&s)&~3K z4Z89488nGF{()p4R96<`Ng`gc#iJs%QfW8~FCM-S{f#b*{>Cq&gU)})(=s!UfuTzg zf#N&JcxXc^^dA+kZg#Vtl3E3=Q|X1Q;^EnGy9^|LF#!}M%yohHvb}BI*(Friigz}u zEILEuiBHUrqh4pssNPQ~>Hg1mL-?s80c(j}LopCM^VUP}=WyY`jiO_+!jDWKEL;m< zncl$94;sIY?K!ucs21tz&?aA6tPW{j;UeU>Ap{9#o>fs=KeDtWA zB5n11d-2Zy`-?4=tlVYs=X%!%9f^BQToK4!;K;YIsil;7quaMtk-&K$3l6x7HiylQ z^K(0&TnQfMy&*uOvYh^t&-^xUG#rcb_IN?SMj7KDjN8!+q&0zkG=rf6t`5jvs{mKc z;ct~ntE{M4sx|Bd9H7#KR>$oKU%(Yy;3YjlB3QCCpR!EcP|6dkF01^W;Te((E97+@ zq%U?j>*V5wT}O(&3iJV;`^2%lbSwpH=-@p<|!uKbs|tG(*YMxtnpXe(f%b6) zEK<$tA!f+!PS5G3C1{UfKxY;d(8a-mi~W}zme8{FlfShf!%pRI`78y%kI~o#9fGzf zPJj#x9zK53DXDx%2Or?wQe_iz%5kvdy8=-+9Ht-A5rTq(mzx;GIQ!V{?#+PxMlonQ zLP-}m3Fc#+zg>~Pa|6Jl@|%1#K<&z^8IUrGU4oH-PyCr26CJH$Y-}75AoRCPt2P%< z8G+<&X|0=>e|6OtKw$H|J470Kcbu^hO$&~}o2QH!CE0FeyS!`F#sMfRj(#&3+g7I~ zN_#<-T}h$tL#5Glt{?&|YOgyux87Dlhh?X(;!nQ6r6&9BJ-fS6VFD2E|Dw|}nDsn> z?sR(&uvOq?wu6s}_HJ=Zx9;mo>J7xh^Mn;AdNF3S|sEML-Ws?wE5i6UIvmCel zoHG#&19HBm3kc_1-8q^W5Q7m&MefCbojWk$H%hri*}I=!TZ>|Q)Ca(0>@TC#+;KI5 zgO=Ko8rV@fdPPi&?=ivs$d`{XV<#qU5oC0%!Hd|5qoc5oxY(Rin!*F3_i$83m0<3KLXo4E^Nw_ z_PBxtR8>`L3~_pG<8zn0d_-Al#|?haH>NeuAeMs@MI$8^wk!Rf2S@PM9gPV zR)mMsC=GY%`?=l8^K*TT;5YT&_1}#y z_CEuvZC+IV1yvOlLW`4G?d@quLRmp40Q)xN+ZYiZ-dIn#S_XYtNlXPId}OksY5v>O zu%|AoR9qD57rd3!s9<%x(#Dc-sCv$In`ABXm7;qp&J}2A=vU5)4Y@?52a%EDaoBme zuNiWzc2@5RMC~zWfrErJk#ZW)X{yk3^YaBEPDaY|>oMf?K=^J+GKoI)iq21J=d)KUGL9&mCFHZ}>1oe1aQ>Ki{Cka=7W6@Yx65o%<3INR%xQ6<170|I&g%aoJ^)WTT;&M5uxou(=56CT5jfwDL! zG4Uyrm6P2q-{yH}c(_2Lt~IuxUsNXa|3zqM{1E$ovFO z0PJ`x)FTqUKHZjBh2!AhxSwp`;aNB`ff;GKh;Ys>0&<5YQWQ!3&Gx~1hdYAb%z)?R zis%JozLrG6ZtO^AeTwW7MCDvzCm%)5gW91cRQ(H~P&wgN#iRerdE70{`J>QEB zBi#Jw(aC7M$ZMoMUw<`$k)JYIbcF2LEP3?~1GGT`RSjss#lgnQY7uT^bYV!AY{Ld7N=#y*CAXB8GDHc;C@-t+!(JoigqH*(o=M z`RH?*av6ZmawcA%s!Q4`5}p>fUsA~SNhJI$6udfpwUT>kB>b&co|?q->sYD!xCkz79mG=SN05YBWTjE;n;n#aE6_x8tCH zH3Tsm3iW!cvAVuu)OwIG>D#$cL3g-cuzA+hk#S+(05bKtsP3Q&;558HNA$F&==gTu zCPJ(_$Y8u`0_-{?6_etSdyyZDPCVIVpXQ%$L4U>jcjw)K@H*l>OJXXJ;8z)0VqTMH zAWEej4vd*AfL8-?Qy_*xH4XE01!P^j)qd|xw!4m%H8iksa=K4uQa+aBeE^}1gxGkU zMhis`4{Wu+Wnc3W@HuVfirre=tN|Zd`DcOnzO}mw0M_K>#(~IbjRDpp6}XE_OXza2 z_Z{2QC6>@#jJj1YRnUj=Y+*Pn>#Sa@ow2t;uLBXfoScFTv2bp#9mbzL;lvQYoELey zxdrfl4)(&CWXS1pb^=H&0TKPOvagfVI7{Lbxp6v;Nr8_$-6uuA%5RTVidIa`h=CXjB;%|P zgs|{-EY9#^W_C6{AfSW*ST%gTC7R$&*!R&6P*o13e$sJG`yy1^%og&xPaRF?-D%j# zJU!o-GG@NPYeX~vN2W+YYjIh>;50md`9WY?`86-BTgSP>aa-sed}NW|m94n6lu*?V z^%0QQfhI@s6_AI4Ti#y}95>K?0CT%o%W6RnCvLPq1bmz|z>4Q#0wOkCLHlUf*h{^J z!b>9{5)#L8AYp`JMe~)%ib63$tCpTJM_Noruhk~7^^k`bMS_45@YpF!yVQf|m;P8rw#jJQlzI(Jm z2)Ti{j0-zJ+g=^Gf-iQKSa~wBr^v`!M2m_-1?f<;lX7!ww{uvXGr z;PR_S|cNyHQIp#Uv*J{g*$NqfCe4pzFa}ynIu|C zL&Gb@oUlJg6_bI11dln5-zm=H0VA$fhcTe7GaA@=Y+g{CB-S*EadA55_Q=Ocot@A1 z4;|`R)mjlI^_wbqGimHf7h8g1>Ubkm-KxW(h6mpNUO6Ahs5c}l5EVm&ZvF|WnbR_T zu6hQYvh)cQ^ThbVBCz)&hfu_Eq6UtIs<<&N!HT#HuMAkA1?Pdk%>7?&{u8XA~|pfm7C zK@lBE-HA&3zaF{viNw6%uYjiq=Hq&Mpn(^`!wamyUm*NVMh!3KNOdbh2dHzgn8qgq zr6!Cp*vZY!=92D>W)+B?B=ssaR@GcCe|Kji{6O?X_;WzVN)p5ju0oEcH}wm72h~-q z{y9)2RFp{rJ01tzn(ry-S~cJLsrU0~8!au1ixt{@TTACRx~wr4;cfP2$aWcUK{nY_ zEFfjYxK%*;9SkHuNaF_FscO9zft^Phk?OC&xu$`z1GPnFWc@C$WXo@~IwmH2Km`qmhA)Pwh=kRcGOW&S+?8zUJ_SPtmaC$N4^< z6LUL!fgeC507ZNuI0r{X<8^am9g+1Qn#oM8i3}QQYEtyu zV91rujlSv)RYntN)!kTHM-$aW1f1iGE{3reb zRDn;CWfAZVF6)n?;=y-iuckk*;f1MaLZvZO&5ySi=)MEz;sA$)===iz88PlR&}^NV z9g69WUJJaO80`XAw7s6M`{zmq_?q)#j*qXlAz!Ee7hh)?R#h8*`9pUj-JKFIA>G{| z(%mU7Al=;!k`fZq-AFeGNSAa-cQ}vp|1@*WHDCOMM>%Jo{oMCjzqPishMEOK9teo( z1>E{FFjsgvy=ac_@)W0DAmoFaYJo)ff$PL*i`SK9yT_@%fx#krW=~HbOkI6l&X*i2 zYU+q!Fv8lPo`5knxV#(0Y}#U#8}7_mEx_ z0vym&as<&W#B#_SbnEFC1<6GGR=*qQ0o3^M+(FTvOOFAclvFBobP|t@&Hw&fn5#iR z9pe~_pMo=}5`;Prz$>-4M%f9}*Vkidt~8NhXrA6a?H7Pwa=PH++14#ADG8gH*v@;M z7#|-fA>cj{a~f=!*}S3LWPL7$ zyW2#lO(Y2C_QzuX!XDGSR3H-@DxOG>ApzsdxpBzL%6ikajY7blW3BWbyXu9GkvV*> zEUClP@^TcXjg=L!u(Wmc!XXWpuy7yMK3}}%MU@neV!5AG=Wv?zRq1VGQysK{Gpv=H zYwp`C2#_IICDV839Dv~(Tpi&|FkmU}^t_-F^z{h|6~Kk)N|g%&INymTGzMS*wp_Mz zvQ3Cc0ZgJcfG3`B|1`18Zw$U+_St-5sTJus7v-piG%`+3;Y0BQnt1knSn=Rn@32@y z78|0Bf{ff29zt;l5*|w)CHApo5TuOk%p?*B7lt1NinRaj^UQ)y33BW3Dj7&(* z=7CNvjcWDOLj`v4pS5N~`3~1d^T`vGDe37~C>qD=7K5Wq_+FO*>L3UOwFbv(3o~6y z;TL0(SUkt*?jevcvnv7R(GT!8&rO ziJIWxHk5i_&dCqeH1wjSnF$ecoR^PZ)hJPv{<*zzX8go_1`Zs1CC8wuDm1feuvG$Y zGir4rd#v)=uGV#583Ex5jEDs){RdIf#>V&(62agS+-ReJQ0k;WDi;2=6_UIYo%d4|W-A3dPU2O)`C&O;P;;LdVpt8oGFO^(@ z?bf0aHN3VKizRJ!b(N<|@8@1UNFX#ht_8(FnMVl%#lw&Y&KRD>pp8aEq+2O_foy*1 z>h8|0eB3a?RJ0BFInrkwR+A(#@*_Be(iNLVNRjV-qG2C_XySTlPNpsbh+Z2ean29I zVDtjZ``Jdfh}oc9h`H|!c?{jxQOGqL+gX2!QZ|6_MVa7woBHtZAhXt64aoU) zFv9ldlrq^8W(ahC9q-5W@oE_93~*)?m;^i%Xi@Hg0YY3uXUb4reS8i&fUwi#2mJY4 z=me2#G9tx%y1+%l_h)N?U#|cd?cyT3u88F<5S`o=+XvH3!L&FEPQSv!#C;GIcnH$a zW#E2hbbl8SlZc5DNj!6F{5}60b;an~T3&cb@hGRc5AXkdgU$yUG9@BB4uPuA{rTZY zGKN-l*Gl)<#Pa-``u|3UXoTa*)bZAjZPMdZd^&&>nf7k^jh-HEb~Y{{F(P@8aX4k% zhx7hoY+@8xW{1<;{$Ecz>2VfYoq0p3jO5uNh*+#t)omVVNJvIC@4qsei-!GMkhnKJ zAEHg$OGiiJ;o?Q~-~F|`DaXI4Eq2huKm7KZvr#SJ)+jHu(m{at*ZW4^{KQPGH+@vz zTyxKk5NuG1*0&&H`Y9YE_2yW^{;Sc~Qr0cW*QcZnAM0NaLf@p{T{lFd-GEif_tVb# z)QWFj8`JIdw%)&hulG$kfEl<$OK}+n1O`6ob+^A035q8d0cI*s8wt2`HQLUPCey3D zQirO;*IjJ=K=3os67qa`yoq|l3}{8V+%aotQQ|=9FMO_9{yY!A155+ZEGKiYFgMA` z$iBP8E0Rr=JFX|FlaX%pmy5*v6FYURB{D01;==Bs0Ncr*IgZ7?zSYU~1)yYic791r z>;-0Mx4X?GSZo!Qlu8scS8?&g!8czX8yigj=%}d1+2*`>;K;DIx94)% zi5PT{8ubMEKymS)g21lU&`gkX641~20`|5sZ#XwW5X%3vSo>Q`6Rug%?|FE9yy5$u zviUQ$=rQ~B$5cT-5>_M|7BK$w_Vx<1vi^%VPooLDlsT$_<^_bihZ{~3wqH|KXy%4W zja0E|jp&zH{(LI0-^q(^nvZ`Kh(*9Xa^yFH7nmL%b^_nPLM@npb_)G~MwOtDbVdS$ zN4b3a2zn7H-0rU#Ofx;kkjUMNz&DHv!E&CNebdF>(>=Ie0qMWDO}V+b7Zq?f5JoAJ z;4xEMGZ}rmMF|l_0|&0W#VDPlJq>w@$XG+4ZF6w-40^R)Zu)=pMeN@Mi7(_aN7cNt z2aJ~Wj6FV94QgH0jk1s4+eYc}d~B+(7c%Ue;=x#)+}kTL8=|Xi4u-(7@g_CumCbBR z&DLP>zV&T!(sj;Jb3q(>I!@2Uh-9&TARjq3;yao&|9yEGL-=3M*h(|XQ_}*qwZ8aY z4{!wlqxtag$kxtoOUA&UN+oaIe&j#TrSUoQ!SO?|hq`!pEX*v3vxg7@=?I>i#l5Zy2hdc zEG&aQ$lnFRAk?J0%;?3CaER;at@MbJBgBYpv2#uT{7K4AQCF$hLCR?A)a>`e8yxvj zMhXhlv=-tZGAJo&0?D~OBIL218^)nme#ggG{;iP&o4cj%abf~|%3fZL-A)CT%r+Tm z;26BI{z+tB8cbqm16GSXVcM>DqN2~A&elQP%w}F5Lkv?EMEY^T6pvVuaia-`BgoS~D07$`L`%I8CAa!^@3JjPJEJlBT10L_M z#-)YEPEQH%Fm>+1g090nCk#MG} zxbNw+QjZh@PQnp6QvP{+&-OrsOE?iV>Fsd!V2=vcfI*xz3UKtYR%sVPuvWm|*b1G1+(WKhY`Y4h0+*!RXW(Zbg1t#}_G zsx4sEyFMWte6LDqP2cH#bF$isGe*2El9?WkTU1oE6eb`G*dbIfhxlo@of`v(JwGVl za$9K?WqKZX?C;*a%MtpVrW^>w@?iBPdNfE%;u{=Mmx6+|f|gA-zX$|gl(4!VJCgM} zP4n9|~M-kruZb@-8Dt-@< zARILY_$I)9yT~o$EDNltVE!8lvx7E2Q}|%?Oy8&a9gHTy5kPp3>PiqSP&1~biIsJ9 z-WDfyKb&oq2p5%^R$O1;H6}b>(3)#s8cIIyy)pen1YOg{7zfLm4z0 zXqc&GmuM^~5d^>-vFq9AmnhScoru{p@azv>bxi#OpcRl1F{i^G_W;=+(TS_nL5 z9c-+))Oltgm$pe{dT%`+--=GVblzO^$Cl#aR&xmkL_(#owdjUvDzHw?@DGPW85kJc za;9K%6rH`VOHa-C^BLXYM*If;%Ed+9n7|jIWS@2$GwMrDm?J-MZ`fp{mVlXF z`X|Ye7WDx^Kdwvd0R~mDXKeZsxJOh>GYSQw2M@hQEll2wO}&VysEEke8@5sv@H%d% zvv6(!&fnYHS3vE8GcctctQ{TUSHc}7hvRyC$;il5xe4S^0jV8C=61Xss_F645z|x) z#`x=d(0}rK1$z#i4{C+g|7$$7_tR$EIZPAe)$@#)&NL%Apm(11aXHv7sK?pB+idtoB` zFSps?bx_cdDIu;X0{kcpan#lkL=zSsYBLe|X7w;t_;U4W-^RyU8eDeeS6d3bhj5`e zkzC(o?syTJrGQAV1Pitq`Kdo(cMjg)JEFn}+=Ht)tQsE^!CS`P-(MKM!Rvr&LjkJH zLQ5+hWGM%Q6ZjO-zD`y!L)8Yt_P#s8E=RSjjE=tQ@X92RkS)h>{%+L0J~v0hQYi!K zaNOee#UMW@4piK(F|DIB+$pc5T3h+j((s;TT!3A8cyjX2YnJAsg9zL@rCw(=BleMl zP|*K~5{2G-al!SA`T-49x3_6iA>=avtz-RUFFgd9@V|+^(kqi})OlS+ zy%|g7N{Wb#v}6)ntjrk7kIkkL)d(^kic!lQ+8qA#gmHe^ygU}m<*(jqM?a?@^Fj|P z41dhZ$N;2wh)>Ate}Ww#NXwJ|0V!)JLGVr@6pQU@0S8hZD&6--BH(nTDKk5J_Sf!= zZjUwCUnLZT6F)(J^~w1h^mlLKc;SyDJCwSHMyZw=d>r9VtBI^y(BCtd?S8?T6kOtQ zyzmB1C9}??&+TY#W^xjpg>ld@*v48)@oDBCB}#^gnXgVaddmqzfb#)c+7(n(Our=1 zXIO)hms3HZM2AZ?q-~24SCJOL?MA6luF#?dV0aQX^57JzMMOY6vN^pjwM1yYZtlWQ zm@!;&mXXYLyY8c3Quh1>gP$sfpC6%bDv*85C1JZ`F#~$8IRB&V0A&N(G0EVh*3m(% zx14|#tLepo7~bCArk!IcLRlEzUfUCslb3en!lulWs*n?`9nd8b&S=eWd7KQNl3@p7 z@iVEl9;x{PgJY$^CYTa`F|GE$Fe3K9!2+-og^v`)n(v2l_*^F$yS$Y|6Tjq;q>7lg zc;7HBGIuyj08Q%88u5B5FMJkzxpr8h8)ycYA(S;|hT=s1oH@aUL%??R!uu6=Ktf`0 z81f@Up!s7_Erkd$r6s~5R(3c7(j6SSBhx>wG0i%}ycyjvXX8a?`+2%dbf%meuoqSP z7dHP3n|@0VnCbq$W>v|UFc-X9f9`8LSL#4DHn*~~dpTLs0FuD3?>ZALdp%I753vO* zLf#?DvdVNS&<#$rU*&2JKp_Kz8XVI5OU{FjAe_XWobGxB5u84s{Yh_IR&lzbRevN( z8<7rkyt&)xe#HqD3de?U|MZh_R-CP@sEGUXEz6}^q_^i%4G-H!i?e}|5k}FBcZu^6 z)J5HgAD*pB4u)Yw*4AZ#{%SfqNEAB&k+44M=!}8XY|PwTT2eUePdeb3QM*kEvK7V9 z4Gsb(6nE+v-g9Ya|F|QDrQkb9Nc#8)wAEye^mpkPg30(&A?vq3<%<-0nhe=O;SfFUI$ z-Ps+C!3VJ(r>i5&a3lbH$J?{4t*uQOynJKGgTSV+$8mXvc(!-pbJsZ}V#9qP?B{2;k&+xot-PFmAcTcWwkRk zg}#16xDIk)e+D2uy0S+V~4dWwK<$N1Kf`nA}NpHLojhj*9xUvWx08H z=-%?cclTl8e96v^#$_a^OXM_xz8qH|>#1pLY;U((X;MgI5%#%fC*o6-noIv4hi=cz zkpMki%Wd~zWl`IV3%-Jtm9yilnF zM6E9({&D-EAV32c2KZPb5tVOFJ#D}gzZkANI6FPT^Cc8HDW zzp_w8uvHM74-*}6F!eqNg5BIuBRU_wPh$MB_j`CMnu8?T>}0}(u&|G+=|^VD_A`Ok z#C<>7I1kPFm5Ux4q=d&l7b_MrN`RA8`+X3I~QXgIfXo{ zeBpOL--LR`!^345if>N{xr~L#hh#iZQENLptGS1%d^2~2ra>)2>g^dzVBf}KW1#9i z)SH}!WQ1HWdpq}NYBQ8A0npn3e0HS)-U02R6A>Dist)HjCFGGfLF zRQsTI&7vcQ$q( z6c8jG!D@JW(w)3!+pV`OEP}p|xG`Uo>90J;q@m5>y{JiBJTIWjQ@N4f8Ec7|c4%)7 zvZ|`Bb5e_{f^9@B>erhE%6X!VQN$L~nR5F}SVSCHXs;yAUnd%JBREEENK2aJwo+NP zp{%bO_uYRD?(_b>y*JvzTy=XceZ*AxYt;MqsT(wAiOWVxS?OqcojTpO z3a8&lfLt_uUqyL-8D60kr4)<2lucxxDVf}yu5jY8Zq!+R*&7P%_ zuhz&^fpq~=jbQK>_PYGq&~OdlT_*g57eR^vpdSZA1E}W(k5!jJ$LB`?NtdUZ9Y*?N z?Wd_+kgXD~ezF(;8-_l>H%;Y<82zd%-#`bDS0`Y#4c^d8gvm#2FoW#i zZyb@2NXJN5V@IsH?q~WO+*PKtA#HK#;~dV(iQ&1BN+O=9C;;B;ioqBeDx>Pq4$-)L-<*GF<^-v)y2*#gSv zsFC@d^2h04Rjcg?OL)`{f&qypnN7CEyr%c(g@sfzcX^^ZOZ5SezhH5nlWNh_)CAtU zh}(gx(DA&cDaceD*uPIhrw*>H1O*XxU6_CW3vdqbW9|fQ30DVOBIWOm;HW22xQhNKXCI_L-{{S=dYH$kla5#id)*D@4 zzQ;9XW`1kd`rPjYdXffB3HCm&wG9jn4XsVQN%Zt?y0Jg5H5O~y+2zQv0p(X<>k7y` zJ3hw2+zj6sA8!Tglg7CV>u18^3?7H__V&+D9=Qym?d^KNL~iK>q~OXv0Cz#f%ISJ1 z2*0kZuYU&ueauE;XMcZ)M{cg+=?b+LaKLzYK7jI2nu{uFb~2-(hKHxUQ^`vY$W6e=m+Tm6V0_8k~#XbMbv`k`E*ADF~!CjVydqwVbm zlOK;YHSD+{A)u}_Aua9p(LGpNE1pcKZ*h2O38@Yl8C8@93>16e=wM<9z6R5BDh=Am zI{`j<9-oNlSW;mhg8Fo|@qfQD2|MKB?&hN8Bs4s{9^73yL7F@GSQB#7gUO>#uV=n%je>uRQ!Z8t!qN*k^W+tx6;X?67B_#>U)J$7%S$SB zE>0d%w`|g9=x(-)1;Yn&JXorV^e|FHlL?6%Ev%O^feU-CpCIJv!By#aVsg?J6k(~t zizs)4G!WS0%G9W7*|Ph}B0&mm!TI%WhNU^ZCz z`4eOpET70c0cj|uR8`!bP5cqex_+dwf-a)4-7gQlFbDuPyEkd+5spLxygvB2t|*b1 zldX_@^|D>6QE9{Y^AxF(up z@O39*lDPef!GX)zGEzsaK8oHe~X(_jf9M* zN|VL2^rk1_{pIfOWO`Z;o*1a^t^2{39pvs${xR4HEAjDUuc+$q#tnUGfj5-7ypWo( zX<3?VcPQhjhB;iW_kKlxKrb&E+6~C5Tq?B{76xIbvI}@FO-=EF7A*(EYxPZFr)Omy zS+`le%i(uN_6?{_q+FrC7)e&w!cPahULeYFxT>ZmTsE#R($p9jz)aqgi8$-WCz!fQfl2$SZ~v3(_!+0zI6i65;f!M-?Ie7XuA#3HAMZa=#NMiQ!*mT`)E47s%woHtSBMS?U`fCEWBloeY+39b*A6~}~ zv1Rnug&j68CT=gA>D7+*p0|7^)+=Mtas6isrHq@yPB^3k4v)_E?~YQh4V-G=Bh)n{ zNMjhi89jA0G^p9mV5f+zKL;bAU8@g_z4~?8$anlZ6tpYBedI?#`VbJ?;>blNJ?bU2 zpp;2C%_I6hz;T0|tORGbAkcteL5Ag5frP0&Y`+(vReAhlb7BZMIzYMUPOJ|BdxWx* z+|0s)WB^Di0j-qWL}8zI+1_p?{CQm=zFbpdqh_u|xC%&QeT~2hI4ItPpUl6DSJ&}0Ka!_-)ocgb& zf^0A85~E|#T|VF1+$$FQ6wQCY*YERQxQH2C5xCQ9+1uQ1EpwZz#2oBH7Azk7xfb9jz(dsEZ|hfCzh5$rKSLB5fe% zS@8@10C2rG%uuze4caZOtv5e>CWB!yv$RY~Oe|3J_sQuW>n-OAN^L45)aqG9TYw0{X#o6B*gRg_WAh7RVkj3vcDav#_U96F{Wd z#3V7#KV122Z~wDrLu5pR>UUp4f7JIEoaeh^rI(jhLK3v&+8bgU%p+-_rwlbP{pTP) z&tGyI)Ely?$J^KIJv2_b!OQ=Eg2|VhmR4R-6q^>7hEYTytppqmkT!vXgRhygg&5

cXn?=>W53+t;c#|U)kK4h#(*ethyNYAB{$0`I9H9wOH^_eL659= zbRxCP;>yYeIUY16u+J1hKTOIRuONsPAC8QSfLoe}v-2LWl5|Z=3qcL#R5ol1?#?_| zE+g!=`y+=_0Vqu%2&ij6+9y$QYpB;(&@)NkTl5?1DoGU6-^WMLai?_B`4E^xfF75* z1+hn|^}#qf+nOZuuuuCf*0aksMgVz`*3o4wtGv zCDRq$0w)NpwA6?DVDc>sPJeU%e0w@3hvVh)e56)Zq&6pCA*-SxxQVBnitd1BLYs4W zDlhETk;AX!S$&qCz=^?CGdem7j1=I*T-SKCC6o@{Pxo>Qr>>)VuQ(N{PX4G_-AtzEXU)QTh`3r7OMou$ubs z3u87K!t=TIsgx37G5$zhf$2zjhMnaZ-1Up&+VUl_&bWFRAI3-S3E3`362Oa`1%2GJ z=u3|$XTJNxc;kehyU93ntc7lotRqw3;BY)Dfq+$&5%9ma5xt8q9W0x`Py=~oCbsI~ z3{7);isEH&^xX7VG{cE6!LlJTv*o$oWB*>a8%?BVjHC-(`n8+RQhPb-R^ddGRZk4= z?ta{CR~o%$TR5sp*>NH$Pi*O+trn*wff-}0y}xLRWyF>Ozm z8v$jJvO)ThpMi}n4@9uR;C#<*u0#Tyz<{vT4zDW^JpR~yTpSM~6N*df*v6YB*5ZB(>tA)ys% z84M`;NpOv*dwZKp{w*u(m0Hbq5y1ek>L5iazjIUT3SQ1v#T2$Z0!HU^6*Ni{3}^yWuE`IdyA29 zlAdnRn(G=4Hmcde{^ABeB>p9m_AD)dO8&2e-XG?Q+(z?E?>$49M#{ewEU0T2V|=_l z7T{oIWvA#FUFKwFJ|=DE;9A}SWE=QDONfC0w{Cm;&7b*be=B~$j`-lW(^s!;DVx*j3>YZ@We6J_y5Js$F`YPlHV(^mE;$hs|$f!;(F7Gw$_#DdbCttuD1Wu+2XhaiS z0Y~5i1850WQ@VFkyUV8)03#LA3V{2ZzW1DSx3*^Z%P;J-cWrY|eHj4p2c>IZMFH>% zXC&!6r=ImmJnCSu(}79>ScFfYrr=-SgydIFKTJ-xU(oNYK^zFIdD~tv0cxd0FEg{3qYHBmaIN{Ne5KJr2W-kxPr0r)H6P~42J zj4?B?2k7(~_kf8wD?1Y)$AF3Dx(5T_hpKCuC$=9rt+Xrp*N;zU;3l=StW6(JJ|&o# z-2W98&HV-h_Rw++kkC$rjYTC5t}c<4^*=f|zDK=xv9$sX(8_Uf_WtiT ze>~lRTS4%}gOKjAn3U82XjlO&1`vIFK7b8T=6k;#G6e>B*Tf+qG~~Ee0LOrTtnxTr zmJ^0}wpxtg-3ZDC5U6QilPASydgepc%mr$74-W8>#|6*Wt zR>M$mcNe!z_sh9ukUv4-ZJ(nhP8z-!8}86Y*{mxoW59@CNb=Cc0NpLVzP_Vl#ZA~V zg(W5Y8=E#FtvK}WPw2INy^f7`_-yw(JK<5um>G*+i4y2!guA~%TrH5m z3}Z`rN&T0AkX1$5e%SB_cLbs|7HJ?D*<(d_I;;R*lH=?2%*;pzw*pn?Bh&*08ODI6 z1c2(c8_V)HYtz%UKmpt3d;9q_Zf8>>16sk#>~zX-U|+PgyfZVWTdIqL`X}qlWtOqk(Th&O(;y8z#Phmvnd~~N zDRzQ=YFN>4inuM!-(S)xp|s6)b+bTXQG!R+2UeQnx2aj`oe?~b<7)nfyvpS~2J|2G zkumd*pNtr|u$3{r0`JXdFM}dD2SJa*bZpgIwIXRMRQazg>edR; zcoXzWS%`siZ}(6}))hA`K*j2OoD^oz_P`i(Z?V>lVeV+2lZ}_o z+%OILF*Xf`7_9s@Iy8gNT9e`CAruVr5Q_`4fL~wA1T1Hgc`NDaei;hBEF30_} z+h=#wB88WaFO!%3>go!M^&?x+=K1yAT`;ZTFIhs96feT13~oC-#a2=Qk8@}-7aTgp znudnWJL;2g z>FFAO5z1u%H-TsGQ16c>r9+@fRI(T3Rq)?nVb4~{#H(7P*oyFbN6;vQfSa#Gx|_SZ zDqJBxLJCnjsDmV612xd#@jYXsqnzv%0qOrB_X9UZMMuZC(D}sY6|Cw;MtR`j4>eR2 z%Ga(0;*_7UuwK*#z!d64?Jcl)h6@j2lc)xX)(>w5g3w6b_4J5lWCW$0qo8Gq_~!oP;79u|11_R)MuH_-y}8`B`}Xk006HfB^E>9}t#W zzwEh5jLPpyu%^J@pGl#(y3{%c>j=vJ6geoM-RSBB3PUUC`2%X7A7Rn%?rvrl!SQjk z?dcz3a1Yd5cnk*5DhW$2DjJ1rQi289Mqr}O)SbaZs!^g!F_LY0p}m|v$vjny_=1Jp@kN<3nf{9))CmZkSWl~P5!YuB?YOaxUy1_ z??3R)gil1{0`~75M0DF2P;1}d;r*+Y$4X02r>^q8HS&A7+yxh&BWPGYsXe75z=R-a zzV8SrDlCM~lwlV(+xe?ai9mC=BlqpAH7;a84c-Vg0#W#xc?~j(QhUx;iUlergI#Jr zL#?8dFSjGmiVJ^Sd(54Rpm+wokd$css=B(Pu+Ru~r8zh|P<%U|<^vk;U3vpGq@0Tb zM3Ub~f@=DE0)7hjk@oyy5Mxo<^uHQJEBCz!iV=bS_jY7W#1Q_BjX|YdL7anGh1OV} zA6QylwVx|f1NV}g|E!vto72C4=V3V>9o3a&2ai$!S#~fA@V#4%C+77Sh95Sr25r=2BxGf6FD(RPfFN)3TLXT8qWtUejrRa2 z>bZWi2kXNe%-4B&l~3-ZD;E^yK)X6PJOs7yNrW>DK}}61k|0|QgCHsI7L4$|Z*|U1K59ks5uR$3++UHZBlJ_)`*+4f)NZ9ML)j-~nYLV{N-Uj70&8bGC95|*0~0SWi; z#>Ux=9pf1T>JJ@VU7}LuT-?s`yJP_`&iIeIo0YxpXY}di4SB2JH_&UcUT<~Xk9ZY) zgoC|5K0Msn-Bn{>oC5@IO)HHBR9;^~`nXv@FGx}Xt%|r;D(da%!UB<(F`Pf#?TCss^pB9iVs0oKbxN^Z|NsFV3ykItGkD zSdSq*{X#(e-#j^cw$w>{`w={u4Mr&*h>AVh%#4h9Qx$=?ksMv$zfXb{RI>WQ|wjDyn?6ypQw2 ze@M9(Xp09to-+f3gCU`EcSe37!VJnQz;*^4Oi4C$%s68<=8H=Jtm1a)A8U{z28@69 zF5k3BePUC%eXvLD2?njZyj;`3#$o8*5TuEGrC{X1YG^kNJ&&Yoav%%dc4bvJ9Aq3f zM?tw-bNBIp?T86P$JV5CyKV=xl0+ElmgXN|*fxljjgR^NJ0+p_KoFZA4GqmWvd0wL z*Dkm;02Fct&h$V}<^5VFGFrSdFcSIC^{vQyb$B{)7n>g_$_EsS29BAwZJ`!7CTlcd z9IGDBar3NRy(QWMWEe1-c6trgZNV&3}pCqMww9v9q{yCN8~n=;ey^qvRiAs2lvbATfx&Hd>% z*Jn8Ftb0{7-U_aD|?-S{|&1C{HO33WIbVU1o?uliRnVA|cZ~Vj53AN)tC( zS>8xBq$nU+frj1xQi{rKn!!jSI;t6^lX|20bz z4A+8G6((FiiW#9$=2!6Pfk4m`^KC6r2uYjUA*zs=RKx%t?Pee) z(Gw9NHfTaNO!!hPXf09Q;q&0KgX|*BEe5LoQ=n!ihwq!J4M(i&{(m#s|BP+&_fKbk z$>Rk4;j``KVZp;mA#zg6lHbLRgZ|G)XJhY^!1B;QAeq=u5ESrJW*;5h{yjDwJRSPP zV8vxc*1JnZa~*2n+sLBk9u$pK#q5g}rKY!0(!e1|5&V;9wcGLL2o9J0_ zH_ntZjuWl4nJ7)!=7nk9Bxh}VXBFF(IMmiJle*e<3;bQ_ept^{jNuTNKfQ37WT_Tz zV#WBYc`i66G|yt@_d$<;;agQ}*k@ZC*S%ct-x{BLD>rk0p6gEhcv5*d9_YPLbnU29 z*~B0E(^M512$ez&`TG0l;N`LGq_b_$hI+!HwtdK|F>{|)IeTJYmV>zIKZm2=bpH`f zq^!Irwyob&N%`Y;J$u&ISbO(wx%|0v8QG4g)7Lb;^P%2ufu1MLv#Uouc6`yAzDdLT z+us`SRMM^F!Na-7j>OX!UyC+>1xq#$9_^ybA4Nr*|q@ADxr_-rUA^ zflkxd(UDG7RayD0Mw`6e>)}Gy!wwpnHt{a09wYfl zt7S1}o1c{Iv}93l2#vt&e|^lza*n~D@HLQa(Z1>{$4n{WtHgbO;h?LY!q26v(^K3ZYJV7} zTR`0qJ?OE(T$*y{eV1*%nzEAgvx9?}#NqcvdY@w)ygVc{cdy zBF6d47%GyB0<369~ z=c~N8lqt_TA79VuS|nEu=siR#UUsMc#{NR&*lUQmVjI^i>sP^7|h z!Bw-e{m%w1#p-xt!b5jaY;FtFyh&~=`G#7g6!nT;#z7ORHb-s#b+-={PyIokviOoQ z$1%HkIeEA7x^_%Qec@!{e<$M*c4-rGJP@VAF@;Wg5`*@~?6CP+k6dL;YRq}S2ZOB>m^CQe!ri$LFe zDlvTentGvjQ3s#ipXQEYvFhguy&@db^WkgU=K;HaFSAlL=lrx4X}^z2r5DL5{MK-3 zGpT>nu^>hOL&Z@bJaOfv!i+`Z6xan-cifdIc(Es#K0<9!n zIz7hUe}3RB{V|dBz;P#W_H3;nz8`;M41RA{v*R3f*`~tNcLqfF`rLe zX#5*ngAK*{M+B|mFH!AMIeV31rPdlUdgEX9XyWIn$=Fu=6Mr-i6AtDNg+Wz*{TM&i zYIa7{O(|V)ing8>Ve`CTpFwzYs_n!P zQO#tzE%;u725~Fy9}+uJK{ckm?>s>XE-eR;HGR)4!K0565Hf z5(>%$v!JLm5o6!=8a5UiM9*k_I?)W0CW#!Mv8;C*QLJZG(s))f%TefvLYG>X3MOAd zpWP41)vYqzsKNckgJ$qhGVmAQ>1b4pb1ZA&1vgFOPFfJBcG^vz^_MSX;pjTJU&Dz` zR<==c4(}uCWQ;wAoOs95-D=S9IF2tDBxxq_BJEB z^r@cu;onsWI$#_peaP#C)C7rM`81LSNhxk}?tnLusR&`ce5zUX;2w-r4wP zt3%h*ll)3dV-*gSdKXtSk7kAehRWO#>EN?XOm?`FlXFUi(S{xN^;}8kI9gB2 zTErHILf0=vukKlTAwN4D#beJ}wK-I1JtlQa=@V_*qACgsnxtm-j^&j0rrxdh%S7xV z?a2E!%FnX{J0rZhPjdqXNG0m#wpNpGa(XkhcDBWph(n`4{~XX!MHNgH70Xo1qBqc2 z##b0l>*F=jzz6^MaIxww{QPQg4>W8buc7*c&V2PfX5%GPxML2x)bme6lWKwlsQ1mM z6ci4TdE#U>-=ZIE>%M!51`o?68&}Y?MxCU7SPgb0OYqj05K3Y{uB|>gXTaDyF`^BB zLkRU_%&iS0-t~L_mjS^oGDD3l-*B1K!jh0vB(qvm409V!1Q~36A-{#>9%hTOC(BOK z4>TAJf=r#ff=LN`!qvmzrO@@4nyi+{o_gp|=XJ~^g?zRI&10uF52_IeD1!G?oRNPC zGC>huzj_CV5kQ~GjS+sD|AZKLM`U{!!PA|}6C((}o@`7jE!Vd)8prpY#XrJ6}7YL0~ z;t)(!-;d;HEE%>GXqTu_@e;cVBRTGg_()J}v*}x69UsemCbe4Vi;3R+VP2`?aQ)cp znCnYx?meqNB)2M=n;XPu5ybbykW7D(_oSMi(v=0O7iR-@*O0TK_SfdcrZ&-E+>F)= z(=}Sk|K6oR7(?rZ-~!@l`@BvhNXZl;QaR^*kH4M%z!~y_9H?<@oWH}+T`PK%=tLjt z?4kKS(MdRd`_8*FcCAdoaLtqD)Tz(yRQ+jjPpX&Fhb0&@{%5V0O|^1|E9r`<;jP-8 zZ<5J&^z^Z1vS{W3j?ES}bDfy=Y{D}2*4?f4ysG7w+%+79vq6Y>F?{4|zCJfMHeWviciBQj6)XgVhOR{*< zU#}*%!N^%Ym;G^_qivbL66<@@u(pGo!c#xrnG}2;? z`IflmH_@2N7P$UG{0Ws%u$*+uTY!&_hBp6!pQep%QPsgA5}K#^($)^c@>MNgLUZE3 zzV^{yxtj$n+0-gadpke{{_TAJHLxk z$bR5`i&RxYnR_v~@(4*)B{I4fl>5eZ-_7*Yj2?Cn!yUTmZBtXBhTRKecH!Qj@~pmt zMcAu6&jmd*)U3vRo0!PQfy%?if+sc5}a(Yo5sGrjvxlvnOGw52(I;+(3Z%3@o|9l+{T5w%2#Gssaym3ff{xq+(G)Qie5>u9yaldzn!2^(8nLmi>!+V2i z!p?m$`U>MXTVR^7b6)&ao0x{jfoXCZ>wR@hliLfgGU^VX98e3ZhW+p2OjrbkGUArl zueMDGpG$0IRKp&3aZ)ysho`t@xwz$#tPgk$Q0YjT?Uq-*Wjmr8S2k;Af2&R~! zUF9p&?D4HC*=t->>DwFOJ!Cm1u;B4?JG+;pE##l z?F-J4aO?n_v%P-9$FPD8m)eHw_lg=BNS>@zr`K5*7WI1v*jm_2vWoLlraUeL4=dPwX%+->WM@ZF#@XyafU4s zl9! zf})$r`Xxclu=`;ARh#hmQ@*-fzWTr|6f5rD6!uAc;+$%s=0L5q*<+@*E0U{a6664M-UGlMHl94dcz5BSLxu{rr!xp>ZQCMp3l!0puJDsB zsMZz?+mEUTWc#THFlGi9nO_)8$o1JGal_&cq8fEYn?I zv)4vDx5?qoBi+j~HSNj77_(Dt>DhD5GsgHr^PS1u^Y8r=BU`_dKPZ2o&|jz2+s?Ho zUVTBvZsaiS#yzWf&XPg>^D7qOLjJhA_+s-w4Ni`1`v#jdZtynE@gFI!amS8rnss?W z7gp)@ywz&g+l{vJ{^LjG!qUt;*Kifh(v^Y3AOaxVwv@{m8{e3Q>j?t*XQl-yc_g(0 zn%sqEtFJ$c*=~K3s+&5yL1>Hrh&Wg#D7_8rs3TwCc9-O zJz@Pdm?L*d(qQ1tM9@O42KY?T77NoD`{cNaO^YK)0s)>frb|rMRz^&LWaxDFEpv>? zT}VN61T-SeG;z{!bcm1x$|&bvmo&vO0ipT8R7?PQ z!F$#g?>(-a|C2BF|6HD>P6BEn`v$}Z3_>(^8?i?S4qap`1>fcu2y(x6ezkP4M$X)J z*o)*G2o3~i2Q27wY?8Tk9ZTk7)zF)F2ENs4`5mF%JT{(L;5#!etO_G`Ht+I=HCtC@ zKQc{+prAH`izwEO3oaLlvl`Ug$K{A*O2N{4%t@}=%%6|!C!>j0+LNL2-f44UTU{BU zFlD0X3~Jt3@Wt_Ek&H=1#|1A-u_C2b2MtQkUqjDCWeQP^Y%`#lB++IK_$6h^g>^WyBcfrO6EQ(7YfB+PyitB4mqzejNsB_mKK6=I) zQ`m`*FW)y`;jib)YGx}l?Uo56VZdPUiYr62@T8RiJ-{DD_Qy9m4n*E?7#T&_>Zpwk zwOP12S&NT0lL=1QnsY^|NR%T|r68Yk(Y!E0PXXtmpI{E3p^M+1ITzjXia9r1p(YTi z1hu5)xj1BF-Ux3OuPd76CFXJ4bw#f@8gTeZU%6#*l+a`7b+LPBC z_C7_Al`<3Pf_DCY|Nd|30u|GD6v)|(I`lBZ4dg7PP&YvDF#l|ZqkxWIfuqn+x#I(0 z#{{mkH0MsaAjsg7I>>f=xSuf7fGil`s;KGople8hT7b8X4duk0KEO)22d=VWz|4k@ zry3Jzr9jaDDy7Ut><~8xQMSonYP8tea5D2uR;i^%Z>H*&TEgVir3POQVOpXd02~AW zWZ%QUn#g6+xOW?yd(K1L*6@Et@yMI2_Y`mA$H`V1){@n&<$MI^!+yzhg$&{#rmvXEJov$& zVhkNc+G=7Tq(oB>p94#SRS9NGu7e0_NHDWK!=Q;vzG6k^k#laC1xHid1%9%_JhzFz zx$@%y5kZ2WD|bP-*`g`6Y>b;ZWBrDc5`ZYjhQz$Yd-#k$K*_zSD!d= zwfu13pU{$|=D*T~IytK$SZ8Wu86u>)U6+m@?*R0P&f582Nc1N(%3xZ+AyROPqXF{L z$SQ6mn>=-jjNyI~t7iy*ImT$o z*1+n6h z!Ly4zbSo3BKIvTJ_{dkd9L7YEzELo)sNvlSIHHL{!5HEHeB{f|{d=S~9ed#zuxzk@ z+)QG0WDUvt=RUsjok+!Xco>Sa5WnCD836bWaMLl6(MPJ0VNPJc;OFtYHd)+@9|mvy z=~|$=U?Obq+v_1e2)K`Ir3B>0rX$X{rf*1^j^mItN1|qyOs?5e-D`IfW4c z2o-CV3OMHCA6}QPfJG!c>lq?simmHwdUNxTDK?g4v7_`9=r8Qd&e0Iqdb~zdhUzV+ z%zcem_My>{KR&$^wYk-J7>8GQyCdwy;~3B8)ynMG=BNa7aO6r@*ajQm&sUHNN4ViU{yrL6dCM7 z5^jFTc`nSw@Ywen&_5M1K1F^CLC$c z%9n;d*ZCW$0qpn6;kW+rI#Ksi4Pb*+Vj&9jAGS$l54@BbP_g@`GCiPTGfp;r0~Py6 z{L>klK*b)8ja0!REd)1IvBe^I5h}>Gs8PwV_>=QxV^Pjv1MQna;lmlIahc2_5?D8tUCkAKh|As$ad@*_-ma5GFE1flDgMWxzSURMHS z8rZj-*ax03m3Wpiz~{=(uTfU$AgF;-OZ=^CPLh^qA6{R)di(l?^5**T^}CPw$L0HX z!w=UlKMk+n{eXm;H%9hISZdB|5?bVf2>P5jP(*2*Kp*k;XA{+X+AXGyM7)vy=8g0K z6@$e&FU`c3G1v47?lpN!dsx1`R#Etspr}X>h$62nS4Txj*BV_r=>h)1h%#43)Hnq)lY+MCBdN*y08}ztl+Y$O9Hq6u zs&{@d8X}Zbynz6=NQA$jqz>vtDLsV11&RPBqJV>^ys2Q0Y$&qi4duNkhV-8omK+3? zA&7?}pHGRVhEg8i)3;MI0DcCxKv9)HVG#5*g#S8{uP%%5>4Tx?uRkNdXh{|8SCl`a zcnfN$DGQD27dSRz&p=pb9#yv`a0QB_5Eqv+qkR*yUQI(hfZBTweiSAUc$F#20!J>zO7FrL3dhkTA+j z;=aUQivkX#Tzg#Fi)2eAZ8I@lS|)Z!*+N>j0@)I|+o+x^9684}86z(zTljWJb+RQg zwi)#CuTOB<@}-3GbSV13cFpk(MSJH!hf~@VWc&ZbjzKq;e2hp_G{wPT#W|eW$XtT! z;%rsKhFoDs9xyIijNE)~xy7KQZ)H%0^0=8$YM>UTTd6^PY`Jtsa0W|8%MzsQe3TL| z)d{wc0hsu~l*Af0luIhtq5Xfnz9ZN~tGqOTh;ZmFGM-3#nke|erkuCWUtn8~F`nVI zyta-m3b%Q3RUFx#8L&yhJ&ExLEpIBzaA$Cbss(D4ALqPcPU3(kLu^WN5==;SoRsH| zl%x;hMP@Y`RHK@Bja+6e#GxW|BoI6ka z8kmy4IT{Xm+cml}q&}(|avz!EPh>nYvIs?CH_8xi27xFEoH_Dx5=p7w$}|R=-)7Ut z`?dO~vx4K4#HCuF$liW=plyQaHDn462vBY> z3aM!~czTxJS5Fz5i1NETYoajc3r)1a=%DsVZ)GTgC|mCXByF70Rd-M6QbWhe7?t`f z<}fO?1k7htYRh+iAzO}cHO=>8`Qc3%3)*MHn_qzUM8z}qm->ANHaC3KUvFo2qo#Gi zxHe!n>LDl0B!;qFh|NOW_eJCiHgY^egEeeIh*~R@4DQ05Q4Y>sD6W_}V#wabp0gL& zmJxmI<3{hBAT?HE`}!rXsPlJxM74>n*w82rGz_{pP>wIimIn_nmno-KZWwyhHA%Cs zWqfvOP`73h(;k*@s;PHdf}#RbO)c2+mJi9~HM%nFYFUmzav6`zO8u0wk<`lT{0h~h z0EF;KD8d?3&0(H%7wk?ww~(Xxuh^pn_HCXIO!SRGH7j9L-p7TASc^AF&Jr#aBFjx4 z6IQe_95X%Mxgbbm^J{s%>>c{|_<>~VNAoP&W&x4srDb?1{tQU+>CA~}`IEc*^h4e7 zf>tzM@cqcJ&lC2_BA?{3Q|0oqrKpXT^2tK5+Ho~AHj||nX-I8y0ukkHq(qA$MCO;M ze&+ePa1!`zXdsIkOq_a#XR@=}C&yhl|NB4I6y7oL`lkc_n0;vEOy(b#9 zokHva)6v|^u$sRy$8KUA&4%(1xc>&*!qHF(uQe9r>V7m(=)7VU{}%uaw#m$uH{>1s zfjP(uV3%1V*w7c>LkLn@YQxngv{eNiiC~i`Ckf}fL2YKx?W+Nzn!j5*<{78<+s?(e z?JN90g=QR$QjMQPH~s_4@%P_p^Tpp&M)Rz7^rhAQ;*w>+#>E>#S>JYBNM%^ecIky* z*irwOsa@!|7VDzlq&{gMwN7+>)SgU^#_H$`n*V9NvDWFHv`)IM?(vB>)=t!}-X80$ z+db}nY2i<=b8^z_9CcvI`)a?}?exBUvTiJUWqld`e6<+;@Q?1Oqo1(5pRPuKeA!~3 z)YizYv zw!xpr&+DJ?`)>04Z#%E>e^Bw|3m>`5hd!NIcR#(-Fdc7S{?c8s+t16-Z(hFq$^Ewd za`kSgExW%zdH3_H8*B83cj_-IJb~X#JD<>ROFzR0sRF*LV&f*siyyv8kreHmcg^y1 zMH7c1|HHlC7s}k$MKX(0S32dQXd@Qw>kiXFgL8pkqD+i>rFrN74*&rF{{sL}O9KQH00saE0000X0Meb- zG&U{(0Eevs015yA0CRMCY-MvUcx`O#eci6xNRsCL0{aev8V0&AC`&q$&JQdPs_Z&l zjXLEr+U_Y}7K;KUQ4-sfD3FwoPhAaWUScm6SYR>0%p1(j0(;SKGA}T%Fp-fN$xJf& zPw7Zy+30GEnarQ~A|fLqBa^TG?#ssOe0GA+^|#aRpx5tqobB9SxZBmV`E5Z~NP&3*#?0fH~Gy-(Sqi zzPqp^duE4@_V#?*T}RRG?&ZtfKJa>euzI|G zupi66Yd->{>g!9t?8{$5&szG{+~4c~sF|nDcIgMDp=Nc}A*_PM!jr^$e0=OZULm=L z{r=TUpc+uu`s_N7zax5W>}YLzVQ_nU^YTY1#Q*&GAnQAkU3QuqsH=`{yWh;5pzPah ztSAF&6I@8jHX%ex5rbXegupW>9%Wlm-%-aB&I5N>TBdky?fs1lSd|m05b9>|3(}}` zJ4~r)gZNxpti#W%j3I!?dZ5b6O$95fLx`L&rK!m3s_%Yb5)hgg7&w0Tk{1*2epyEw zqjUhX-@e3BS=Dp5pG?j2s;soz5$vTX`%(8b>G7oxI(%u*9c$stz3}xb&dc&KECLJ) zrpTw=Zvxl$U|smUx)T)u@2B`VR#i%@m9upM7xZHI=!PL%QCMSGW9LS55b4i0vJ;$uxYJMm zEt$~TNtiU#@3F7m_9TQ}T!_LE_t z$@1*M7K>kjw!*HmhM-}Uq*JM`UkbG^aEKMWc#e`H_5H$G+Ivq}^CU&65T{*S31P+H zvW35_T>ut+5V@dlm;T+x4p#2g@|-1zTi*pq=d0(;4?yrOhAS*+bKmpqT?l+mvwIBO z2!3LPY1a#^XhyHvp1T6agf+=9eaSo5hDjsR9-77u=76`~Y!g%957n9QKK8Hx`Mb#7 z*vyn+FItc8f|;LDuy>jdCh#8v-s9XWJ8v*({yfxq7_81a1QJqqk?xU&PWX9@R}_q1DEKCCRl z#-rfxSbFnD5GdG?^U?&0awpYdJajBr!K6>!Ta3 ztu5Mue5e`p#&Nm}{}If-A&%M)c55I7{hS4k{mGg+U>bsH#oI!=k^3JO7;g?#mY{NB zns&F~k7Ii~d%@jxlsL{B;o62SsShB|K6}Sr;I3EJI+N`NPh!krHdYE>X zwioh=@LssUL(CzN<1^|9-eQt9Bo;y!&HO0x!9nf!23I#XOeFzMNC^_CLBIb3pO#`- zP-qb9@ORe2WnmFUjDBx)JD5Pzq==M;magY@7T~Dgv3~*Gea~GeTxw!5Y6i)nC|EvW z)Z@At9xqPpxdjmy8{~nE^h7E1;yvffw41VlfiT$kqtG;4@Kw;vk6YkH)I)X!*$Gvl zws8)OEmKWnNlweW+|)4A3AGE4MM%NG*`Q;w1;wfNi7z1^L~Bq}tF;w9?Ep;vGAA|G z0Y+xkB%kskY&vi}*IDZCuvO#Hg&5Z(giOGtlFAR33}ihgieM>}+;13F2>K8D<9x}x z^Y~kzz!G@d-C>TBk39JX&X>YG!Rt^{FIV?0$03PTczonO{4o#8O zt58qG`4ilcwkWJ(u*RZxZTRVbLmN6J`Y+{65yuWvB zrq>754`>`_ty)@XM;3GIaN3nBh2Db)u)gvDt$6vJCVy-d%PA(iN=O2jcb}OVH<0>H z_E@w|dXM%K_%^^uNy{WI5qcX`tfI7~35~SQ)`^5^p>6{waY6J!#?v)hR59GE0w-PNbCN7RHYZ(OI7zkBz`_s)ozzK9b;u|md0BjHBIDQjtRRbz%?j5SR*-&N9xIIc z>~AZqfZ0E6uh#5N$l_zO!p(1k6-am$#AIxSMS$|$0ArzK3;u2k>%wimGLXf`=78JZ z1_#9E+JV-EQ)DeY{G_WEy)4aDMJ_;c{qB)L&sSR|^l#Y_#Ihi13jc-$at$ z@=ewEw83-_fnl>$iJBc*wWHQ0Vz3|>GfLS1!(K+HZ`bnh;Lkt*@)M6-KR|^K%pdqg z27h#lo2#nLW5kalgqRiA;eAsikm8p64QyAzcvv7FsLO})?%^I5BTjzU(-MVh01@Be zohY$A>;gBOXQ)bg<+oGO5b3EFV?e{SB6VpVrC*tB3q_ASt-JxA(d>J)DCWOc&HuRZck9&a7+eyW6zI6Rx%2Nt9EJK<<#z zi|`;L3y6A`uO!lVk`WcoxZIz|^&|FK8|5AR?SI2@yKue^++{TQhxuA2Z0U1WtHI$4 zwIWTPjVfo}#&`@-Avq&HPYly>nrGxyioKgu=27DPcvCi26POLVq5R9NBqY&OR0<*$GHm$kQ#PloC!{O~*{>3>L3pAZ2Z;yxVU!aJz{UWRk^Hqh-3pn}jDr7my6R&xNgY ziTpvWs6HjK4z7{F7)b#FAR=1&88fz8Btu=jXFW9p0}=;6SvCb8{OtGOW-Lrj;C!4s z7%ESRtLvUI5J2mmu~4pi!%5TAM5rIL*FY@(4K96Eb@E97U3&3jM^l}ERxW)F(93EF zcS-4$C;QokkB|m-!vR0nuP66SChGZoI>Rq-J)sAp8GaIc4&m~6j7)ByeicBht2x3^Y6fwWaNfySkCM*9B{%-lJ<9bfE zB+Dw#Ce1Lx3iOCkKpct4_(NdH1OE5EuP}nn?0VU8n4LzdFi#FAUf3Az4*})=Z~v!& zjqj<-Z;g%L*l?MVFLkBP$BDukj7%cK5?zrUDf^dSH9$;j(r=38B}_75c8NAKbGG9f zT@q=xH^Z#NBwj+Jks=f;1JeLybv8MDw-XgkrNy4hs`6gE!)DsCD^%-Bd-{IeZBx_j z0n%~bQ_?yuW;)-nDsi?t)v3WgL}C;91sh~~bqfDb-ZfjHsmbOb*LDrRwINO1-+ol~ zqjma;3LUjZ+tf4oHF;b33O{kB`7wP5B`b*8mMTc;90yCq4%AEd}J|K#IOZ{!6tI_E;kA@81{AsO{S z%+ch+^V2(uB9PueuRk7BR(N8SxEhRy%z22LL$jS72fDo(Wvw9MEgGQIF3AUij@+5h z`~f(01l|*0C8ym5+)##hpQ4>2%9yD??e<8asvgAPW}s*LDI;j$L{wVCfMT_EA~23T zkdkI8SyV#{66ZEELCSE>4RU}uz)jFRt$w#GT*-sGyUpMz-3IZc>Ao^DAq zfh;;!ZHJL2GOa=!ZMoRBIe zZeYrhUV-%?nbue-y$>`Q?Hcys&;30$%sR2+OX|294)(q zzoe4SInfBaBbQx~yN%rK-rt7`P*|V%27i#k!=?I9aJukI#$t_SC$L;g-KsCUWVOS3 zoVDtTBAUKr+L(_`mV&I#U{D-4PI@#wbyHR(cLG;PyL8%pMi&egOL>}1mkwrs$s&>r zNdw|ygLvo%tQ&5jNI)~qtYPnJG{mF1)y%A$$@m%d;CjA(2j^*7I``TTr-GuMsWes-~hf|GWxn+#BIOaJ>FC(@#Y!qEe3kjN=o^T~w{C znayvmL2E}kk~#--OGp;B&$xmMnTcoZckopxy8oASl3b%zgCt%X<%()Hk-&wcXa-u2 zZhWW2bDBsPYgT!Log5J<2F5a(VbC~AjfhH1$b_~mY#;4*K%EQ*wANifjhz`81~7pt z3)=_vz#=>v-;h0gK|4lUnx!VRW#QSOeLcC#I&A+nD{OgZg9&X}cy?&Rhd{EfGWnX( zmNz|^(3XW~hBkbsb8?$?QPkIrw!9z0gtja^JG6)JM;PUobvs_S<=qk{v}NJhp?!6I z@w3wV3*wtJ6l*a-o~Y6y@aX9ke|AQM3n?{#Z`DGaguACGx;3@}D(#Oeo-lte4wsm6 zyo?^Q>OD6J2D22^Eo88MRCdjD+^EJgWFgg#*(tdjNo8CsK?6T9DMk}#Td?~^+lsIO zh9?pqV=1nTBMNe(v}(ssjB0r+4#SEumMEd56Yz(o>_{a3>?|GFV4gc>jYriwsd}XL z7<1CQhRwK2d)10o;hA~bRWw|&$OvW!Tze(Y|;=QNRRC@2h*C5yMDJ>_+ z)-FmVqk?IZLLg(bn}5@1e--I1K>P>C-99)@5ZL=ocD^91)uC$7B@^ZG3H-l0pQ4%P z&ogo?-WzHV>&ifN4*w=jsLEFgV%xnT8CS|~4ZH9jKE(;M2Z1UkE`J+wO>rc(pS>#dR2(3^^-*nT23n2CG=A1%b?(e+Bsf71uJ{&hWJ@oVj-Pe zrW#cURg?RK6Q{AB{61`H_7nD5<~3fN#)YOG=W6-sNzv*;E;#hzNm20T`)1$uP)VMx z=G0oxrRBtWjPi_0I#~qI)C*0a0p=%Ms(fiQ54+N;TSeeo%RFeE zH^Y!!uL>9jL!oG)7i)I$XPld`;g3#azlEFynN6eX8&=%W%BxJ;XxEfB8O3*8GMN#k zEoFJyRb*H`B_YPLCRF-n1_z74=}|h-=|mMeN{uR%YGBw1vB^IP-xd*-rMKm?hwL=@ zTQ>mj1a^LPxw&mlWqBpiPLZT;^1U#!B^8NL-Au>4KZJ(Z!R`VQA=ZLqD{YGM>^E4|v(Lepp!_+hBtN3H98 ztkc0t9ko`KH5S@{qdY~^7FJjBwb@N14ML=D&LMFuHpWgRi<7Mi55S4YyMUn}sy6Mu z@%QX9v(7u`ky?#?aGAEL)za6v;sCSi+Us^h^W@)q@nyE}^ADG0RwEWVSXjEx!qS2Q z2*x=bGW*LG&Ib72XJ_#v@EMq983)eddYxp&gA*9z{>&Ml+4E1JBY?gT3-b9zi=+(khqfOkX82Lr%`%ff ztwBiF&{Fc1#72S^v(4Ww(CPHNO6dpAMs~miK0EBHReQF$Ys-YI%3~k)v%flXxoK)< zvqYsToMvF<)FDW<4haS7>Rr4YMP#bv4Jr;Ze=pvpl8GU;EvJ}$*3QN*!)B~r9X^YD zB7V-Ik}_d!&-!50lhK|QzMoy1b^ipx!)@q%x7n>>mm=fvoT$`E)*|L*3`T~5!H%nx zDnR5#@*n61=J752TYe2;OT%?fX7cNT%?dk8DG^031kzHMPZCRmNc+;xPjT*377hJc zNPd4ZaWcW)mBv8KpWamR4=CB`*wlQc*g;#ns5*r+UO? z3}|}Rf_fv1e$pR*H-3ZsXtMVQZ|~o}Ew7{g?0j~^%v%zZr8G6ElIkd_JoQssS@8Je z&(4e}uA{|^JHLktf1n!a$p{a?09Li|Ctd0opO#3f3iTv~rZ4hM{FHH#+VM}+pdFx8 zJ-J?@d~s#1yo*5!AztP}UAhG2j<$Qu^w2MF-hNA1>S!lR4~{e(g2Gc!oPr9V`tn;b zGdn;3qcpAGe%CC6hN$^wZ3p@E?xyz~)6Px6N2;53441kbY zff!}LS_nn>Qj0(Q{PQnA?IXrX?8ea#?5ez9GD1)0s;^(g&3n#g$Da_3@_gQ~OMN z*12W&JjT;Fe~2{YAy5Gyd3i%sd^j~pHzGh_ybk4}Z5%g$sRC|zA}~2sI#TdVpZm@_ zrO2Ki4L5mWza8A-FTu2f8)hV*7;cm$&4y(uSADSON5gGYS09??E&ftXJGh~xabmb- zodIXhkA|C!w6r5{23xMkfwC?XbOuf)i=?X7R}_JekCo3xA@-ez%PxMkh2 zp-7;=?SM7=6M)&8kVX5mIdww)MDQ_fb2e+G6al?C|P6{>iO;zma z(GZij3bcdRZM%r|P7pIbCWvzBk_H!Mwt$=B*kMFL_2uwEktO7c!;r?dMO7 z#f>kPw~HH}A#WEqzOuYs-1uU7ySVWg@^*3KE6dx(jW3e76Lbl|@ncC`35T!+cd)dF zc5&k?N*Z_94X8bX8~@P>WjdGcw_{0NM?KsxmoDT>%Cw}+5RbM^5BupG8@`wq-wtRD z_Ez4^<@XdNIr^D*bLHhpy6pD(tx89W!fE^P@Wst0xY-l}Lb&0KB>O(%({?`XM!`Nl zrB@zQal;fMXGpF%NnEqsL>%nVVAcHlhOoLdBC9!Q1aNm|mIyk#Ea3ECwvm>W%<~KyHbxnGH>togj4~}ctXn}%; zpw>{NNQ5)eqQe8Pfa(2y+=Ra~?)9@X5D)i1jUWF0L8?dXECglE<6^Dk%kwtn)g#lc zcFpfTbRboJ3&#;b3&V{k;y4(3i?OSOZBPeA!;}8(X%0{NWv4kj>3q~1-iN0R9Dr9+ zh$=xR4e00ST-tf{I{z8IDZYUJRru65WX33BC5@G5>R&Fo_4;pyyj&XE?Hsi|Mw`-F z;{i-RN4f2c%tAd1inTgwwXBfnY!6r0MLaZ#hf?qe5{>{n7xtwNI_OfY!C$uKpk=4s z|M2oAF zzeiL(QO8RBJtEYZ;d?t8WgR(e8DGVEKpHhy z&|pgz08BL!0RLMZfQeFP1u*PG-}EzgtJ)Rd_5lWay#QdUp#%KS|EoH{F{RE7;8FI6 zY+IIK-Ty%{H5X#=i3%{L8al@R^sjX=CSsi##*^_dD^v0uFb2P~0As3=z_`XrJm?Xz z&J5!l_;Vaft9?ZczI_3}R3ia!jg@%NBTAhWz{B2vr?MR06E2Of;wht(t2)Q{Ksyfh zz@jNDXXC44?r5}tZ;freevfEzRw^GZ@oXMFX-h=qu8#`g zaZ}C&G0qG_^7~If4CUro8yL2)XNgj01#s;5p8&vegR%{PYbe^77-xnd`SmA&q1@zE zF+65Q8qwm+ASAc_1R#|AXEZFsawLjk_|=$@lDML9b9>R1#^~`d2(cax>;QM`68X>wQR(x% z=}0uJ6F^mqsT>H^)^Fau$ZA@Wxj^CbX;%xg90=96@8u<-xX3EIt=@E#mKJz95UMq9 z?Tr&Y4N>iJd^-13^e>#2%F0E-f}^ddTAbxTc-FYhx9A+;5!Qdo)C~sLO#6 zt#Qw9!TCVt6!xjeXwH!&9PQB%)q*ewLbS#Wz;u2xE4p@bdNMlfW!-X*gFPCeTG-`4 zh~8Gu3d=b(7%#A=BA(`CY&OoOFe=`v2xssh1^!n{1c}eL+%%89h-4MfL8ZfjvAvoe z;|FHSL12W>fxKOQQbd$xMOb)>l4jNCM_2?Ea5#E?(?9?J>g<^NsUe<16i=LcBhQ_P zl4aDDJA2F_Vspwp-%~oPDM=k{-(=Nm;jQvnE1Kg@QL(ne{NiGh?3|U;TW0zvawUX@ zPeWL1ME3<5kP8iN*-1+9nO}>fAx;um=YqNOyY>Ms6hkz#oa$B9{B&F^Ykh=0gyaqW zT6}~=u0(Q?5xBNhX>7!uhd5Fc;Mq~tq9jdGt)WSY5ND)Hg}?vo&}rcig06VO&nS;I z6lp=&;{?}0a_gTRIW6qb5V_Vh>G`dXXMHV_Q5mHdJa4+D}k?dpxQF-X!rsn>rqkmM3u zuk)jUB;)1v#+d_B93o4rJh%dGAZ1t&obsY9zp!%LRH#%Oj2<_wcLj%HR-T8a*EC|r z6%?c2AtR>-TwyIj)NlZ)j6;Si)zEPDYed7(&*W?tk|~L)s)X1=9ZR$t$l=tlAh00# z1;A1b4cPyzcN@dm32amMz9hK1=57gEu!{wRgGyV zx%nlbJ%}a-=cfQzs*wP;h90*Tvvh7T`)XG+b-w;;Zu$*UVc6St3JQ z;(8!W432mKuv9|>ww5Lyou9ytjw7&Dbg|+Op{7?|Abg-jd0AXTh7Hpp4|d)H@mJOo zY{ZmQ1gTihCEg$l^Y06T-A{LY&Zxwd!S;3}Co z;p;q%?`C0;wm_AU%oac`+IgeBW7~6A+iBO?E@<7@*>lI5IUv^#Tp8cH$_Gc}CeGKeUJAlRk016cjZc zcd&dW9H{j3>J3znEh*rY$vVRUNWY}s0F-ESo!+H&U9b1!;Uw+FdIN2aleBQ^4WJ=T za+R*v`|)s+D^IM%GDI3UvBalU!qz}QKHN;>_3%zMypmD*BaYwUtQF-B&MnwY7tpVEz3cc zs%R2hYoF~aJX}^1U0rv_>RR1g;qHb)*8zAD-6<>g!Mq`n6k@qu%#**wzbspB>^pRoiOPmL%cxy=6Fj| zOX+1f$WoOAvNe?PR~XYRDYxybW6Cef0hX$0z}8U5UtLVMB&Y{c#*|=|gDh3ikgcVR zFF9yV&|Dp-gTko3w|?Y=aN>5mbXWVpj$D7sO=DJI%{@DW>$sP`AFUO6nuvpfMHc}AIk@c>=vU(_0)oC6Kg-$$OibvXHw5&WNc z;RAdS@dLYO?iY5?HqMP+Q+%alP>SmjMqEq~;S?5ejCT+B8RVxpw3<{R)7b?!T9#4n zHFCJyoHQl~F3a97tPmU9_zU0&&z?D+g;`CAvtcZWDq_y~-qQCx|It}kvnOZ@NEX?% zZU=IuHg>Rbx0dHDfrStU)5qlL z6T>Sjp_@HFI9_tQryaanzb7APAY=d-9$5S{2+%XjSJowsrSk9jT2^1atPgA4ZJ)b-U7w(Q;g~1|*xfF`BARwB*g`l4UUFNt z9r>zpcYQ8i_+j%Cldr6gt+VF`moK>s-40&YH7-_=B4h}VpW+9Zvc5CGo*x`9xo_VN zUN!EW&ylbAf=kspe$Edqna_T(rw2z$CN8vt)NQMh1>aYdVs|oF@iC=VEN%eL<3vm$aC&ca{C#uR7C@}#!l-c3(>q6mt0|5LKc)# z5wcW8L$=mV>m>`Zjh)s!SMZ>n1I=*BfnnhOkr1I2l1rv%=40DjBDhXt3DC0{OVwT*tuZ}6j zFb7zwq5)e&9bd8#%>sKMWlSlCIml8K4cS`C_>zT~C9+l2F%QCHtO8Mc{R%clAbamF zu|J{(<1r5{T@$msG=qA;0xqIKwk*7UF?jLnrTTzMWq0XDhK5FZFNW0{y2@y%_u{I0 zW22nLdM`%R8ypuj*n2Uq-sq%6qrDfC>J49)Y`FL0x_aX`6&mloxT)U3ZN(0HFK&~a z5Eo0v<(Zn2-4oA~^22Vw5pp1Frdi)4KYwU0K-HT_iB9zTRTCq(&Plk*Lu| ziu-$&K}qp=^(InWoNS^YkFrp9JswRCq_~wVC11Uz6sy9T!8rP%5`((0SpIMg z5vZ;oQ@mfji4?=vP>(4VuhB+|p=-2}V%;RJ#h|44vw9OL223{5kh@s6bMZt>rbKce z#jT{&boC}uJX*bp6pvPKBE_QBn@DkJ^(M}pLD6NrQ<5PxGxz-iyOAeVN6j^Wv@(2K zBn8~`h7(G>#pi3sU9BNedNAlsZh5i*J5hDFgX3k9<-;c{xBTcE93u0BD6ri~JvaqoE6c>0r5rxI2R&HuC5@pf&Er;uwdQNy%yjz|Z?es=RJ2TmU7Jz(Jt zdRUq}ueFGj8<#sRT3e4XDu}_swJ9~qHoXVonD(TG@VI7tj$zv=yM{;pin3m5^q`#E zuM-S8y~)w8ZEx;O38V2%n~&OZJxitC?B)$z)MnJd#RS;pac;-_Wec2g@b4s9;upvL zWi}BfTzlJJsB}m#lI%{+$Vk4h&EJsBK!#f{*@UVbnbYVMiO961)gJ5reBZo9Z5lT| zb@d{W_wVb#@sztXjzn&1b@s7M^C%l=itRFGf;eAGpwca+<6qv;RvnPSLdd~~iO&X) ziYOFlUv+hz+=x~IrQw%WtUwH!&-3;r zI-{wy{565{)?9s9OoHRJq4!_Wl|t86eA~*!@GMcWM70wF$is>brLxG566sXj%6h*( zApeZ&hpaAZsHQ;E6*~%@6WLD!qb{H!1a!eh;@gp=bPS@T{IQ7E+}X6TMwvkkyUv=X z=Y#d5sNUU{o)u0@*$%T$;~8uW&G(Np)#)!J1Zgg?lGCI`h4Qr5cox%yctK|0`Q+PU zdNm%djx)>Z9opzYFVP@Y$Ps zMpi0s*-$AJcXMME-ZE-?s4Jp$1`$j+1JG zcxvb29#^Z7V?01I^THmaP|%UH0q!TwMcKmuf{`F+wNBReQ?`Lyztd?& zIjctIg(Z!(`9)e4#4O*s>OswX79$V7Ub=+sguusNElN{SmLoJF^IRz%=Fm{UV8oLr z1jz2&LxA#o%^U}D;DDmrBH+sM1D~m~-;1IzI4nrKeJCnSphY_n$4%oJv;ro+@s7MPTG)O0ZRChIRAWz#0S=9_un04^3UCa#zOgeGEIlH*YN6 z^p|7!aTr5%c2sPCLF6HUx%k-XPa>*Vz>qCHVzF{6^_0cDWK^5m8oJp z+1D7q_*>8>#@pxvQuPE?4^R=*$XrMh62ZuLpHB`K6{I-Q!S9&p2@|b+NN9|?#T_LS zDOkQLi#hbcSalVoKu2EVFx;Q-lEkqGjTY9ZPlhU=(z3V#Q}{4)@~R4Z@Opxjzio?P zqxgFIk<^ti;ci-M)IW0|0wj6$@Tx&8*YF$+A=>$(c+URYT$vmAP^rF>!?3cpM`NJV zA=_KAZYc&zzvsMtL$v7dL|4>?W4~Q0EIc#8>^jRiDno5VLF>CyM%q;gs_;`*dKG_@ zX7;j*%Dav2xR!|2XcOKbV2mp8o_Tl64KU92V zo?kQpR~)8cG86##4e}%SUvJO5cOcf!-^a*5&+U|!ATy{zJE{_I~{R7^ks diff --git a/docs/en/Em002-2.3 Checklist OSS Release and Publication.odt b/docs/en/Em002-2.3 Checklist OSS Release and Publication.odt deleted file mode 100644 index 223a534ad908af47cb1583e177d1ad63cf3aafb9..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 50777 zcmZU)18`k!_%FI+tFg_-wynl&Y}>ZkIBjg(R+BVoY};vUob~*5(w9?;B{tR~<&2v}8B1)#$Xkn@9GX zEaq-b+{owejayY7PZ#)5Ls~hUtTqnE)V#*Af4kT0Pk||ZNx`*Q9`5^syaq zvy!~GQ{DJ5o?5JQFg!Z1;kwmYqL|}^%XA+>E4&uQgvaLmw_oGKIVR0Z?Hk_0?!E z-w-UdLlU%CXyAUHp)M#@?M6~j&+)Sgu*+sH&vaJd zcqL`rcx%tw14!gmkJnDgxug^@Cx#@#>hhQ*9bLX(Uto0din9ky=LZ*D-Wy#^|z#x*Vz$P0x{n{NNpuzqffKjvrW zKgvRJM&1NpIy(N!(+sUN)f0U^qVl;hPPL0CzR<-ak6oa@`k9B71CiF9Kl+`km5Y;X z@UP6$FDqiBzL0VDu8ecKX}R8bjV+-84Ob!H?*ISKNAYogcn1;$!bAH%?;Nq2&Xd8PAcDUu&XXQLB$I=dSUTz5N~JHh4>z_) zUs{a0JUD1K;HPl=*!9S~G6FvP@OEzsjDesol-8V3 zWT7}7tIWrH{L*L$rDAssFLzzHMpkrtMYS7uBXpWvZaZ6Uw0J)}LqlM8URO_UugQP7 zRI@txS(P-VDti>$b-`^;9`zTqxzoC!+kPcnx4)g;ltC%xjmYzkS=7ju*g}!a-Y7~t4qDtNR#H7llakTr=Ebt@?h({M1+ky93q&4DllLWG;m`gR`?FWSE64{*ExDl1ftEB#wCd zbCjP^K1isi!c-rRP_cV0i|EGjQZP$wMs@peF*My!m8JRNSHJ<gcd#NJGVw zQG;<72%^ZMl7ckJJQ=lfayPTnD=y9#bES=wsDI}3|3yFkBc8_|&1}3aC0`%)Lo{bI zS6k0(8Jn@nVSx6-ziZPU%%&F!e#-~t?sII>{Lus7e+&M}rQuX> zm5sx?FQu+E$lWMdHA>xeB$NjJOFf&)5FH2A%SYGL2lnHa$cx1Ve9#AyM=x9OlzBr_ zdt)i+dxj6OVkddU%f~Yc3jNP%el!dTjNg&8%hk@bl(Ge)Uu@Zr3OpsFcYpU0s;D8p zg)$qU!k4Cou)+?9?aE#+N`opl#`V-s) z@(R_n=hyWPZ^AZPP()0n`fFvsBqNf_eap=cW_Xy)A9B=Ol_LE0G0>jtN~g-i}8L9V+2zdv-k{WPiVg$BcV4*6}Sdq;Y-88RGWSltCm&s-^dVR1)d9yo=FjL%DXC&4xZ-dZI zZ+qQ4p2_&tXR*`6;d=jH?=J#EUq8R9D*9XjpXj;qaoM&%e}>B}CV!44uXMP@Bqfm& zpb!fVF*ze%x^}D@So2*=U&E-`Z z6QH0(u{ahS`zrIEKVj_|?q^%7!(RQ7W8=b-eYvvoxx19$B(fN`2>D5J*acvb&@vgH zrUJ0v?zbF;K6*b(uY^7sXh%NYU&XOuDwH(2($kp?lBYDUU+!&Y?oCkH6kyiFCMAAp ze6L1nY2m!SzOJcZba&_6-#b1Qjt4&QHWwEcH60y%d`1S&oBzvQdBCUt%#2tlYV_LJ zH6bc(!a-*c&xZx6IUbVgM19N45m%gQln~0ouNd%etIe2t&DY!gelx|8T$|QZw|XdZOJdEduu}+j-I(jMzp|XAe$^Z;CB@-! z4n0;0Y!wY4h?cim+ExpT%Pf{({%v;8EzUNzw2Z4;^4NZ%rk3*X;6g{= zySfs@z;Uc=Mb|Sfsf@GAla_OAWMx-i|EiWM6jhXs2PrccI3jYie@KZ$u4T+JI0`xR zV-+$zlP5iCbt-kwWZq zT=w6w^%k~eUWogb*pTo+y@b4wlYb^md67)AYQR}$#2nooFZHIa2&PXqIz38DN?etX z*}+}U7IDcX;A1Q2O27SH04g(a%454#J%P(ce^WAEj^qieY{_;Fb}Q#)*^%o z54PfHemG`e$YIi!Lwn;*J)E<8L#E-_-F)(A=C5B!Yd%1wnVXkf4S_(K*K(}D=bsqO zfRZYW?|+&c&mtBO&)8z);>zZ9qa)bpa1Wv;5YFbTemq}6is!Z)p6&P#az^qFGN2TVT$5=8Yw*;sSuD%|8igR!|n?kzhK5)eFU@#*3h_wd_TElmugIifvf?k^ zfsLMD)Obu;bch#?7GYAk8=Voc1hn#1uP-kc*x1T{6cmYwakf!_X?hDh<7qWHIXNsw ztw7SF3>K4VLRkRL*`>#P?l1|v`ggEYRq&D9zhydCcE|K!h% zxTXy+jt=tx{Kx*~QZ2E+ zoo#3k@43j^>^ekhzWS_>MAO7F~KA(DSNF}{#Lzdr<~$t&hp z4Gav7zNGB06QVO>Y|yb6*RR|C5Ni0Qcxa@i5Yr0_U_S21pY8U|I<@{|*i-1w3+*TopJX9(y7IDe1-)J}xd8bVP_j zf6$tQW?_L7B$BES7gu^4H!Uq(vh^7)f2qdd@$~ei>*>V;5f;sY)JRq4RBn1dTGjS3 zC_pHqUSMzlmEna&81*)t$&|{*20>2(c=%UxCU0j;wOd_Y=*Zx_vDbT0j3W%2n*&u? zaCj$VblmpqZ6fh~eSw;_`u#?>rlDKax~*hK*47L=_O9&ld1k(ty^7N~UD1rlQt zOC?mLk?plS9p~7_4Pr;o*u{UOWJtRYzdhg1NF`y)&k3vXH>7lTtpX?mD_+pg`{?M1 zkB_fk!1F54L<&j}xrG-c)D?IS9vG$N__Tq&!p zo9O*(Cgesq%DpibnC!6DaxrqR^X+)qR&s9_=$-{~a86G35)u-r&D3xcm{SD)oTC6w z(?FR~g~e3yPfg8-eRxd&MogLRSeC*HO}ig%6sV67Z?D%$#P11$h>MK;;9gjm8L3T3 z;7UR8d%xNlbkxy!IPVL3*Vev8M@Qf6u3WDt_qZ!lzCuAp4mJ`d9|5}8(a~1F9-GDA zK1XO3$@duoqgH#pR=c(FCO$z$oJjDZUI2seyPwmnP>hU7W@frLthdF#*)G@R7w!fr z2KIge#p1*_A_&wLyDEK8a1^V}p*-YTZ-9`ZoUAM=T%4g3Hr*Fw3+hr}cJ&9%(ANy? zoSlUXBp+U`wJr@0u~ob;& z-IOCd49m##?a?)#+bPDIVm2pIugB%Oq+vzuk(n7zO5tigpHu=-n2-QuL1jF0a0;5P zr)RFkRL+blnf`bh)?o@3m`b>YsGs!swCi`f%{QhtpZn7=e4{Y|?>pErWd>H-TtPoP z+&nLo^%$~5#XhWwiHT5iX=uJtI0i#zPSzqsiWrs6?to9hr$pox+9Kb7n*u|9GTQZO zs8S5H2q=}}0m&SCFN7jLa6VzhX|XFfumw*0{zR2ysPLy>GgxYvF3YCfOi4E0)XM}v z%|m`vzz8v#Ip!X}Jm%xV<_<~4L?L|KZeg-f&v3X}hkZUX%@|w=!QMI-aBnaM6&FK! z=g3v$B%@m1fH^vrX> z&H*4hRW>OfAHrf~Z!Xh%UAJXBEhz^FX8LxX#aG_wr~n)kHuDLRPvK!_4Q}tpOTtpm zp4%8w>1VT3Nc|KyS#7Dh$khIkBz|BVNhWZPijti)S$?EfSI5Q0sausRc?O4v^YVAP zpNP&v{v;qg){7k&5PeJTjcKe4wrMvGtg}fs%$!vRXNV|;(lp%^9WV2j8oq4=u&?nO zIE?Kwv6snRC+T0T>)9%~af7yI&o7Asn>~K`y*SnV(&BJlw6C;9{ALY?;zFKRpkAOw zu`eFaN@SFU7Ect#%9;FzMW`RGqx{Uk86Mypj`Z@dqZRUhgGGWecJuHUq>X!YjP@*J z6Gk*L64=fV&?Q*>Fpg9SKbS;N<8I=3nrqk;pe>61Cp*|7%S74CtDS-8=-A9%83;oo zduX|kG>S?{TiTg>JteD=vZ2LlU9`6PhrgEeWob8DB4oi(2n_(VN5D7P?DFC+wvr48 z5PF+c@mwV>DJv@ziy-+qTep+OZ>4i$o9YtB$Atr|8;K`34<|%k0 zgm5_GeQbh)@!HN1M3ls z5MdN5$(Zd8sTgLD|(h zb8HDo3&E`Xm5z?_dmHF+zFf8ZZCpja-uSuG z8{(tr9H}uk##c1O?UY4srCGUj#!cn-=~AZ|Zk04;Aye8<_)(P)%qIyIXouO3wSQs) zoW^=eE7YH=mISnO1+Ct~8!x?BaU^C9^0*J@D+&(VrjywE8XPQWC1-{vd4<4`mW^!nSIFSj8-fWpM^0(*bJXwX_; z>8Ai61T@6JUPWnXoh4d3__oXG{ur>XbFci|>g~&q7KLa<^th?08QuJzj&YQwiwzR; z@^@`cCZ0Yk)1#<4jYp=;a(@>W!|hIF>irTohyzea6Pjkje(*N(m&Yj${*zHPdVhdI4KbYuyj^Z~1RHmJU`yNRFd14{%N8S3Q$x@q3C>q2_x?-HA5xHF3iu+ zSQo3GP0uBVm+x7^s*{T~1?u6VTy6<@-_cCg8?-x{0Z^KT$9H-5_2$M|gUDYKtE9H> z+%Qzg_bE|N)YkO0*XtIq9&MRjQ0-`c?1!xwF(`f8Yd6$TXE&v~b@-$>2Aj#CXQ))q-=WY`1&^H7aZUF!~$eSSc zX*IQ>VF)Aez&dPp1yRSY1KXQ52-J4KD(ieghQtMHW@ZM|k9i|OB+tJgI6ST|o83Mh z`=e<7c#sPsKjBIb*HWyEqw@E5Cp;H~)gp*p%)J+QZzm_w8X3EyySZ6(Q@k~*POARlCjav@g-&|%XIEB-83 zzNwZJ_I!YDpNmu$hqZacHa4Q~L3u}EvEbn1si`ki{Ss}S6_bUwWV3UGn8+2%HUADv zL-obYxnkukaB&Ac4?^t~)bv~;{;Wo@TG6aMoTFcXoFds(YP1YsJG*)|U|UfcgFCUc zbJ?$tmauntpop+ttZ@-s78QwG;#8l4^Fn)g-j#)$!F6$pxjktPDT{@L4OC$#TyAu# zo>6nF*{~VipDvhw%4f2MP5wfS%pU7@JJYZ>gh3_{4ofPPrD@YvQwSE%9z$QSwX_tz z+}=jEO``!idz05lEUw4D#VZ=4^X05(3QbMyS##J>H|{oT8}C&_|nA_PahiJLgTuRmetlKbm+*r{yJ}V-#%TaEGeNnJ++2_fxrD` z*i0#xHeKxZ`Y?kB0=4>hd!s7Qt=n1EgBdMUr1J9e;^Cd%F%qB>W6QZq1M`y9PZ}O( zEyZOrYhjz8K>=yC6d8xbn7dm~@py(jgzq+{--^3DjX<`Bc9vhD?l$Mb(heP%I z9ylfRsNd&@9|D5Q`q@FTG3I|0soxqhYd@6pvHXJo6@Ix|SCfOI+5i2;{bV-Nt02MM z&54NBbQI`08CF3U_xHM1)@2c)p@~!L?Jk){)1}`W(ryX)+>ehf&rVNmH|dq&>I_9V zJ76P?j}(pco2t$;qw3M37khi#JTSh5QT0oG`-Uxm;x+q434HfAQ*e8GM_%2bZ@**jCV90w>?<=w+zxA!VLri{JTB#$pXpv38Fi5!oo4EnoQ9I5vpahMyAAM zWZ*ie*dgZGo3!uV)AMmt8lGAv>Hm763vKo1w)5vOuytfLeY1t#GXC09Z#u5| z)T}w*10Tg1uuJqjmUyj7$}jM&r8b)KuafDzKPD5kLeOcCQaUG-amCQA0ja@CG1rnb0nl z-Q3=?v6>U|x<=jvCU&}C%Hs%}0!w-YR-=c$_zgWeI+~T06+pSso})1Cb^xzb{Oi6S zL7dM@0*$z5KK0kIUBcD6G+%<_){^5Kaa+CLSIR# zk7^Y)M-VRz)KpJG%E}s?GjP6K9|Cm=2%Jv!u3N{XVg(Ni{vqRi!nqjONsW4zi2~N$ zGEs20`UJw}%W4q)E86E?eFw>z4MLb4XY7KS8nW|ALOpKbHT=pMRJPoCkcx`&cWx?h zPXf^q;z-bD14*f=!)aH@MC^%^sW+=t#l=yUxZAftr7->)rmbG8HJGCs0X1nO7J+7<0N};D`}-ku2~JVbj+sFO^kEMU*m=4S&v_lUP*H5%Ou4({_=d6% z0Bd-5HopY=9HkAU4Y=ct|K?LC9<+xA5cZE`*8Zj6F#MB;Ov>nN=JJm>)+p6xC=tMT zl0pFwqLjm8n=>BYACu1x0@$dRkB{5wa#ALk(k_vJ_tVSEdYh8~i?ZiCOdrGENSwr% z|I}nGiKtn1knEyBQFd?dR-qJ1=~vD^vb(dTR)AI)F*XTc8U6jqBhAHHAS5d;h|Q#L z_zgXsQEyx*hO`e{q=wfGk&zb7Kps#V#H6J)o2LGxGf7FIh|pbquOrEB;^E_4`~91b zhNdo0n0d-Dwm%N1#eRisy^3aFy7>I41>I3 zQzRNts5bec*>DF|v>fAfJZjeM%9T?>pXlYRrt=}Z&6!sp=b1Wme~1@&^{{3P4r)|@ zk~j91$d>SZzPY~M%aRI*7w{*-o;#LBRIPQ`apT`J6m+OGZ--wlhZc+KO>Bn%G?*=}}a(&CQ9 zoSd9QbNn{5?ZMSts?tVBCsg3mg_w@j>vXqYY4AG5aI$R$`Zh4|#T5(X5r>&aviLmg z57*n-kK&|(KAecDafW%#hbfl@0@mrY`~x&@|I;#b4XF8LSJygHI(!;{XbHHa~N=6ZN{Z|^y80#8- zSrjbH)9Eyf<6$G83b{W&EoMU7R+g3`0wjX_$H%{DjsZ2`p!4)+iVLN}qz89l(4Ha> zJ_)|Pf9w1ts@QB20uP)lf6C#@w8Qjwd@@7?^m#(Sq9FLZL9v1^UM`liNQ+Y~RgA-7 zAwafd^MgbN{>aa8FP>y|VJViEPkOl>dlOH@F}pgRJSo6t7YrN z4QP;%`nX{JBxLuD?zbSipdCAB`0j|gS3XHMvV-~+Ze^aL555?tfAFdbII&1|!@-O~y z0qP4dGzL04bgo&O#3IqzTz0E%PK8&kP7vC7x~=v`7e~P6EiW%`44op1R{aA&6h3dY zCe!V)!#`*XfSk*s2+B`JNf-zY=5aa9!?*)ufL0RxiV^5jzRg@2N&vU)cwcc3|^K`vuK9TV^M;0&xm}l}aA{{3(SOC~8mOt8fQfOt>h=?l$uAOc6 z#*^5rJ(3$zQalN4@YDJ7!mxJWj;vgpu7ZLcpsH__+r4FQ-=e39VQdv*R&xnnabXe8 zNNXKx5ELY`WiX%OFg#-k`9{XZSm^0vyH|SzEM7xkP*z(XU0qy?wbe<;3VMTr{1b@s zZ6*Ezc*$|^c!mSvMOIGk{oQwC{X4(_#%)}_e@7Jkn@!#G7}mcFj9z9$u|-AznG2E5W)U~}_rqbiE{NZt%d^LLI2!PUEi6iL-F(4t zAry*c>rI$hl~h!mpRP!6eh2=$J5hBs)RGa~@wz=!KJE6o|H&q`EQ%&ENYe;dTX*^- z;q8EoBx(x>H}FXRiDXH)N;@%CcQ$EUmKa93r11{hr-y<0F5dwc<}h zx_BI5zBT&2x~~rqE%u?WHrj9SejHGGTZ9IJEcyA|&jW=7dipPpDRF50xwVi1H?THi zs~Z3b2+`;dj4|l)31o@cU`U66%sz@=6RjVeX(dRZmSzlbqB0BW4uZCc*b+hD5y5sk zUsir-Ka7p!`scRSJ(a2s2metay7n65EqI^=!Oswp(DOn1GL#HZRCp`d+kKgfxonE(8PWWoLRsR`6K985mgoU(o zUre1FwJky|*flgX+;@lIB#)*U==hC=(Jc(`qCR$jLZIh=L$d=|NcU=J%g|F{!S2CK zq11^k1*9poRXw6us_i3k>)d0hdE|gunsO zbIV{rcH5JIS>Xn(fnM;=hK8H{v94?`2PIW%bwObI^zQISzule8kxL;r(z>gyk7ND; zyoe~WZH$?$>})Iy43Zh>a_4+Wgy_iMf9C6x4e1h~D_F%3PftakO_p0dYNfI{k1f&} z^kf%ItgL48#isj1U;v$B=4jyP;E%Hwq1t3p5}NJQ<51|#UGrzLT>8++P~M@fot<>M zvaSHeKf!!(R2hv$UjpwAUWZNC7Xd)=0mx-&YePd3ug^^pJA0E40F>S%uE+l2tUFtxitKo3S67!r zOsG0BEa;Ysfx&I+a-;grRi*{#swgP`ezDjb0xA_E;$8WqL5C|GxHxCoc%aGe_yThv z!qn=1p;O^n)({he012fcMu&lDE#PrUP!uU!s)_sXZwnjH@JNmB7OMvy84Z&PM$n+? z=a|(sG>gZ_WDKYep(|NI@iR+Hxm-*?vS=xWdp!FLEiB~VqnT;=y#~ObB|PsqEK$@B zijXXi&*$(5*0SJ{#Z*fk-(cIE=8u(?z}uXdT(jP07E8ZjyEB8cSXx<=;5^srHHJTI z1h0b~qD0u=k2oSyjYu8~ZwogXp)80{+$o_?47qO^2hz1#eqeVeY_wFv3=28!iqm1! zAp!PL#ldpO-`aYSmKylOu+w}gF$9r+(zd3 zN(MU(?cIUUUI!k+0OT9OG&-#p=&p8w)iFYx#{Qfk7AXZH+fIRIeC~+hrQ)eh4!&Ji ze)`)hjTW#dA0@g2gJD1O#D>E_0b|VT5q`o#&l{$63dF zM2W(t;sK~gxH#PR*Gc{`Vn&9rlhB$gHu08eEi{46n3r*Jn6J4V>e^CP$yz66s;T&W zl(<*sk+oHnJx|=VQoacM$?GiD)s2S_yWd^BSfa7aAW_-i%^C0ir zwLAq09nFJ*)1j04%le78s=fu;5#p(}-^+3P#ac!r!)c&WFy9%-t%5~Up)#4(B|+?%#x(%Ish7BLt8C~& zuJxiz5Oup|lj6r49sk!}%e(~9q)9^t?{YdX^Mb=ZUF zx$EQQfT)mo3_dNVekxL>Iu8pA7@kc36DbB*MQn%oJt|Gkowa&64Z-<^Bl&C?l+2b7 zOkQ)HWfEluacn9Y$eqqO4?MXvA(;-MZrze14h$i_V5l4HtP?l!l1_0QU9u zELV^e6|u-LagfR!=z`2uMFGi$BG8hAhKL08ns8k#^cml#+vy?GVaS_smVGtL(xBl zpzM<{4A{SOjn$}|BUz(xVy|WWyGySi#1KGFYEc4+7MouaiV1c{=+g{eAx0iL04G^V zMY)yI@<{3hNN_sPD2(!I6Rs(}ScOy9yqn5Dc2mB}nCuKdvDbjt=ygXMr3LwaRoX6+ z`7w&#Z&=jP!ENGsbbda>9}*1CF~1lb#Y;f25nsA-A`%BtQQ8RFgOlmfGn-7EN!eBJpQ5?iHiq_ zD0z3V^8sOlK}5udVJSoh<}_i4@Z|W~k1jmunDcuC5EZ4)M=;dNq^xe|qKcpb$MtlD zyJZDt#fxnM^Le4+cWF{);_S4S-=_-Urf+!bKt=#gqB7B@8&2WUG1b7ls^b**S4 zwixu1WlqUzC9j~#oFhidTP2k!gB#BGT_{{uf2u6?i5%@huVA{Ru8Uj0vf}X$otuvq zR)3@{^~*I~lMT)mI&9qx|8k3tC3dTcEd;soANdqCwUiL8cl)#|;5+SM!U1>DX1~#K zes1fXBhKx#I|OJ{7E^!om|h2thGVc_A1?4&DWd&?a5|cSv?j2RrqPwb)d1OR1>maL ze65nHl@%3>wFbR_15^^<>aZ2=1Gs|oJR~Pb_=^^1lNJfAj0VHcp++4i;ZFdC0H90AxQD%Y;}CJAY-~RsoJVM*RW+y-#|n+eBlb(0<3SDV z0UuoeELF|9?gWyL`-uz}VN+N(~VdVtx*X^$Gh2?FwIM~^B- zWmQ$7Bj39`(KIj4ZCA)u6_D-$@nC=+K-*gSId%K3U0rX0t8jf?-{gniwDR{aw6_aj zk!n;AF+py1dQ2@YLc0$GIs-nMFC1C$k8uNjPWv(o~l zJ-^DfxIpK=(r_wA009=Y*A1LYcQd}jqEkoV7wJ%V4U^&Kl2TGyh^@i0271eG<&%;VfOOpVJLpyv`5me4BVggGdC9`qng4e?d_Slxw)yu z67Lm1Gcx*UP)mYa(x}>5h$vy~HT9+70}~kNCrTBvB@Zg(Qel8G)8@3-k(qhYRIWvoaE6ce|yy3969_9Xmh`?E>+y+ z4B}T&QK>P&?zM@_S?cl@VXht5|4G-F+B}U|20p;t$HvW_ft1}>TQvTIs(27Fk6B3p z9!|X^%(?H^S}Op>s6Id5UlwY|f%K%A&GfV_K=DQ=E1hlBD-cPdqO7c#(|5vyz(TU$ zW^z*1afMF-Ct$7Dz}Eu3wNTs+(+AjWo!AhFPoOHL0L}_^+~B9D`Wk`nYQ1Z}8=dWb z`Bz&%E58R;6&65?ky`HVs!KpwLdOI9Hu(D(AujG%Pnc>tU1@Q21tNSzl7dOz>*KJ8 z4vS=LBq}}ba!O>78g5BraTruR$C`DLrrC1g9VN#yG&J-JN5#5q0@A(kNYOa#ob0!B zSr%K%w|K(#=(B)90_q4^b?8(T=-Iis{9s2zCAqa|GCCl9wj7eT+-ja2e3>@h(RqJ#o!E5_dlqcLO@0663K^GaHzzKkD zFZp^zf|tjeV#_dWY;3oabzEF?2SzYM4QFAFnFT=Z&_IeLuD{;eU+Zu~@SPs;xLg*w zfXver&;QMQ=7d=x?~KD^45`TSWa2!Shias>>||o2;qciH3^HNuDI$5=-hWSbqQeN+ z|9N!M>d$iOsZUqmjA7&^jTamsdp3$+yg~tO5MMc zvVNeIDVc4%NJu0ZeT^!Kj&SE7UeY*DKe5`K1l|!{sd~KcXsOmqq54*d=I-p23*Bt= zsZ^;HKxf&1ULLE9+bZH87q*_0N%x4w{VL==JAE{hdTPY|td<{}#PaG`JXHtKcVawB z@mcY;^!5KTu_a%3?wwU2`aa*Cc*(0Vs4vc-xCsL!Mn*i1VAmnCkeo_f@ z09Hbtf~0tD2Ma*F2L?vgm$!idXS*V{H?Xz_M5*USMmlQLMIJ9VvRTBIk50E@q01Wr znG6Jby;NCTUeIgZi5c~5T`8eE+%8x>YU)TiF|Glb`dmb3P#JI<-k!pHT9dVXx^EI7 zR_vwGUo-%Aot}b0e#o`Jhe<1z5+v|VT84Z7}-2jP9;rH>gE+3Zwkdh>8NFZ0Q;QiDN*Ln7Tq;ljY2bz`u zq|bQB@nPl9pBmV}-!@wi&uLq7B=-h+3UaV%eds2CHZ8i8sovMSJn}L(`|0SI7#OyzZD^Pf z^rL@E{GNC{E=SX7LL(kY)pPhP{sMY5jcKjEfQ*%70?{xQ3p#LkMc8~sEIiLGNHNuB~N1AqrO-z9vEd)R4SZ%ht>)0$Id12>&>dV0Bf; zGCHLrU6W7$lj7>Z`dh0Bh6sMBj%I5_M6-H3aNw&h60mUpoB*If8@Vq>z-Ky^xRas10H(>V()>?Q=Wi(QG?6UwwLkm%2u~K5hl{K!~@<+H`U9 z5rA61>-`h~&Jq|%rYls$e&~tmT|D2iK8b14=;)^!Y3XWZkQ3oBghN9Evk-I!{vaT% zEur(L((b@L$1Z`02mA%_^uWAbZuZr2!?}5Y6*vIG-=tLVq7IZd!nA-o7lUDRGEid7 z0E3m(+-xS{)@WLR*hyTkTw__y>3py=6YdM5BgC5pI#!|pMo<-U6rG80@EfSEV&(6? z0)c{bD%kNj;MV*|{-Rm)y`O3?kEYSWqNqr|&8M|wZoSJ2eF5HjcbatPD-OsyYmynH zq!7CTD8GXN_z0<7fIC&K+rq#7KrLMT4LH{{5W26rz=W*V<(XvhokrW(co(REe6jsr zli$dQC$QpaWuEMq5{_WNAtXg<={z)2u<^;=iOK3rT+kUcHTAb_-mpn(=Db*+hjSt> zdwTc*M0`*Ixmw=R%(jeX89OwNsvu4dFbuGM$d++(5v-h)q&vWvCK};|3 z#*cxy+}rtCV`7J=IQ1MMA8e{$#3S}UOpdj9Us|?%oah@EETL!i^aR1w)z{^G&Y_~F zjtl`MJU;f^78qV$=3`>AU9KyRNo6x=TWV{}&dWQ! zJPi99jmOFYL|4xb#qTGr&2n=c5+hDl2d(Ur=@brUsd3+fBWrJRJaigVh0FEtZZdrX z9ne#91ko)-bI2TY>*<#S$%Osastoi1YW#5KAaBp5$AC{tDj7C5g-6B~aCaue)gYjX zafHQB!5LfuOr87SmD*cB*$LFw*JEj{Hj!ayoZLL_eF1NB=F9n$ty_3f5;ifhozFTk zK0Z*&TSP0v+lUSn0G0=AQawSv$BoYW0hCc<0RKU&EK`ikPy@op!S+<9lR&bgL z0*du=FHFmaX7g4{inLt6THj7h*D=7tt#?L?1gK>VGYF{)MQ}CGsS)u6pcOYpCM0L` zK&O^MwR-HK0=@V5TC?GNhpWSdtVa-@VT}HHG^x2j!bHz z1~|A4CDqF~`JtMIpS3hHA@3X)WaHP=zRF8|-`+Sieq=rc2adghV{m09n%NcTD#2{? z)7oVAc*T=l?T0-@1cXOWB7RXC*#9JDY>Y219s-u&MjNd?veFoWwQX54lX$K52YZNM zmTF~}@mpfMqqVghuuWK6OqTSpN6#8xT%K0wHX?`WYBQid8g}~^R~CB%l{E%^`RgU< zZY?TMBWi20Skl(k)_5xQzVFrp2SStM&)^s+^G||6@h~KUGlpj|XrmDp?pDZNBwJX% zyuCFmn=p(t6=?(W9H~G7QY!tG83LVO$Lq8{Q4J%N0nUssCV@``T9mt>fDlvDnKo2aotTFXBnhc(aBx0eK5@wOiN?n^eZSx+yhpD`(QO) z2JRV2|;)V6!{sQ7z!sDEn@;g8=WZ&$X=iv6*OZ`k1V_ z#;zS9=%5mb$f&41JkI@1Mcf=ei8Q4BTNQxD0~=gPwZb?QeyH<{w7-Qyq+JfKfPiGv?5*ZxHYs0agfw!z7JUeJomo>O#{&^r*g0`H_6G! zs$Apc$tKGj*ArC9NH+$`gyREXczRG8=;o^ybC;z>a)WCp5z149yHmLs5QBjSv&3W;_kzsFd&*l0% za>zk)%nSGf#l(WY1a-BBWdfg*fPT(r(6^2Iz_|$mQ~sZ&+Fx24aLt1LPa_i(4OO>_ z=1^9%$P2HVkA8d+jf8vP$ZrHMFf%gZ44%LOEttS|3jM%FrQpzXMgoHe znSA?5dSNKs?xGB)*&bs^)J}QOD@M5x8L!N~nPQ)r9$fFh^k3Vi+}zwta=04^W0Xno zn5nIqjDFoBgoq+RgO@&{lrGU;hP*^%tYJ^KIkyo45ia7jul%9(b#bSL=K6+xrcQ|GK>*6AY@J-M7YBS1X(;~ICzSv(6 zumZrK`QYHt*3NG0y@5fcQr^1#=o_!)iFxy(i38Awx_Wpl&Mu0vhY|wm2%ek8)h+d8 zwUJoBqr&{D9eCfC)KpYLynms18g%)N&dzSl(Qa9=L2H}+Y-==T0DL`7Q0Sbh+L9bB zEQ3Dq-vz-S)TF!4>cx<7i0SFA_K1)p#E5RObIpAJPRdSES0Ud)%4q7`?BDMLj{HwX za&pwP7Gl6MC?R12$+S6tdghpPazQT&pKs6wecIgYJw}{jVsi-S z$DW=aBwtjJ2j2KD)qpOb&>yRkKpHBPg@J(pNWq}{Opq}kbx zrW}Ja91qM>c8unTSfYB)0&1+#S7j0$7huh6s@HM3{t1g!l+}D{|^rKlAi-83Y(y+9meROcRi9LYGx5?>OS^md6 zCY+?P6}#if*0FLLv2*~qY>gD9nXJ#dpE`wIxv1D+lv_d&(DOgM;pQge=lU~*W>VsH zPJ}R{JRH|+Xm}#h^;8P$IRCEI1qs&H)V=`>pBL{`X!GF{)Bz@PPvPs~;W3Uk38;YK z;CJ2^17ma0v3M!4zdjFwfEE)|Q=ryLw+6!pX3uoIM{)iL3ax-y|PeW%a$@med+IPtb{W_ko}VPWBNxPUZZhfqNs;;-g*W(+3m`N8>? z+X`zaGYeqG{`T$LoOd776oY_R9-_KTj|NFee1#+8`sK^dFD;vF{*eg0DB*Seza{E* zn(PVLwm?PS*4nnobPs7kk-{8GqA*Qk=29^tcXBJnM8BVh8z3adM-kfq(~{z7RQw(y zK{#p*@Fc)~JI^iUEDb6zXZ{-o^BZkpw&33AiM~&{3X~=xkwAF<)RiFkMa7twCRWdM1pivK*4M^~57RTUBxQ7}4ELuz*R_&ntNUv!D2#j6OGO5Mh}r4h_VF(F7EEd(C3 z4mMUy@+>omOWPzWy|-RAs~~p41q`JftQ{TUS0fxHM&f#V$;il*xd~)Z0jV8K=619ars4725z|x) z%J{20kbm-P6?-0?4{DaezX6ZqCO8AG-!K#Fwd0`!+G&(%`xyyVg?RGmHz( ziS*%B=5KF8vlL(n7H7dWBR>fM?9RUWog*rYz#Uk{;nnz<2tMxv0s@5K8@%_KHsqj6 zEwr@KftPYfD1lENt!S#88LBo2w)gEZb{VQ=MRfFKhj%7{xO5qYOO;Xg`usc%OT~K- zhvOE%CkpAO*jIA9!nBUgaHqVKY;EOBOT&A5?+V6+2gk>6z2|7oJBYy6Dfu$15xIvP zjDr40gedIJn;Sj>O8d=7lI*j&h$b4UZg113TBgWZ9^U8QESAc4(9sRt1%riZt zAmSk_BLk4$p}wInZv;Dlk(MW46DeyrLGV^Q42$h@5eHHhCe`;xJn&?-DKk5J?#Iro zZjUwSU&ZBw56YVq+~S|2X@P5+%dL%vYrwyWxZ(z|q8(`T!y-W}Xx1 zGps?#%ZcE-M28C%q-~4Q55g^g+x?_Mxk`%`h~Y)p$b(a$5*Z2c$maCE&=RIC+T4Mk zG-J5rEG3!m{;-FBLD};c6n@GW{{Do1sX+EImw@e##SHAZXWk;%L2>b+ z5lDZEK(kX}Erl=`N{fd_uKwl-Om}eTj!Jj>$u#E>^J;9voQ)Tm?fc0J(Wzo?;O?i| zzp(kA+4Ng_Ku!1eC9Cqi3GyLeHX9^vt#^zRbcF)JlYCsbBQKd84vfBfNdLR2m z>77rgqO>BN5_E&}T#-!8J_uxBP=P~Izu??=0_G(4Go%mxAJmMT@qzcus_B(YnIHRokzxdQqaV3UQ3 zJq&?UDj7hi&&(n!{K8p?ErLz3E&7-$gPau_MDuX}=co8xiAQM-6buzdhwbX(uNOZT zC1Q96eUP3M6a-ZVX8il8bn*Zo1cRURXQ&38LP2NpkNFWafTpHi0ZMo8-De&LCQ=HY ztG~y57^)GJFyBE*OVqC-`2CXbm57OK` zJan&l;Jf>UQ)FpD7KwnJAk@eKHHMX}~tv1P}u?YFzu@mvhOU|cP#i83X zb0k2|)NN`&%+^w`n49VTdik~gMy1vuvwKJj1(xGYxa z08#6+a6sH%7%-5ACQcv*rGIGy#oG2q6fdzLEcz>0_t-L>b`P|*UCXb)ifrlvHKB!c`YtPn3lG;3%g@+^YSRDIxs=sT3~bidliQf42pvoS&c z7<>RsO5wx0^T zB<}gs#(8KgtU7VyQ7{s)U{Zna*g=Lk8G?q?M8HHa44{>J73_KZ1yqAQVx+Z5%unOZ z2=MyQ)m!P^a3aQ^WCgY0V8N&ul?%8Xl9hdO%ODK0l9F%)vGiEK@kY0#$j(IBM^7M6 zN}u`N&o-f+@bGXMhU424LN8(=vY{FGRMgroE-LQfO5e;sK+~WWBK7u+C$Mj0u`y8f z9_UTYKr%wlnSES(G_)B?mjUQ)0KU7DK%c;Nk;zCkOl60&YZL?)JL%N>vp`>VvG=0J z2~>L^cFm$AbpS>S3uAH*n2cVT>oK;(j+H!MeR-V{wB7$8iDB$WGkJIpO1RR7DOh<3u87AXq@NF+j-82iA71J%kg zS_%k~j$k#sJ?ZbfX4|dTEG&Y454bT!$@G_A<5JM(@ZQvZs!d!EEDtW+E`fJqt_puu!rKoXUZ;lVg@0dvmz5IQ_aQqfk zIrXa>S?`6m!ZVGwjpY}0x4Ia-CTf&!Yqdu)s_ z@uW~UOTc1Ddg$>0Owrm!wHC@@w%AV4i=^cAW4~8su4d_?z8A4%(z`(w9(HJtd;<0G zm<0`m@0O{k^F^P$;}IRL0V>VuT6$UI^HduxZTc$u=z-cdP4mqfGu% zcI0F*WlXrAU5uyvW^<26Hy=r${M9U8-`(x&UGHO|!c2;^ffVsoH*v*CAuAnCuT!V{ zM(*Sr36P6M?kXwIE+WdcJ}JZ^FJ}|kXG$bDr^_8XtQ&QfUG#Nn5eUaN_8u$DKYj z1*kMKm1CU)S0gC=g}g6{8XB$uyvu~2@GM9%2=wC+XaMy*8==k;rl5}~g*kPnU z)Ot?m0&kU2^`pfg5TUlq#^6+iUorFnzG*s7*yu-H*#MGZa)*h#p7ekFp?mVb|Y?%*^FD^l{8al_($fCS2TIc0D7u&Vh-D zm-k0Pf}=ftoD{+XkNF+2XC(>tlbeE=!ki2K#SL5#<}@-gvYEaN%pw}<0q+mT)0+i6 zaSx7M2TCaUtxsyc?la6QGpFR(A_;}*9>N_?GVjXcQ&$jw@{7hsd3hjr@oOOHp8G=i z^l5bAciF?tkIJ=ngk?Nx2f@HZlguXDVqVj`vw{Mu+1or3o#pyK$Y0R7&r7ywXlQ`h zyRh57^1Gu24O8H$*tb_tL#Ga@r~m;Gc3qf%-vqh@`ZITeX$e;cTO#GJjgYL;YbE7T3`B_;IsTTKq{Hs1hd=EdLy=;3e(p4J;( zpR3}UGBdw5YkeH>202MXrUbiAKidX}hlhVozDo4+X}Y#Qsx=mE`n|)EVFSXiK-U$R zd3tn&gSi>8F)`5!+9$O$SJsb&#Th&fW$o=BA3bsz!rI&Qz!15m6Oe+ddjQ-85i2L_ zoxuFMy1rfo1p1hb#Lj_%P>`D;ra&BbL?qF4wgglBS%mehE+i!kH&47cGxkOtZB4i~gdHr&(4) zu5)SXkh*1)K0|l2T{Hwfh~wT;S-6LhBAV=-n9<^T2@_b@^8*B-kM|!GjwYw3Y(Wr~ zGQ6;2H*f=iF0NFCnwBlQuT-Kwhts=`=FNz?`n)linE4NflqiKgXMGF}uhTIj=m53B z;`i^syI}c9<^@PYNrlSd_H1G&Q0w}W#tOQMz;-|1_rf3m*zC@vrAH_V3Gn*h>$;>w zVp6bIUQM7>Nh%2P06_`8hG}cTcR1MC&@eFGhT*<5dyO{Vvo_kX--3Zhaj_(@$wtEl zue5%kr&;@^_Fjm+baA}g0H`nPUC+oLwyHoEDRz7<-&Lr@$v*RbZ_J8}kDSLoBQCCq zCK){L#O%fpoK5h=AfS;fHQH(MYYYM2VuqGQPt#6KnGD!wfb|_?iG=$#=>A*WoNL72 zYbZ5YJV|YO5#C+w{7R;$_27wt>fX8=dj5^v?HLe*jj$RYPxgYU3UA!dmlkwQnac~Q z37?Us$##b_o^F`OhsZLRW1BQcWY}w8U+jLMHs_l7G7hQbMtSbB=%~-cVg^qlWAl?9Q{K ziokfx_vWvnWIXNUTdw6WRZZ{R$3J_Z+M#j;_#RvVL0ym>~vC7%$uYB%b zCJwOQ>#YkpY@ScvTr|_G9PU1C`A)7^#G>N{%oa!*H-{f{NCh4op6=Zqrd}C1*T6@r zs)>`vF#0fh>8Pnuvz@|D6Ip)@K|s4w9UOo0@3N8Y_;)C1SAcz_KQMh5h;4D?!c!jg z;#yFOB%J1v1DbH$z$Yut*)0e(U|8T``SC^E)E;)g8_=pe0kJtT1RNb8-1K*>F9Ca` zqJqrq;-W+#a4G?<#h4+(X;!?T&!=>Ervm=0t^i-Asj*QbS3E)qII@Z&u>$vtH!U0- zDuLxZY7d#>8l-eBZtn1txyuHwh#KVMivRirkXyhLj?}YKMRc-kS+qo;5kF`cT8eO! zzVqP{dc8O>@Ro;1s_q4rkb#M1t;WO;1WdB9PW%f6z_kP_zO)}ORDzsHJZ2fFd0bBY zml8p?=XCM0ap*4JZ*A`7OMUX@{qXgByyvc>2A2fx^jh{dH(M**=1MX9dyqwohXJl7 z{hC1<`@WufCf#oU4r0(2BO&l>Z*NB<6U^YfI^4F{8dpVYN;m3ai5Mipo>MSIgo#WW zjCqp(%s&XG-Wz79TGa;ame$srnjgtvSj;RflM)lZ$Ori542<`ddEL(y%Sqb-!s|&9 zoq>oS5>ri^1Y~k+pvPB~C8g6|63{E{>S$-glW^#Z8G_*FP+w46tan#uW+AX0&G(K6 zcdoG;?$%mOletxa8LcG-WM&pbyjYn}Y%c@-;Him>>|eu5O=SyY517T*vJqL>)2Ru- z(rjXqm=_SCc)Gjy(W@aUGE%w9k1zmL{hae`XT0R%!s?wk?S%G*=mzs>8ptU_4NCt$ zgwOMr+y?cUZ2IBmvySxfgH7zX!HI&oYuqn8| z7eI3vX}3KPHIfQIX#zn&UHj8MiilZ5y}W>&NdmvZUr?7xBA5ZbzJiXwOQu{7z;FoA ze%2dd|8AJ1ht#I+&qk zpry3{lqLYoXMz$Oe<~YlS~!C|LDFyHNeN6B@uVrK{`Id&Hzq)(6IT@G1@pgSWR4FY~nU^h>R#Fq(#8XT~cR(|t z&AB*{6>{sy;n(r1K21;H#NetK8yf?I6flR$7t0W{)~Z3c4Yag6|!Ly=_bk_I#QltXITb!{nCWC?AKTqT)hmG9;uw|^L~o$+%w8E22Q&@Ga6-q$xc9F2)1U{z)W{&zQ`cmBD9WfKh4fM1!3 zt$HLw!`z;tc*O@jH$4{3aPo7Abm;rJvRt3>f3Mq(CfqYl(gl`&?WT+5ZjP!|1kqIG zBZIrUKR4T@TCdp_jhn*rN=X ze(;%e9b8@juvAS=4aEBbi50BPiSY?s!^?y3Ry$*_n6$KigaCB5q@+a7P$21?O~UN5 z4tA!xjLD>O^|a8cCUQ8IxV-pVt@9T2=n>L21P%_ftE>#UyT;R*$?z9MsSP%NmWo}Z z#1s(@geZc??)v&#Mkz0noryXWLrx{KAPyHwHX5$n?yp6gtjjiD%OJ`^J_MCT@!a*~ zH)O|N4RXgE^19aew|I%*zUng^y%KzvL?A&V%>4)M0)88d9w|jxdF%D3YVZyG_z+Fy zv%o!qpZxhk2qKs|+rtilgV|RvK;3S%?TPp)P3Z!Dr@4nRX^SUBe@?c)j)CD|xI{=y z3~)A$s|OX4L(lTLFnx_X%Kq_;&#>Y&bOrq99Nx&Odo(f!z{x?jsSf z&Y!Yefu-LqFhvT3m?+*DlqsEldTq8U8X~J} zYNC@6EKhw;b}+sGqbD@?M!>6cGD(QSOGt@@b8jP~I=i~6tJ(26l-*4|gAWLtOq0-v zCb$BQU=9qRC0Grq-c9W;-&O#Olt;?}?sMkOYu?@3n&B_Mkn`@9%^mecAS3{Uu7MT> zz$=_lq;H*j)~E2OLqJalA_ZU(JV8vszq|>FB2IryPPQM=Z>@nH2()?I-Y|hGC5@>I z85}Z6jDrASc6NKj}b@LoV+V*8Yrl>D=S z(OHc^!QGzUFx{=>mO}mngO7clmN;qTPIRP0A7!(yw3GoOelf{I0|R8Y`1$#bjTbjz z&lY_B%D=H`BixEZuYOFg_2XrHtiyMEz{MGl>b;q<$fXGJ8}=FD4^rkP8M<+CHvkvg zMl*!eDr9m>a>fUJ1X_(qA|D^0Y0PTV&h9R_{lQ}&Gm=D=eNDi1z}Z~Gq7V*+Vmcq@ zOu$}SSeSg;!vXE;I`uXgh62hQA|J$g@hAe-QZzB1uRFsVPVF`Z11~Uy6B*(D3UTd= zIA%Co(sSxR2ZXdT%J%(60N4?T(paQ`U}TRK-RZCjcu9_;nc3OV3~o89&IhP_3NnmA zOK||zZ8w(YZ`P)#Yk>f^3w8U2Q*IYiA_H2%itKdC2r#~AYk6yCPPbea2lY+75rk5K z5c~T$a*+}^905*FXdfy(Rh4cqxDO4>1vZK(^utdt_BY2dN_j;J5N}B8Mu+n$4zq@~P6c6W3GcTJ@2%&h}0b6B2~=DNCBz_BRKqwEVS#qrD3EcMn1p2u-5e?wO3VgUpC zkLu{SdB=A~3|!cXm|lVUBSJR0#T@;&0qb9R*vyuy$_w8CN+dzR$XRlEoPxjWD-qz# zTxV(Pg|J09MB^w#M-cjYMatyTr?6`S(-%N7{s3PJMQ{d;9tG*x$~P*7QdFq2MJ%e; za?yB`^a@#sLG!P7QAXG0H!XnaCsMk=y=P}UeOBxGbc37}X2^Em7;|^2){J5PaDkJJ zm(JWU4f-KA4Tczb2+p3w;v{tL(%~9p{ed{KnymX)gHS#YSYKJG0Gd?)4kHY{6*Y1ez-yN z^l+6Z0YXN;zWktIxJna~ApmLC0j0HAnZ4awP_%D6zo1*C+bDaLG)s`+t;0RDWIW@J zhzyMd=oN6+3EFRHA+d4*+=ZBbbk7+YM!|>{;jPi3qNbXdkT;Py{n@Tnu!d4se|4>Q zj-d)}GGGcvjp{2k%1jRtaFbS2(sHD<2DxuE)RMr00}|G_2$pI-vF%z!Q{wi-3V0qv z;6j=T3JSJ={nBmrc&}@HZ+$4p1_KOSVCjM(7*Nl^r8uy`lriPeZ-j?GAp$Qfnz&LX zwX@CT?j#uhPEAb#JJkrb6a=jEVP)W)_;Z{|;I*+bHa9Ub@Z-mi@$z>8`4aOHqHi~M zz{U+mdc7#fGGN9};P=Y*3ow=d(+Z^Z`>hZSDq;wF5eYUnRpzjW4#*(KGyjo~U) z>7kjKngC(S6#zGZyLYJf#*)$@P+yg@7iE?3UtwX-Rlbi`wnniP=J$!DkqZTzuXwtf zySp-60X{+sQ96i&BwzzE(BS%>@v$*Zc8b9Ce~|mW8>76V<7?=A;rP14paoYk^=ilD9oQA{iOMDQ75XnZg0N zL89ehD0q=U=3MY#&HpRKzrtmvTYyPIp^fOS#lKO3wJ!K>|5f=}c>l+b>})^)`5OQT zORXRF+$2V2w_mZQ!T+C4p}4%zIs@$p%HA|N2%z2Q>I4cyE6Di+YM(!0;m*!ZW){KG zQM2vIA0e;@>McHmfV)b1r|9Sa&%zgge*^Z|z5-ois2lcQ4WPYwe_03aWuT*@1E&YtMkgWw zN+&@9GJ|-!K3Q#Nl?gci;P1WlE}c4bR@+S$c3at8&KBO9fO5Ns4L0A`3=SQ+jAkX;m)-;NKMkE zI8ZqGl>~^Uza!wMa35{Y9|1NNrOklLA+$2T^WYd^=zkwa)?^If_t+Rz+Ev7Pm^Em% zm4(6OwKe$$|pywgs=kgaZFRHCg%+6-+`vqxMg**jQgTS!;qvlVsv7$8KbZe-ucQ~4b zPZ^_v>IsaBLIQ3-1Ab4#8j6qLa03PA_4zs3JKGfVzZUF$nQuxeD=SDyNq~J9_=z~o zrBiaNrhpvjJqEKuIS3}$Qj%z(b{EM2HTd#Al-Bc;FW6r)_}ve|chd7x`ST}58W@Oj z3_*PXrM`01zH&#%pVf|gqY!wsr!!Gsj7LBOfRlY>YHT|?IlG-ya@X^KhK4>K?2o_2 z#WFx2frN^>4@xLyHQ@eq zyfypP$%}mSr8pYzH5WGrZ~}FBz1(h)1_y(k*UA9D6ln7nzUP#q;NWWl(LSbTzoWOs z0}2WY9USbRV4fn-V^=}Ghk+OehmTrE0C{$5YFJ0CjBGG6QuZGA7DmYE9o@h3swSR_ zit6d!3@Ly|<%d1%u>mep%U&p?D~G$N)S6vxsvkBTe97XLosbPJID2QwGK{VV1|5 zA2$jBIJm5>2U^e=C6uoP?}vxR!1$rhTBHQt_AIEyIz@@)BHy6B7laY{>wY|I;f&q-Y$*&Fg0gCc3$2Z;s zoTz8|%^s}x^DspVvPz!rq^su?Wk9>yKR5uf@JWQT48cuJUnPLI7zRN?)-41D&8 z&FW+_gB`W5wpQwWG`iGP8GI7_K(g&W&)Y;?k&dPL(_(^mD_;I0I2u5tUJ{nuI|35! zk&TVhYdgkM2Go8XU0tFQ#a!IZvfE?_xr^ zKET1=9UUC}-q}%MUz!I5ZcQtV1yo*NLi&VRU@ve|0|Z@Oce>n3eB%UeW`j|P2clw+HZvn5-gJ4;O%z90Rn-(|K_#jmZtt(k zLef)@El|yXV=102^$#{9RBU5^e?M(R+y!Dx!F}vWKG? zFs#@Mw8ecMui3$&q0lgyTO)s9VFuw9pgRK-ObIr0%s68<=JN{xtm1a)AE}Wd22OnR zDciJ2ePolnxwl8`2?43Qyj(M2jKk2qAxIPTLcz#^)zEGlb{0j~18Mfo+3m>BM-zzf%%=7Z|bW(a_M0qk2rS z{p>*1J)+E7 zev8r=03H^;e?QV#H4LBqBSdybrTc74pgR3GAJm;YA96+&b#Y_?~h<$&lHUj z*&%2E#|Dht19N>O;%Mjk9QQmP$4k4D79a1YgC@qyprC>A_!xA^LSQbssJV%S@KFHJ z%rSaqrUkU(x(VnL#rgRZ2nZiBFfj0~=x2t3Qy94G=rThMn%uq>7QQpxC8qJ>qcm}o zmgbF8LHYzFE0D1JCY6{z#>M%y7Xo3(PIMd;p}1zV{kLm*)NdiLLFEpH#Rfn1*M9z- zSvI${>_b1n#2uJ6pc2ksvH4yCF#h+(1S_u@!jq}x4PGt_G39i1Z9%S(#em^DV z1!Sh%6XG}`QS7%fnUi_K7=7R}rd`R{x+`$)CCH{5?aQ#!s(yIz0%k~c!D<-ktAELo z1S7S;RfP#RfMQ1YF0)8%772uie;=KN;%4w3k|PlG!hBsz6iU+Oc7Xa$R5Ef9k9ISN zlIW3$5E~>R8zy`%7PJ;Au*>_26j?A_z( zU-CGC0QhWsSy*s6DMUt6QKCxBIQW0wojsrh%3z{86y%1C8CmZ@zXm< zf0r}eJ92GD;R1T^)y4DA*da0dHI`-SRSP}szb}tQT>+xEo&ha+%PXXpzT@tSc0Pp~ z-!tBLD2xM7xnE0H#jRZyIYFGwQdPgA9rNyw7w4PXfZNXknc8L^rft6lWB5ec~rVP8tgrvKMO8X+Qg^- zQLu=6Vx0d>DsRQqsAqYdVSQr6^sUp;Y^=Xb7Q1| zKJ|2j7Cxl)7wygt+wXE~EBvc#2Xcm-@>(>Ux^7P%1_p7bcQZ;8KNFk`Tr(+g8xYfP z4ZTs&rmyI@%-a<|M_q(cXfr@_Tj+u z8HYz`dh5JH38srg}Y4R>F z-As4k)K#GOqa@fTQwmpp{+MRc&$0G1X9R_PqkR8uH4ApGk}0&|YaIjO%0_O3A3nNTcI6vDkjm(=Ls^&lIG(oh(bMuRVQ7^R z78VzWH9OX5uCJ7vB;%-q^4e^i$Te2!AL|`lVzmz1=$SK#s~axA)q3>==?Yfbvpxea zyvxXMgz9wDyUF|?6n1BQCDNr06)Qekexe`Vdm)%0K8vE4@)$qp(4CZe9c6h1FNPo# zGPeHX`OIF|`HiDoy|)?1+rHmN`MN*iDA66B-1O;Mg!?6Nu4HY2P2GGWlPskB0)|J< zxkMr@zCrWBbD3gY-$uBlcb+KvASN^DyY7=dm$(flFCLB~75wHKmsX`DRjJ?ig3f*? z#XHjuW~rjq557XRJBM1Pm3QSA($W(eSxTvfKT|A?ro_!RcU;V{dahs>Tc+Hlbo^h` z`VKL!6S7*juy*&-=fmV$nxGv!_zEpW#3st8V~OdMx(N-b8WMCz(T;7R67DPmTC!F(1wr9TzEQ@_dIhV#1I1h; zh!F)1=TBNwVzQo<*FFB5tS!zO$x(K}EcjKO8GJsTu^#+Lh_Y6N90TY>gPM`~Ed*|v zxVu+G?>m1@(Yf{<%nD?t6iG+gWO#W#6c>4^GCA-B{k0FmR_HP5Z*t5RaqDPHaNS;S zmwRSN?rPh6t;V%29rHewTVn#b-k~%7`76g%v7uyy>FKuS@HIqBnpCfHy~mYnqmfnZ zv1~9POv%tk6OwK~Uji5Bb#1I(*uEDoQzbaRuW98h@f7_zQQx5r?W|aGwxqCI?T?W6ig`C8N?eY0) z<$j=%@EZSsZEHqfOvhzB zESx^73C8#d1ME2;Pot?H7KBe1%{(kwTI@{2fb@i`$}uZe(^;ii#1NZ0fJ4YsbY)e@2|^N13AY z_RGJYhj$$X;wOF@dVX3vv2rZpH>xs@r^kClFcRM%GX1#IM)a|NUG_MlKVPHwyMRn0{L|A|2xbxLDY{s!-WyX= zEWTl?!rwv2iJI-R4vq0Rl2J>)Zm_IL88I?Ap3?12S&oef;{ISaX0wy1JC+q$H@G8b z^d+JEiHN@t?7J~+Ti9>l{|ReW9x9VWW|8p<$3tngX|;2*TnYR${ZU09Cxiq7F&%^2O$0TVs z8f1LG9qMNmbJ7Gzb!2JcOR^zM4&;2eC}r~6Nm(g)v_O&<6q%4&K-O7D*jW)=9H$^1TNcTlz-x} zA_YHw+EF1hQ++z~6PyU2ZQ@+&I~g~IkkVHxrXZu3n)x#6i<)`!>zzmz+m}lo)cCj$XHtZFA3i%8 z{cxuUVYQ?ieiqIw^~)~Zs_o+?tU3|>{Ko~0ZY;v=BOdPUewpp5-$@w~k}_W2|8hg%J1d&Fa{2@Q^5^;X5d1+=6m$9L*%m@_ z+dVpQOwX9-h%M9LulzoeqpS0LEzB&5>GCvz?Y{as#k}d6N#H4zL27-V&S7%E)q(y> zxFT4BJn2UPwao*yAF>2KKBsMMwSAd?9Ty1$By~%Ge7+px)7g;K-oh&hnT%_MeQ5^u zOuu=?W{pqM1>-*GS809H2$(CMT~U4H?oay@n?5FqI_y{Xknp815rS8AIB@&`A)*?%2`mJSu>*skXCC zu8lcWVaNdG_js0tP{>xnaKO4FhSR3O)XtYsyRh%{WeZ<~&gbazEI=s%i}j%RkCt%J zl%z90I-=+DiuBDUxe{J< zl@}cchgM%(qcx+>d1y*%A7;=CSGr)le%3sexGV1YiY}y!_d4VbVb>1pW+}6pBY~!? zZv@btFR!F}Um+Vy{!qtr3^OeV+q?-jy^?ygPI%(49r)!U8+z`;#ZKomC@RLj{idu$ zKSQ6a$@R5-{9>{|;NmH~eSzdHr}S#~;(H^_K?hrX@GSCtx2}5cjq)oNi@As@fFD=R zUNxT$PEbBXaB&(*&EWn}u1_g}B03FbA|Wlp%}Csj4du#2-Oi|LSXJbUx&201VY3E2 z)q$IkAIRDgVHcH=Rk*-!<#!9Ns63Mn?wX_N=dq-w&#R4EzT?C;4~xFi&^QZ`{3zb( zOxrOmVx*G0*?XWi!|U{|Q_1LZ;c~HVRpHj~!f0FIZ;Yf^6w6imh;9z^||^b1EYDjfu@FX>mY zk19l1<-#$#5}XE%Ub~ay`%{8G^rbPV2H`Ak+Oo#KIIYYVWvk%L{R z%C9Q%T0*=h;We7J)>y2oiCe2LL8{_^+Q>AUA*wAdwSBRa>id21W~tSd^!xBP{URW^yG_+NvfkaGm+*8tY;QTGXdME>TW!_Vp_H0jl~@;z7uOZgcJ|{Rup4=D zD=6sdXrJFUHg~bft2X@OY1@inSU}gk)8xizdZ4{=4}9mBLnfr4B%)a1=EmFPV~ew0 zwFfRE9`G64WH8?7@a}nqEgAMae#bb=cts+#A?p>kG`b&58rd zZ8VSPl8M3)!D+laTWu*KbGZ!rcR*0A0RLbbaiI1V$7`x*T=6@@?V96K&pQoo(#1F1 z-vsQ+^j9O*NlynvZ2`-GR<=8gKC?ltdemHv4UWaC1WJXR)V0hJ%Mm}qR-Y!k&C2vP zkcLwrhT+DZ||3mo{zeBtnGU#Pl^^Obg~r(lP!} zy89kM42;Q9bZ7g|w%J9zsc3q!d^Oe4|# z6Eu{kOJR@sRi*>R2{#%ZfgLf{=$C-fJ%j`Sbkf@(A8&llwpb)xEk`3@ok&dp{1yU~ zyLsJFcZeAQX|l`4lO4>+ecP3noEN_T6Uc_R^Vt1~&F`rN!=*#N%S@_veT1__$U~#}SsxeLGnivwcwu=i#4iLwRXxfIp{-jMV3K z{`wkt8HT(X{3=gVr07$~l#+W!sR?X~{8Oj|e$ZaH%ONBennMXuc)=*VqzO^^o`IQp zcDUo3DH!=u+8*sKe1%(wc&012p&O&0-ox(0PF=}jDU&BmW(iHjy2+CBW+^v`9UF;6 z1`~}96}=Ft2>gSWa3TxRiScf>fzs6x(iQweu!XrlYN=%x13$uK81F9N4pR+<5Y7{E zwsQkhliLlD19nTsXwyBxxYHrPx!+48&3nLSGKbsd^Te9RmRIzNy?aLT%aS@#z9NvM znP&<1V+H*Rcg8@bN9(LA9z`rbOPM2>q@BEsd*IZsj*L>N$+M)oOaedyU_wM)Ew*71 zUuvCOv)6kW_VUGe8JWw)f(-nYZ1x5iXa!(0qRQ8pbbSQ9>#)%0$nZ);j9dD%`ihD0 zcO}>NjbWCJ(c%7UmtTk(4W5t3>zdQjq!atiBOKnvl0HIak%lV{%EZc)!$RS)4Gf&6 zX@+Zo-a-x%xq1FrTWm1M(8_GX3+XHsIOcq2^MEsfNMRiwN`|VeZQ0E&y7IWMUIjS~iis^E5%0_33;>k9nOh*)^ zVM@uKUOUA+=?6T<3Xs|Pg|2R*vxfEi7`xh*xCqUjCi^+g!rwa3?jkljUX+5Vl619af?7@R^K(Hy+h68!C)DZ^LTtU(klmkDNT9+EHX`BP8St9EJkRt@a zj6`SJiRH<*Zx*6XEog#Ja4ao&B=P_U$$;VaMe$)^aN_uG;^>q z2@`3w{&r(3^ z9KwY`*pN}2L`7`IR8l*51MGbSmg`yKKPe|-@oe%DC(Y+UjV!WSk5Xr%58E_IAQJa> z&gke5BCT{RT&Sn09X5r6${>GA$=Gt^ost=y8_gqmGGKWvFA^HQ-)FuhR>c8x31Y_j z9J(ZL>wmMLqzpby8?hPbK^UHkKwrLDR*hDMD4`c)VROxRz{OuQ7~H__K0EK2cgyd2 zCf$C3F?PdChAjLBNem($3H5f0#}vq)!WuZz3_ouo1;Uxiw@vnxA|NYm3&!topq#9H z$h(_)XyqCS`CVeUpZQbi}n19gqg@B-_Ia~{8?T2&9bCwpVl!NI#_ zSi_FT$BnhXLFY8EF0KhjKL&i*YyQ_la~97nf;3uASG$+z5VfNXp2%OeXN=G~)Wv8u zbTQR8f#t1h=a3P~Ne-F(Vbo&f* zh|6eBDPZIIlM|-d6xN|z#_r0EKqX;pTDwL>R+?%ElT8A04r5Vz0O0^`vtg;wHI=EO z-SiVA3MREQFa-Vk%J8<*ESbuTP?y|HO_g1oKwZNy4KnckH4q)~w75YZv0|E;B?DZO zTe^0-L3d5?hipOw_GLFcW}J)+o=WdbFV~2%f%~CW!jb^8zHuzwoGihC{6Xw`(X>jM z*MK8C(gi0NEVV4&RKWsKgCFrI^lO`D2Lsktxz{L8O_=e0&r7pFBgmwq4ekku4xDzT z$8bC4y=V3rBZ54QxK>1&kQs_sYz~9_q-3`V18xxoAxT#0N50CjZjD=)3iYRHM81;o@-q=aj51FcVmbCXoZht_7MdZZF6#srKd-5jh*UXy475`+=Ybg4Ur&d z$SF@~v@3VIJdZXJF*z~VHnGGh+j1_#N{5bY@iQe9u>m&B0t5_I zA!jk5k36e0ezI3*7a}p4gYJg?_;X7kKl%i0Gy5TsR%z>uZc=JzqliFI z6lml#hSjfVl-T{dU>??)N|4jjC$9Gm{cq}Q=Of!cb5dOaaw%Z0rW=NC9thJ^(yc3gQG;4Dol56hTglkIY8Yw2} zuw*~ASF-nBAu8irhjAvj>P@u)gC?9HCe+C#Ip=G!GCkHKp~Y8Yq`hLxE4>)ulM8Zj zqS+63Y)e-jW*7KNtZJgz_^GV;7i2(QC}@d`#ZqUm?<5isz1|le_CeSV^^>VVVqbSW zXEnsRwWQdZ-PScAO{a9sc`Gq+E^K2qh&uZkv^^j7d*9D(Q3Fl?lCwwzR{O9A>-}ME zcXv6r@EP+fOid`4%d%eenqnQ!K+?;%C1dR{1(0YQJ@m>dB_xx7m_u>qm@1h$Y+3oJ z-MkMLUt-93#yLKhG}C1nNVF?^)=InE-y%t(#-f#BY3&2#e68%OFd*%JQMCVcnIS^c zmFB0^Fzx3g^{Dunu3(p!b1{W&$`nc#?eiJczrq6>T|Mf66Cpes#$3xjA4^pet=}U{ z#_Q+*^?o}=+5+hlr|rrT9?LHwWcYgLDMJx}iiJv{2z)|df-sdinwz_l_(I*6aRQvtiEXI>&=-ZuLAMMT4JiqvWMbRWy{RFS!Hj3({Gv%k70YSD9FX z7Do{}fB&12bxj9oNx%Xi337SDvj|&4wKZ?%&-!c->Vf;Y{M*kbiTlpt%Y{}72fs(+gTSDbk-f)uR z7DtoVVQeW|K5GgVJwBVSPck#+oF|Kj_!4JLctDtmdM1g8ge<^;Uud_W)<0o=%G31lhj!RUs(kE0t{>>grQ74dJko=dQSo311AMS3SQFbI$9hdshJaGicI{y!KelqT z_yM=F3+#eZZ05p`+~yJ3i+m6CH^_UgzPp}$Ts)J0naut!a4f$go{RPu;QaamH)i`5 zk1Uke7RT4VitSWJ^4)DQq3^kFo@F~@SSdmGGtt0EIooop*fG+j5jK=t7q9BJj9E_{ zo72GewYk78U}xjn@~hafb&Y)=UOm0gZQy0oZ1LXwTSqu1^IRAGI0a`$iy{?VEKad$B-{Q-!I&wn5P z?sLknZ2q($4SebGu>a>eVQY*2TK|Uzn)vPdK6HQ8RCoGS_x*hGr)Bz7-u_8H#RI4Z zlM(&_p)e;O2XTCfkPn=|HZUOmMM?uZk9-)jCR_;>G5#HdVn)w$R3>$%Da|@kJ`-Xz zZL!}f8tsQsA31peh4b2X7#GeQ+g%<6=V<|)(i<%kKM>4GB4$LW_8LKRhH_bk)A4FV z{6VQA^UCOhatdPp4G#eD{S6H8-^onHmL^S`-F->sMf z38(8%z-ev>EfxcP1=6y@zXPSwY1dU*Lywaz#onF0csMW=5ecob5kQizu2ac-4@f8d z0e}MmpJ3g0Tip@*y*0bxqrXka(vl=1l_ZsyqTdji)6#y^6EP7nF+EiDyw}5M<#bUz z4=j~#UASz}+OtBId|B~XeSh3-w^_FA59-Qp5$JdpJQtw1d|y9(f9dOoHl*?2T^H|} zG(4(BAd|-iqPOI>srsB$e;k!|MX0&wVZYyPjq7^d=`yuJuWU!^w@F{LL%R5jcSZe5 z48$PhyNL{+K~uVSUc#45DV2792KfDLXLEl>xZWv0|>$zfQn|DeBSt91f&~j zODZGX&nBS6?yNenS`ic<-NCK47QSqx9;vHB6y;q)|L{xyAkw;F|C8^A|mU|-n zN28D35yokXRg5K#_c0KWzYWl~Ks5PFO&w6iGiTB3pK3KL?N+c_zEAG6-K%_^v3!$k zRrsC1mgV>6bv41#YvSQ7j`v3jg=0*xEu*u9uLr{EwS_UB5X5}f)_ING0lQYg#z8G_ z*6x4;lPmfBuTZ&fgmC%p zk#hn{(M`$rxLy({wf@+35*?t0t6~hB*uPAupgWpWUC}bUW8oiVPnKh zcAB#)P^M-`);-?g$)NC=hy%&r3~2&$ zHEMtOsX=4u_<4Gv!@oRy?mL?jL!9X~a|ti(5*)rAVW@F9L#C$C1ufwAmVo=VJF#ZkKTDfXtVBz z@Kyh)n_20b-Q;YnQ@}6DHtCKY{kuyJZ7$lJi(v)WWtsWK;sel7BVPbl@B}2$$3OC; zC*w4Xml|fE712Cuhw}9ccsK(*8MRa>RqP7&^7vUTfLSU>R&jIRgd zqC+Cb!)VTZ?+`-o(r_^wfzm3{BZJkgmD_y~b%J9Z8Ge3mJ z;@#4ny>Gy+f!-V|9V=r-yRgwbN{zd|!Vy_!o~+E%7*W^NLYJIwGaAMdi;iZZ2`aPX^U zRmZ;SP?FcoYXcg!PL$E0)Uo+*ZKfJ|ec=8Jk)S@e?gCVOQIbxjTq&VFB$Sv>5D*){ zRiop{t!g&HDWnXGBnaLqe)ry=HaLHxWt7K+wyU!eM4sZN)kveH8^QS&3DHj1Wy|Rc~IZu;<9OFpQ9sFd;iYWMPN4 zENzv$y0#*J7`wA=9ldc%KK4&{a2D|#aPp@X$Al(^qe5w)7C^c7&1uQ<*VRmyw|>d? zEHJb%meVA;b@g8`&BQg4vC%wX6`@YtyT6^gxkTc`R^2RqvXpz|yBzXZb5H|Uoq3V5 zQ`iIMQ`oSj?-f_Q<@?6K-mWkPO{)US4glWyj2VF>DEZ_{IL<)Syf6JuMdxi`yL4S8 zJ5M{iJ7OjuUfk5B`^F9ZPtep9{C3#XFzv4`h-$f)_&OC$9mqdnRXRLu7=WVb!7`#| z^g+zBvG;0~t_pQ-^maOQ=wkk0oqMnBgMpQtuLK_YDeF@({g_mvG*eE>b?F4$zOHKp z>CLohA8%SA2kQweqkv>vg8Q1w{O~2csL@n+9)K2jLBg(-NUfVymQwWoL<9;lut?qZ z)TSV2Of(Vkyq55P-WP=H^aMlU&*Hy|g8IuuZd9C4DG$aHha{n{Ao)6z#2ut$kkY94 zc`zWrFQN*+?QQYOhy{Jr7L!6h0T6W&bIlofFM`r?lr1sV75~nOp2!d6eg@J@x^km< zOq>^KCO_DRE38#o+&WM-^GZWQVWd^IM7E{L_f-}3WA0)PX1%=a%iuDG;5wkLr4vD} zHsNmrp&JJ23?6VY&;;61MVKiDl6vYFaV0h>Nus z@yC0dYfSE_Q}0{E4br^dGIw@xx3n8J=Gd z*a|j$2NkcQlOxYJ7g)-I8nIM`mUrPDLoNwD)RUzDp|`LTZ$NtjCoSXm$oq0Tm$oHM zDqz(wM&lbuc!kN~Te9Ty35f8l?g7nKne;ME~yskF_Yyy-(?r75hGO~z-NAkDPf7Y#M3 zTe3){J0sc~n*}8ao_6j_qf6wsKv^mgnHy$B!=R=V05B1m*fb7n5M^6j@|@QdW*}(0 zLvEn7I52MkCO1}e3feum99C$O*2#IP3gg-1DVO7e z%$1h+Yh_)E@;GKX0cfZUbNG{_*VKTI?o-IJ3khzd-;=iK?pky+bHe*^zKHBckb%hE zM~*-z-xI%LEq*m2CvTQGS|*YWVbF=QXNb#F`M5lT+dIEl+p9`0LRvSLe;~{=6BFAbh@z{!-GE*wCD^B&Q z%O!NG*{DUi%K9qp!nNf+-R_0}_l1|d>cPb99#&1VVW~|H_Sq0=W0Za^ceY~T_18nS zW7sj-3wT?z^=mY=<^JAzK{KB1yu6yl8EblR_E61Qb4blyqCz_UgSmo{;CQo6-uef% zqAIi7`u6tnI5-Eedp!oY0|RpwyQ)p2i8Y@78S_u^G5NAS)bv8T^6OIV6qLVxk(u}M zd|$6(xD3WlbV)e(mza17s`!OCQ*@oHT?LdtN4PHS1BB+G=4KHS+qJRN!s|F`SFO0G z&t?iN!J{o60a6_%_!3-D=KZ(e1`CKD@2qjxdeJVdUk?$k3JkgWw2eUGvK_CduKpY!)$ z_tS$WvLUJTa9-6f!96(6RZ>U2KAf~L{ zE51YOGNjTh*)b_|&3-9~(qKk{O%9>mF|cdgw1wmY(6TiA&6*I*X+BnCZm_EklP@I) zM>xby%`ilnU`42)b*vxACQDhLNIAh$b(z;;?(9B_MlLc}Z`CZ3#u6Fp`aOj|HrRf- z`8@r{^7e1EgWJsvyTb(xbsWsQ0dA{AVRG5iV`d0)nEJ-Bm1y2ySxJhJSlZ+|GC2kR!NHVF3ur?}N ztQ&K#-jf&4N>@NS7c&)%0kA468~k~os0Tx*q4z836^gBC%KEHYsQItwrzO)lv-gwA z+NCsDwno*xwLDn#Konfl`^-5ta^BT{oWj^P7d&0HT@)6b#k8~F4S$Bn#$ES)C62!T zJ?x)Vr_M^e`fJ`BWSC);B~+7IzeTkvna$Q=WD~-rm^I5bY)w-gYQbQ- z)T9E*2HM-sxnd%lfW3&p5r!dDP9t%Aw>sE2=j0JtJ-EtD{@h9z!3PJSTb+1( zVoYr%<1aMTPYRK>*|3%)l#{(kl204(y7K?X9VI?%?lI~G4RgzK_br{DORk-($a47H z71DS-T=~6tos!V2IeS%=%sV;pk$D!AWDy0SpNIP90Un#{ly9=M!*#PelO4=hr)|^@eFUzL-`jGm?ec=`^aWMxYOY)1fS(Mj7?HBX zR$}-MZ*@cB9rrzS;)d;esrJ@lKy{FLahl(B4}0RXeQZl_w!}5$)?3Q>1`p8|bdHN_ zU!~8J6?Bdi#bNF>B-6yMr^8f~&N4CWBI(tu zEm%omulJDB^7WcHU)rc~>o!vZ9r8rV%0R+GO(;bLk4}m%6og39Jx_Puh&ZvQ;c@RhsE$ zDjooGqYXe9?tH6)=M0D7UujK#w|K2fi{R>(8Dg}~F&nrB%evkRcB}kvFM8XP&sWb= zrlCuzp+7$u*G3vzN&&qbC9-DxH3s$q7(UO%JHR=CmTI+oG*v6(YCIf)l-IG-ud7); zK)8U9p&AYdVg=7Pe*U5U6E#qskb5>gstMZLj7#yAu9>O?%B$x$vIFdf?TOmMmU5b8lU@&f6O@NYRWvfy8lCO?NE9^!MREsr{M|H5t zw3hQc8!~@Iu`5OuyRl8El=oYrsZHAkEnd_r#8vB+Oeo3}OKs;KGeo`2t5PLnC~Y`N zt(ou9ZZX+}J)Pfbt|LD6tLF!O*zr6sZ7`(Z_!akTbyB-`T%$f|P_^#Ec)ZgJMH#Yf&PL%7Tn5smn7d z2g|%OJMz^ zUvtRq@*UWncx@@t80V31#uTpD_d(NMMW3^TJwW$^w*q0nXuKx<$fW9*<*)(dril6S zXqIerCI1nIa)`TNmar1>U$@kDvZ*68t*$B%z8GV^tiW!9PL-vLLrY4p)X-}BJoJ4& z=ywKgC|c4S?`Pcrsc(KQ#EWo|&{#@$N>no*3B9;0Aso1G09$17CR5+qyZL1=QElTV zeRK7>(c-Ba6

7>J!*u)&YcvY`btgRJBP`e-Gs38G1W`dP}d~J3+mnypj5Pd<5kI zrEo%85~Ne6TRo+-nYNvs3oH9zS-vl(>7z;7ceWt!(!^+vwqJ{5>&?R_Z_a!1BFsYa z&e%R&5wHf|WpDqCzN;gsSK_^5w>!4rji0EpZ};m{T%56#t_E$v>i$sgz9h0t&5|H1 zx6qyi)_s`W&8+pZ44^khdM$XG9}Y$TBL0itS@y6$Y@RG{+7bjez`@v(e;NSyv$$&6 zABrAfASJWpVou9xklxnYd}Rny;J+3?cWQl9k0Hq85pCb_bUfIzlGNt-I}}|*V=oGB zKQY9WM)tTrEbR?>&FggNL)o&)uh`mf>cIJcvk!dmyg#g-!rskAgk3y*BHkeV)2WnN z#AlqEj~C0}Pa`q`%)Gw<5;TIMxG>`6eP3-V`ulW<%C+}#qpYyH0MFix8Q|Q*w5xX%;D!ci_HFEV483QXnxIy33Fx$$P!vv+)0KSF0FE@R$L$iCie;?d# z?er+0&#n6PcH_z}YkgH)DBG^!H$@jPve%vP2#DFd0%&2#LB?srk7~>4l3E3Gud?zS z&14_nCh5DS4=7KIckTIl==2vW(mrcIa+wP7i=K>6SFF6{?BZ=xekkvG>5TrK8*7LbD5^nHQ4@)eNXlD{fIHWK!lE*ByEzoTz$t*= zw7xXpEHowwt}U%8B+rBVSOY*i$;6#|gas=wv526%zMoqXakJZg>y@rNf?j-v`|1=; zc55o6_~#_}h7~8kQg@8Y_YIWW9K2g+p!cQc`;OnL^cW8LeDbyn7bemP6+1!dVJv6@EjC}VP5X{>byjN!c4O^2H=WH`X&FF;kBG{40$Q!tcJD z&7apt4Rnmju3b|#%){<}wyxoZr>L!NuiOD9S(yM7r|n zDJKZ<;**lR1X)b4X?;0>xYy966kQ`TZ6$=U1~hB(nI{zKN>a4k(yLoCw_Xe>q5&Tj zB6>@Jyr>BL(;>~c{7w$MoCghJXEl{y%Tc4jZma4lSFRXnr=^Yt`rO~e<kEWIC90Dv zY-CcxSSu4VPsZX_h-)aT>H~0Xe_Tu2C!mP}_ckjVFapQP9g2CfT9|9r#c#JQI(&y4#Fo zn6`guwD-UU-IY}FnUuD?$9^!Or$)+|1X|JUMZq$XI?Im^MteQG7t!T#r8sc#z~cLo zx^gofQvad1AS)#Y?O=Er4#d*1{I+lWQYQ(vqYd$-6M;$w-=7yzwWB;LC!nbsIgG$R zzb^Hn&p}tg1?WWR5(a#p)Sc0j*gjxq6yW25Uf$SyZ1-_0ZIYWtg zeR!~n#FtJ4BK8&UjM{9l#mJXs;U&D7*duN9ztdZ&1~7>v1iz=Vp=sDzw=VI$=Mq#K zzdTk(s;5;$^0$kL4)_e`y4HtNx8qA!q{?KLCSsI1y`P3H&5o9G6P={bf4-a&<6hM( zZE}8NzkUHqYKA@yx3No%hn1~-`w^6#HS3*-153&h{a8T@SyYl&xN7O!OH5LY&G)So z6;)8GQQu<3!VSDz)yh?{WXLq@#n>u&@WmhP9g#$(jQ$=Gwcjn~t>m+4uv965R?3fQ zEvj0Ge~^3ziQlQ5MJsA2rd*yV>xv`v09AKlD|FJO5^q68wmQKAuhg~=0Y!+GC41tP zCXkxe2~6P1Dhi2U7jBden4LBa|CIQq+9+V1d@HRJqtuU z8fp!L!af$pOARq#?_Zei^7U5N+Hwee|4~vdNpJ z$|;XkPQwSH`P;3eZwna8cRkMU z%H3{Sz6VW|Ii^x~soe(H;fJF=!=Uw}&r&XW1r}$m)x+1}AgY{O4if+-U@Or9H$CS? z8>7HdpwHTA+8X%P;L5CD)8Q|+Mkt?Caz~ldss|N`7t5`|hYYLo=J^C>HJrk7J8sf7 z2au$%WDlUl(k^#1-d?@(e&?X{Y}6Ha9h+G1a1LuApSeh*Tk~?TS7?^)1-uocjI~T4 zHUnn#z7<3}@WL;osK_BdxJ7-KUH4oxhoSiHb+W|YQ(K{+EYVXnW^NQ|#UL8NJW=|+ ziRO^qbl7A;8cN058F3BW~wccQh`ystS~&oAfb)43|wYB zO}7z5tIk+kRTQI-G>fzo)xdXO>Wg4Hd1k5|cSMD0Voh;ijErbC~Nn_jS&Jk3v>pjY_5m!)>R|?B5-+IS8-b z&oT^Tj?~JSsmKaF0OBuQ;ki$)@*}d;^T*Zi-c0YXimYw?z~QgPc{GP(!Qk5^7`BAG z;vKq18?C0S-~?)rcKH=RlM<0-Uu9d;Jrp85g8xu@h-umBa8E2$jT_u}-3s)#r0SC@7Oc0+H zvFaO;lqOR`p9!s{t}*4U5H6hNNeX!!3RYt-syc6cLN6w+BXq< zq8k>RqKI^5V9~r*+(d8ByB=jrb!N9#e>GYwkO!lFG6~Q*_&D?s>kz&hFnX+TJ{w&A zx;X@TEM(AnuOC0&rb}kG<&L=Ed~6SM`9QnfBh*OWb`ewzt&5Mcr3gkCcujSS4C`xtVZ@Q?PO{)rlEh zC$7H4Bux%;4f%3dt}CqrlE4`N2>55+0<^7D$U9Ds7G6Hhb6>KX-ceD8Et_S^5!xz> zWJ@tjfICFXJ1fDlcun`Y>$sRLe(kjPVk3RGy zi$~b!kmq&51Q0P(u7#dHcOI(k^E#KmRpgt}x26?6T(PpVCxp+&T=43@i$WlJ++o58~kRNrhB&Z1IpRsk+aTa4?&LY%Uj|TeSzo9lm#1(24=2zX1E+nwfh~<*6dA$EXM>Q$_-Y&$OE}9p0~8TD z_$j4%b4A!wpUH_KyKTLWhWEpljRd!5t5zi|SI#o(-Ar)Ex0$Y$=If0jn?M62bvQ(jYPh`2mgr6ujmU)q;QS^#+=REAWQEh#uSd3O+xw#T7UqFrDhgRs&*s_WhaEn2 zYO3yZBNQb@d`yV?d=ViJ3x8P?5dA|09!b2299_6+x*wA_z})UV*!&MI8V48~zeg)zQOFB*Lus*Y-Ptvc#Y|1LLf- zx=SzqIzgNxkUQ&+00bnwHsM-!NQNqsVCUfpJXSzQSeY8RyjSYYQhugs>P`ZW*%>&h zG(%!B3M;I6_C#}V$juT^lBo?oVCzK;7H@C{ekQ0P*YICKtG|vI0;4kZ5VcXnP&n+* zy5S0nj#SMZVU^1UG{Syh^<^n6G&%l4^=12Sfk5uiG?Hfo8V7M;; zf)?aD#@V~2(fkr~(E||2`jJo11o;;=S``jQigW8(a&zqnU~qH~g47=hkRHcv3|?ILl6D}v+M1a{y0&Hos}39a!fp3gaC1cVRKO4y$}$>Z6>_#_n1|pLd2SK+%o3^# zq}crqWAZIz+C3C*>?S>kxIpdpho{EBkFZORQrgNwI-0%3gMUoEVer-n?$rN6@x98))tVONd1cujhxxDRYC_;9MXdzx8@J@cvZ=);%jy+s#s~agQSAeB3`Jyz_^w4*E;7*UbR!*Z8p^f>l zawEq6<~u}4ikMzR*MKm|Ov4|lE!L8-ml-3vVu>;^m8B@x$6aL6-;F#pys`4w=m8o? zJ%1Gd^oRNo?{OL5gAs=Z#rFgGO7rY%TDbEXBfXJwP)Cjv7v~_6+5;3HU?O?s zxO}7#MD!1OgFEXzFLCkTV|dwKN_GgyL#j}6XnkK8o%)UdTe|lyss$ddlAeo*`2PPFP?+pF5*4{TOWL=D7%kqF@Jz>0#1hfI!VcnV87yJ%nZh4RwQH3FvLwe0RN#Ig$?No{Qpo;0fA`$ zrJMdRP5}r3^oE&W$bX*wb3*)M`me**($>_))4^0h`X3Yu0NB4igaB>55^$w}001Ch z001!mg^>MeIh(q;SlXHYOJ)6EWMD)C)76hpFAx9#>VF~ee=M@1DuT3bPjgr|2yXY3J?9?4zzv$ONQuwf&WYL{l7qp^#7Og Ys~`>fGnW7W;6IPlpP8)~{HOK*0WS>HnE(I) diff --git a/docs/en/Em002-4.1 Checklist OSS Community.odt b/docs/en/Em002-4.1 Checklist OSS Community.odt deleted file mode 100644 index c455d3690f605f5011bcbe72ac60d4b7f3d77548..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 52751 zcmZU)19V(p^e;ZK)!4Ren~mAnwr#U<+SsM5+3xwzeqs_qil%Oz>EJLu)xFK+TPsF+sWM6$;r;z)Y#41(Sg~+!Hmh# z*wxyV$&yHFtBf zcCd71^0K#!Q~#|r#DdyQevOjMTjoFuV}sW29D?r`WXoR@PMo}KKe*lGytbE5_M9T_ zVL{x)AK-&qU6DW+^iWG$HIkw}0mt03&UtXV-x5H9DRD``y;Tw6M^C~$-Nya3*SbC;--gOP-3A#_Dj6+yLF^m0mKEOd3uFSGUdjf$_;ie5WXfIz8 ztaL&XbyjKMew?8$Dp&7CO?3<%gW5g%y{;eK;PV_kSEPLx3BAtovkS4yXD`om*Wmc1 zWZn7d&N~80?w(;lpwCYT(EocygQJ_+E`XKn2M2*Lf$xfv>Y|LYN>a@B#tzmN=B{r4 zEp2s*sKXEms^nvu56tk^%sCkbf7g$E!G73LrZ0$NaYauLBk4biV`XX%Hv9d0KC^b+ zdPhiVd9d=z(_rpNp;8q8%+E~JP0PEc7P2ITCc*0QnkFAzzF%Mj`z3}?X-3Hvx(K(r z;Ehwz^x}j>jns3}l6RPuMGYUeZ82>(htHVp{L{2~ZcjKC;1D>< zMsY#j0$)Blrsr*eR-W#SxgJ&h+?=4=!;@I-W>&y1G+6u0$I69B?YOnYuT|fP ze7NT-d@9}AJPb8svbq{QzAKdFETw*5V<=Nq(5T>}&!Npqs^DMo);m3Y33&GC`f2xW z5H##8aAB!$dF9G1v7jjZkN@tjz0J6S&b+-w(WfH3BB!%H?*&y+mSy12`_9qY*!~H5 zvMKGCD*KALdCpOyLiD{!ExB(QoedMu&DuP-K0OZf_Wu$F@{FCSsWiyrwzS6#UzDn( zE)YVRztdmHm=j^xJy*JUt-ozzeSWB=S7zVQJz~1YVK1 zT*@GRq@ecML=XR@(fIBY3XvG$iL;+?SMbtF);@8ym)!rpp;T<2DyoXvsXBK;->{y? z{^;TyaDN|iRQZNCCpN)jLIZCeXGMXtC*~sIoQa+b6Ha%vJRfsZlHy>aSOq=izZuH? zDlQD(ru;w%Ie+1T2p54NfqRWkKuv+?+MRemag{MqYvbfG+qC;mB}B3(Jr6ZDZEYM7tbZM>9)k*V!m3}XiTnScm;X7#z0u~8W9tE=wbYqe$i^B}bW+i#^BKT~V}4+kt)%nDHq1F<)Qeeg^#j3tYJhK%;|x+dry*=S5W` zfy>0k5J*=wxHJh!lWm8 z@x}@s`0|LTi?mJfrot>BP-~B~#KmeAmtWC3y<%XJOeRUQBU(!FWV{G_8F|CM(W@NX>GzZ*vF`jl;kKPVqg}J;yX*flhS@1booVe=@>v#Q%?e`G4VtvZZP3ksAo~ z-vbr+3wv`jYhz|>dt*y;RwgG0%V=dKX(V{O|Na3*4YGM9vV>}PM8hzSof82cKr^BT<`hls!7KMfeL5GuM28{?CrK6(4azrrj1O4#F zh=RJxa8S&yU(=&aOyMK6%4}$EZqcf`mX?-wi_KEy>FKFOAbPLgv%0EkTHukXG1x|- zrJ7_@We#^t^MVGENz!P47Q5xx_1|^Mo4pZ)*^>TxWAP3JTZ9ew|xNKM4r^{Qaw|8S(^uW9BC&l9LM$}Q?1Gq?m1S;e zsi&udg^5Wk2KV&#%pUM~v2N*TDK7*{Lv5%r=bQ9sPKJmB5CnRMz6o$Y3^1nbx{~xwoCYH$`PvgxLt6lKiRptp=sFmFxQYy0(_d z!-MN!|M*xW0r+}zyMbae0unVC3m0WWtIfu8}hv*KZ>G3(>kgs8NMf4hQtKP*Wt z@Q~Cd8(LqExZ~BLg;5rN#)5xcYr)iSx!xJ@pDlsp*212>=Zqr~Od(jn34m;2dsn== zzD`I?3{@Hu6*5wGK`r>A^n+&r90Y?xWVPBj(quWkBgNwA$ZP{r35B7r<%ZqPI|)Sn zoKO%KlvrjSezfGHqVhSODHwCJs}>pR?{v2vA2{O}3P(5+7w^(iSD&#~QbOkKh3ISY z@q4~1INj>0?0U}I?xoBtjkBo6P9@lLXKBcxXFW@!*BUD$#o=`cJ5~*96AL7WQLtS; zP@QZZY_*_aq#a;p>#?4f($mvZQ$zo;wxaEMu_o!P?-c3r5Bb+me$O$>;i%p9R{K!l zpWromU9n71PS)outX5zCZS~AA%{8~SPH0&1+I^v>miF}IMn~Vjx)Q>`ajI`a*EcDx zinq>}k#}lh<51+FS5Fg;F3!P&lpP8h6+JpQq(mauHenqagBDv9o!T}ii z+abi%V6^I2yf6(P=B)6b51xM$%Y7l3pkl8sjnw0l1>!sYG&c~eYvwf`t!4~ zu~B=>cDWXbnDxg-|NHA;Ke$$WTwG;kCC7r~AA8u|+!LxOVUBrjhi};Wi#xI}!~@Ih zNcf;WLO#f;-;-v1NT%7f;Hl9}fe=WF$=^4Eg79^uFuSpMf5|R=a?^W6~QI%ZKxD1ngd~Ym=K|*>-uu@_xCYKMfbNMP-M&zTQ3y2G(BXE=+S+?j5z8YcKCxo zj6p90w*IFa4c}0UtxUy8D1Nwng*c`oXlW_E@a$io=#){4(oep@&EB8Xc+A;!h!;(k z;nI1VU6FAFviF;lzO-^@jM=tdZ$(2>P{%jJLnAeVm|0u|`#uE>5kjR7(K#I*2* zV^=ocF+S>E!*#@SXKy67Fm`DFSE9sn9x`Ug2Qn%Os)?!Twfq6XcicX+v!uT{EItd3 z=D&C9)fkSPTrtZ{f2T95s0{9lXU@SYczg^ubG(83_;g-D8jBvvot9k(rI$hr?BcLdz#|vSSA!$saU>Ctl5Sq%1g}eK6%{%|BB=>; zb7!>k(9*)C*qqS{lxZFw&&*u9on9;wVbLr~k5*?*=Vc6_Rqq^w0);ah1cwGu8DCgM zP;WDs&8Tc`5%eX2n|~#5`gXQlx83cHjttHhcfAkAG|ITOHCT-Whj&6o$K$ZkE}GEa zAEZ@hFkozF7PeiZ*G6_^W5c-X;Kq@VZ|;ZLr!<4p9m9kyoj`!5ACF|itq2oOZe;=z zV-DA`u(uC4oNgt0lJte#>I;Nut38@|02O5fP!%-lT?#IcF^{6nrELd zj2lJckocaODdREn_Ix`los6k4FQP8cnA+352A~YA1R;N)qoX5!e*OVLud94hX((A> z9?X<u`B}u=n{`E{(6hYREAmgSwAd z-_5MdtZi&-gAx6jCq#H@h?rFrh-QO;H#+k>gP2&bveQ*soBw_1qpZ<#5R!u%n{uCj z1`*?_SzKi5DlFmD+wy~^fvrweftL%?jE$SGpQy0Pn56b|wY;i+vhR<%ush)x&*peg zisO3g#pu26*W(pCsr@~mdlt&WIXgE*(B~qoZ&2RBbend)}3+T%jN%hZu{Hj{@E6=xBRDpWX6LzZ0~o)cY)fahrpF zoBjGkGry1$P84`?AAmswJkDuWDMm-7va(zqH`){4>{jXviuQt)g8DvzVsYjl6#{CD zLye&~B%00kPyuqiFHl%XUQP}bF5bu)o9+v;C3P7vy9R=18EOZ2&(1;zQw}fJ+m=U0 zaQ7L+#UWD37#T4MTj*$~G4s;sxy8f zK@ibI)aw?UpkQ}Tv!mYuqpvLBo$51%PY@vI(Jr$%wQrN z>o64yOf^DN%wJ|=#_gN^)*ExX@BL{wzVW!A&mHWz3L_hBo{&EtZoW6lMl4y9Qa{$@ zlWEYkb(^in1rKL?>}6u53$;>sk=SGM(6quhM7Gb*lqWc@Z%$|vDs5miSpXPEQi)t+Vq_=HRv#HPHSzKB8rBucULg??d;(n_Ct`DuKL`kq_2UKy z#oki-Vw>tiY&%SX>TNTOvgS0v86(S}w9K}|Cdvb(M{b({>}&D{4r8}M>}`72MfwNp zdahc2!mz!?>r2w$R9JM&DN zIRB|pPHDdL`}MIqivAI<$^sus*d+b^GD$A$YIpECCN67F7Q)Eb0a`vZouUfTj&}B5 zU)g%Je0Zrw53Rl7;g1zVdHM~vC|L*;LL&g}5%5j7y1jWytfc}2h2Q2>z1B!e%gf8f zBT0VDRqg&tB#xvMiA6Qmo#7+d=`m@j>)gAb=jPVZMrOg!74iocZ@2tfAYNJ`RnK}Q zkDSdTE%P=vN&Oc!+CWRdCJ5qiX0b|ZS4mE8n3*vpWa{I)MJk@?#8~t3p3|Ebqi+^N zM>=En>yww~$wssVAsmiGKf91nf{qIo)*()45R>?G8PBJ8g16; zoeJ%$ zu+2wg^Q8|fp2WOS0r%m2Rnc+BYzo^zlam##^vuXKzX%wTTpQ8R(aIb+uHuoS`>C4D z07fMw6kN5R*?4>N<1rEdP?$tLD+eUL>2mGQrx98^VDAqa57`(f{}AMdfQA^{uPiI8 zw?gXx-*G)X7zfsM{#AfSqhsaKvIwo10XGdbvq!+oDW0-ysZmlv;jZ1;)XR5uW(+mA z>Bx*l{?F1_d^tJSD|)TkVoCyZ>e9`=K$H)K z3E<}6-eV2|P--qySzj@!F@Rn$j)?Rx_17>tzCeR-su2CdrN#!4B*p@8A``5$v+acY zJ<^H8o{<0`P^fYYWDQXH_sAT{@YgVSP4(mL`FA9WW1GGAQiobYiB57alQ4qrc0rYf zor(6InW2z_!eS^4PD2dZMA9|FZ1w3w4PJ?Qi$J%iv_AKsp)`6#aHeigP>aj)j_8VS zM@L6BbLxKp^O$+$J8^#ySaS2j^(!jQ%nY2XTTl1Ys>nvC`?jg|$dqaTX5d@%vf+=FZc5^!#h6n;Ltm9U9 zFm>Dpu)W!WLG6Fp!DZ?4Tb!xTZW+dQ}M*bo3l`HaRH%hwyOsxQd= zclw;qBLX&4oQmCU{8f2eR1|FcYkcSKs`rByd`1pw6v~k-#t&Y*T{( z%KB5tKYN3T=?_M)XPrSD97y*UG7dgM4ps_2C~eL`8WCvqLR)*f{h0LW^9gkMTcqN{ z{zLPsYA3j`iBC^njEsu*_Kbw~jCj3;Ox84!s^t|eW*YKmbHOVsIJ)YP`EGZEK1zQc zYGO(>g8KT1ImKv@@Qv2jSCf4xsT0ct3qV#V7xMK09X89f7RYwvpKeX%C;;g8xoA~M zc)Mp@Qxp0=lutAkD-JH6y2fJlPqCIcaXDx!c6%p?$vojai*K+rRA1a(Dp${fmUhwe zA=F<%&CjJ0&*}tgl`T3WxdxTUsZ!l##w!4}vu|JrwiT5LxHEePx5LI*DMzO#iYWWV zIyb>(aj}FIPR%JeAGD{}U3r8#TsN1v`;*qNig7v=E zLKa*2)KAo?obev_Gff*K7-RyG@Z>T%nsyy^#Sn>{ar8wyD=U%9ogHMmbQ++uH+zr9 z;d=gCx}q^YU&(%^(9*)5vw#hA=V`aGHJwUr?|zf4()2mUh>AK6y!>&+$0n$k8q~^7 zUaw2SpxbOUinz3d0ky%r>?x)&+`_Kozumt(o(9^QyT~v_}i~WEtK-)bZ0)p$t z+20Zq%>O3RfDL5!K^WI##RmZ@{7Q|U7AI#*!265G$y}CqVWNk-GZCBF7|?Svt%EV{ z@Aa&0$|J+VlBPF0T(gX4%Dy_L-xBhB93NYqou1llF(|{;8;Npt!bX`KDH$6ySD$A^ zH=xBV_4T!TVtfgw8j$|_6}~NG1)GUk$8ZXvMd;D!e6k8i)6ME*&hpbS>)vkR+R*vG8!=J-T0iC>}omf zc(Mj;8>T-*7zzaj^mrAJ1(695#B}9`M_^bto1qCI)W~X&PK(RR!gW${KrC=H>)gF( z6yT;d%1D2wHJn{G`1wK?))v5HAHZp7=fr0AW(T`%Lf_h8Hlg*@qP5TqAI%lGNAx_N zbgf1zAo#4UK9>5giuqdrCNs5S_3WW0pB3X?I5a3?Hf1E19~vgo1EnB%r_E#_1j=+Y zj@Rut->Wur(nQZeUId?jg@E59uJ1Yr)P+T^a(!S4en`$PXf8t{gurm`RHtI45qYXY zl2f3TomNy7lapCZT>p1-^BW~PI3kYx)DPbMgK+^!a^kS+>gtVF`*ncQuI}uduQuT% z&9dp{O+e-{rCln&xxHm)vmoSii@FI) z>hic$z!5wJmh=j&Rv&%oD|$>!3>zC8fO2EJ#$Y_`0bZ%}$KxQ9xPXlW8gbuZ`j1hE zr1P=ITO%)L9NRehE(#qHmx|X96T8TDR-OnwG)?VJHvbon@$&&p zq}Nl8@Uk+V3UyuG(?hC1#0}$zfYdM>MA&BZLn&7vpT=&|Kv}t;Y7I442rnGe+(1Ig z#uk!0c)rpQ3UvtxoX!ny+sCBhg%67Xp%eWgc^KHqP5M?zf;K&}(QtMK1R@qI>JS5~ zI_KW~e^as=g)uqLIE1t``AevC)Vx69FUnP0X$0R%Rc`=29fA+3{>a%3Xx?HF zz>9bH_rvItTw-FKvqK2zBc7bF3v?e|3%c%MV%U0F@^>i-jpZKz*6`|Tc?t48N*_!g z^uU|=#jim;#lw zmd_oLi5AUJ0Z<#nWn{FPr+;TKOG~4O(p`P4C&_8%<>z1j^^2c|raoVUW!fliARedH zVU=v7nr3jLLyRkFs0)efIly*d&SG$VU$6dF*dwgqB2aDT07 zIVb3N)onUds-}fM(JR=@7DD-2vaUYPvvlcx6EE`VW6c`=tyKj|-o#HbN7C>4=K6X+ zTRH+>Fn|bq{#XuCtcEZvP+@0)X<5CbJZ;cSeDcFfu%Bx7D3Ri#r;7a&i*G`ODm{7guY! zS_d7SP?28`VkS<%%fn%{(fbs`*{%)f+rYq=P%2VD9AO#F=J#|s-00vqikAWUfVNnh z!zKZ*i5EgDax+?J(t#<;MaC zO06VAE}6sn7MNN|^hR6V3NL2)^+=7!?1>MSqEypAgb1;*yUfPFEJ3qm_6EHB`1uiF z?gA^Cr0U|*II((N8eLjAm6n#~KE=IGC&VoSOxCaRBL%DLt#DQJ!GMQDXL%flh@{L4 zS_?`msmJv5enxoNAh`l;!pGBR3uzc%tduQVDT>mVsXw?*nD;S$jZkiouCDAhrm*?7 zwGoExp&=n-VBgxEf;Eo>{a=b}BCitIoen2)eKasfaCw|az#;fOFV&yHndT%j!XqYf z!RKO2#}M@bRvXP39ku`|cJj2v7qYpqL_VB(9vonPbp}0!63Ld?6s#;W88l22;iI35 zc|SfaXT#c8mzN_0B|`=#CcbEm12y2N`}BL78>P~;7k6>Ufg&G18NOp+`}`!j#C!?@ z51g!E+VRVbLDUr8Kk5?;GipOCkK(=D{heQT`DZqFy zk!*coC7xeEdbtyKlR(5dw>FV7CCF|c0Z+EVe<_IlbhRA-Rb5j9XpoTPTMd zs(5>Q%gROruE+T*jETr&wm^VDbC%F|rIj9E?iaUuY(;(YF9C3Y8jCPAhPt|RZrNMJ zqA@w#_G|6VMOSUk5IT5zZ4Sm4N5JN-sHkWPnU`-Pjuclmqs zbiHpenfWJI4ln~)W(zQ)oF+3_0oW{FFxGTZWNqDqh${@PlVkqIo7AE+nipDHG6ih# z(}jwn@DAXLtlgTgf=a|y@(5mWVG+(q>l|wl6eV+HF`wcw zyy6J?N5{um85rVv)_MgkUqfL~*4iH3TwP0aG)Tw_`+|c55{U}zB>w?;$!Y(1mJ{Jc zPG0`~-EVW_8^8c2Y+b*7LlpayL*4rrKClOjUKT_X`a=_wLNpSJ;`Khd}R1U zvZ7mKnB;z~*b-exUY8*SfNu?~c~$W1Wc?ZduO{c z3kih;Y>-TKwat_bX(TZ7ff@F1K(U-O6ClCa@IezcR#EJ3z$7YtCk_UL_Zz>LyJ*k* zEj(q9wdL=>00RmDz)yeOFE1U&zU(b8Efva$iFY;W@a_Qq+a0Fo4xm$?x444iefIc1 zw%V-P?cD1q^D-b8cykHh7fTe5oR}(hnoL1RP+#HTl1KYzz`D z^`oyfIc)NM{H64<3=0BT3GjQI2MG)I4qO~l;?M-}Xd?q|U|r^R4*(JnV$dI$V$l^6 z$&zxwkPZQveGI=g#vmrkT8KhD-2~!9bq>@M3~d{^EsDS^itT*9qVm*4y&K4tozC?; z>6-k1?|Hsv+)YY8Iv||79pLkDZfZR63+A!v@=)vVHd>$5+(Nml^6l+Nd|&?5tLgqVp===7aj6y!wo7Fo!nqG2zy?qaFun%3iYVJ1ziE)v z-wYL5NcyaOVYJ)WCu{@N1OVEQ+4Y_zz>8DQuP25UhTCgl=#iwoy*teK9&+l+k zH1@t2o0&b;ti1u-1ei@ksyk!Jc%y=gq*lGk{r zl4S4|x$1yvBJJ$#yf^NM?EkK5XVVgJzLM;_(;sjx(IE8NVuF1KUDbHdh04?0Ng7Pn zzrN;Mx*QINPF21^`WG-hekBlgdEZhw`6su?(~1(A3oQ z*c*nEI+|gm6EG1$w=}wo{@4WyfkEI6%^qMOJ!@gD!%szpdw*w(q)+rHAkCny8xY0Q zRK&5FzKu;!AEkXk+moW8%XJk&w2SqF_G(;5V<+o&JxY*Bo6Ql`{I}h+pRv{Fb-f47 zS_OuFdZ-;*+4pDHU3%1RYRK@geg*}$a`FdO81OHGu7?~5L4#uFRw01wwl52_$^%#f zec)YQl+dXm-<&!(p>`EuSUw8N;K)`GWi^-l z2z)yE9JgR!1OdedAeUinjg7^8zBk1j9L>G}P_Fq4Xi}8+N#Q<7a3|@Wdyub}kHEIs z+|(bytO*r^kiM&4DZsy0K_&aol$350WW9+dCi5 z#Zt`UYBB8V1tKF()(_{1Pb8$Mzgq3}JP!`%JlK;|BZCvaLW@MM3%ZlhyVRP^l0R?<%GYJKf;GCAi8bf=quU6j}fgrZ$fY-AcFe#@JW{ zNGMftIt)Y`LC;Hq;wZT?E!>BH+t`4HM{0bxR5SR(y^$X(2=3xg`)nq7|H7Rd>(&rJsTcb zT&?u+4Yu8R;aEi(yxp1EE&FYDsq8DZ2Mai>m9-5C&U2l9Q^dn&$OhOUN~FX6s1qX9 zsMN8@j!2U+%AzR6oih65u*bGZ5M7(q2X;^5W@`=1h_LgX1RXX_p1--t^NsnPJ$+Jb zQBk`S6jGXh6F3(>uQH^jnWl)B*z2yyRzB(h+)S6Y40g%k#j+>_OnQ2H<4qwf*y8r? z)cANX%}zU@@BrXq%yl&Gk4l*Y_8SD(SPbWf0J$NW1 zkZ%ar?6O&;yV?U*#~5)2`*W69v<%30I|rHbdmu)XNu)VD`gLFV8|4%a^OX9*h230@a`mo{Vp1P#523trSZ*5rNLM+5iPY)86zs831H zu8}JoNaX(t;ROUzaB+^?lhJR&%vO;70a+*&m2Di0tDz1?H0ACd^_c#%qpjEf^^4&~ zmnZhKWmSF>m~wAk9rNDL5&bx+=vybs0)+VSPNb71qy?pct964DSGI0CanGNX&xk>|^QA3!RUIL8u7+S{ z)e0hZ#YJQFH(w~Z&i6GsBxCzfGdCv64b!**$JcD!jh@1&3p%#Fg3%PYyIl9&W^r^F@P;o7+^dx~mIcuQs|XUtvZv zEK*rUTOrLE6B;fP-#H~3{3|)RI9?&CfP0;)h5>ygn?vvh8uhD%+vDY+n6N}FJ}s9) z8d8-8FDok;p6tLADF#?&T&Ki6DoyU4jYb3w!TE&~`CK@Z?6xmVeoMVoGG!)lTpAk4 zgU%!$Jf$o#g$|;A!-^sv3@a?UI~no{;o)LUV}%bhD_FQNB+5xw;~q>Ac^3_uEsSQz z`!*e3LrS0>KHsLi`{Uz-MMeg^olvNo&X!Ic7kNdDhM52W_6-fJSCAByamX<7kSd($ zLM+wAfhk3z&{Bkm`Wo+h&hIM?O3ehc-?)3$p zIE#8RiyeQ6(?xu-f93!hwO7&B^VCMxhUG>o{>xIC=>{}o@ju1joRe@2*gx}4HK<#o z*<*0xujK=K%da5BP(V*=RR)L_yMHr^DRyVr(=2}xMm{n0g(Z zpAQR!hJbS}EQ;vcS%4t;T|_$A*}~9>f|3FP0>-{nyH2pAB7O-?%&S8gM-l|ZKwFsS zEQm;7T-c#On-u#DP+GC*hl42&O#m4nD{E^jTkA&8KWN4h5`m)1KAjx=K-gdi5%FO} z8qtv@UBodWC86%48xK16{2l>BMXCD{0<}6Nr`NTlDx}DHJyYpnRf$>oVwcErUS#x5 zhLnXkC;jEusbYlL8{P(x5kOn%gP+RvI8iV1&bFB*dzo#UtL)36@sWTI2|=A)G@04ZDJa$V1KldF{u zTQ4)9f@tVJF?05Oex6$47H_kk#@%()NTZuXd~`aj-XP1`V86UkH=ZtoIuYAHko1G{ zpT$Iyh*xa!m`I&e8ur4ohcCoHlgpyN@w4cV^WTZI%*qSN5yMe z+^nahRzd5OdLgU0xOUtwgNY0#fTD!4F7Q^ix6M1dgbG{v#zvV%YiRuY6XWBk&lw}C z?-NRT;PcH8eyT{oT4L8w3H_nQaE_6=$NeVBNGS<*8y0jFYxmNh~zp}WjJsV z09mGZz?Tq0=Wwu`4%>}mJ)6B__itHJMUw{0awxPu-SQjZs(IL!Q;F)3}{rA z(|_`rUk8syVzFNzF7VkXV*G<~I$MCWCa{lY&{e?I0oiL6;Ho+NZBl7fm6c0%hJAno zRGQG{xEn!?B5?;MrmWzG^v!vi;T%54@z4SK#d%MAKd^fRm;8Z0+Nph zNsJfa(`zlZDt9#xIYtEkrzxyWap;;rhCv*&n}o_0Jz@A6LL4)vOt2hTQJ*oL*Xj z_80+lW%KV*c z02Y;B=c55?S61zylu7Ioj0Ak*&*YfsXcc2)v1=V&Xg}V1uM$@^1 z2(YMq?%>>dTM3<(UAl@t`Tmxg?059;?nZ?PK)k(2r)4nfc>vw%<{V(F&VgcsR^wcE zpj0Y8A6Pw5aou*z0<4UT3<;1pw8vKyMdivSCa@w>HlJWQZv8oDA{Ykbd`%Y+&bNAU zG&3NEB9MyQivc@#@VDO>#TrH5etKOUitSN90FSX4#;CaCY6FKXwIwyMqIC3%m=@n+ zf(MW|U>IHxp)2SxATD2=MZ3MQ~Y>Tjid8VoRI+MV}1v$9T_E7WKNUefdXLCrQ_mI0A) zYHE0|NSXR;uKLCuwYa+Z)o84-vjQ6BFVFg$BgY?s?H(64WlDQo!2+tPsIyT zSnNbNk7REU$Kh!}(>-49a;6X({cY=N?b+-M7S6qguYl`^Vrppma6sm9JyZblc}A#_ z;o)pA!$wsAmkbE#1uRn%Vo)n*2{@zl{del-uuph&H+qWVoW#V(Ojb^Iw|twY;gOL7 zjrz9Of&o#{;DBBsAj&sxd4H;5MR5SFS*soVjgpcw_#*QYI03NZtz(chelvrfmn)(dkoj5?1;1F%oG~jE zTyS_zAeC63OkIZZQH_;XoK0;t9X|(vK_;RzO{75E_wVUWYy{!@KaWmE<5^xK?dj^P z35@)d$)Y1ifCzS{%U?t=$N=ejpvI4|= zaBy^EWd|5=cB|t1gX`-+lzM)2w6j)2^zm{thgE##=yW>{x}q_N*-)s@TaDHA1-;IL zm`UHxjS{-k{esQ2ww{y=;~J2u&qZ~IQ~;;p?J1(SEk(z-=Oz(i)jba8}vC4evy+?kRcMz&9y`SlP8=Q0+{n6&(}8q{?Fn5j2!{>_cZ(H zg9e#(8X=J>{6Buw7vK^AQj%0H3FO)pyubS42JgZ5G|s$~AhS|{^qCAhJAYJFJDJC)Yg5L|S9pzxM&QU4 z31}@Ys{&5L1DGH9wpCyA!g_R^I~})$-oQr}`CZwHOG^n<{ZJnOc^znSr28MrhU1QRGOA>FBk2L_$2St*t5FwzjqwO1T3GSztuS1esXa{(?cm8>=IuN94Ol8-$PPxAL_r-rr-o85}?L=B*T`5*zx z$vZk~O?U@yO=K^CT4oBwF-P7T1KvCB*TYJRmCal2*}>XKZh*_L*1h+gZ05q$kb0c* zFgjudL}bQT2)t&44&5|k(x7w^Bex{Fb(gcWf`Q@*a;dnhhnq^|6UnOZnde4K0p-S- znHgY@0MXp3_4S-5M3E|^*CYsl8j{y(+nHNOB8%Du;~ysxtgY!<#iVv-Xz?3-Qd~XQ zd~Gwu5XBGE)oP23Y|-cd4t&)|0T%A>696>mAou4A`pzWLNE#acQ_KnbgH$;g7>NIn z)AXJEJRUIO>U0ik2VbZXvf;*GO zu5_^_7^aRpO4*}25^8wh{r0#NHW{U4&hSpq|; z48_X04}Ed{i|1RmCvhzrU4t}ZZ9VNwav~hY2xw?v7J|;e9|T2oBz1pR+5h#(wNE7C z1%ClNJun~Fn*$Bp2p(Qw1^xozZ&E6FF-OW95n4c>_SZskN%%a{0SE8{r3{BgC5nI#!Y(MsPK9G@Yqm$Q!7>a`n%FB7vez8rbm!;MROk z`Jz?(ZGdV&pQg#uvbb2G-M6iDexutOeG%SfZ-#W29tUKTJ;ef2R*YK(l;5F1e1tS^ zz@4hmYZcgepcbk53Y=>i3_DO;WJcES_DZ(=Mx$e5vIkT^f%rk6=`Uo&6IhA#axV@{ zNhdJi5R#INOgP{DuW3PF+$#i;l%? z5GS_T=`Md~zhuE*G6%O?N$2=j`*_y9n=5V@AMc>%?kb zM1Sy@@8QS{OvTzB_ZR*1#RDIjbE6Iq&$nP7XQb3sE$DKAK};{;&X&h!loR?sv0`T}7Z8XL0z%ci8FiUV%E!Q9z1mP5lfr7yvC`3;m79BheH>a6jmOLcL|6AO z#nMw&W;r=_iQ#AKL!WHFzEeD&qr#O2N7ljAM92)N3RfEi?=pM>?9h|51<)--vq|lA z8);VrNQM12Y7F!MYW#R%r(nyeNB5S5L^5=I8jqCK|NcUVvx#2~;{@viIY&?xFm)b+ zcj|19vf*!RY{b%BZz09dJiB{3$OnJqZ2sl5wM$r15;hT$jn^j8+qXa|ZxgK!>mWQ* z1Xv!hN%cWJ!IlgSMt;5-d;-0hlvEgK8EYyk=9iX=@X?8RMbO~q8o2Ns`T6+B@o@(h z7Se(EF$i0GcV?pS{V0WTx5D3>Ur)Cw;64#^7Ic|eJfU2q1I`6|yM(AM#0VF*C!+t% z9e#BOG7EsEpwr%zyn zrLC(M4r#iAg>z8#zI@G%Dk&Jpay_lh<}ewk*4xFVJnR5xSUVTzLisB&kRg2fO52-# z2#Ra4I>H%XKvUf9aY-rQ>k|^nj|gn$Q7qB2Uei5_9P8t2J2=e*0L6NJ5US-xz5Pc^ zilkD%R^LWl*WTa4rGHk77^r1Uvj{1QMR0X5DdF+>pcOYpCLm*VL#L8L{q)pF33~7E z^=2b^b~ne1U#BRN)6%X{)KAnbhQ}G+dR_&n0V5RD4>)FPnAv)AzZi>*V)g*_Jt!D> zwl@g2XSQV{5OPi!n3vTrmSkW)ZctrZHQtL}X2!@U|Iq{$ELYI3)3%F-vwa#fkWcB> zsM2Bq*j@rh;0CJ7$3wFA{=K5{I_2~q1AVMlU0%1=pk{Cm){#v~)C32&p`=Cy#|NmE zkryq^42YopqFnrjdWnM6_uZ{?<0r;*aNyV~+6PrvqnX`+t`f{Pqc*0pCaRuo>c1Q) zAs{?~5;0$S@Gwfs*!ZoucraLkTOBmE$jajgR@N0?8N}V$YS0VjYDo&SX3`sV1!-oUEqqL z#`%xHqH6#~J3EVPDquPBM}O^!9e`;iXIL2rr(Z!q;sLMiHN4G}&uMYWK3zbHOyymBqo;?Pm4!<{gh&=-98MAU@nWzTn+OG#(eCVS zaQR6mEzV-6J9h+?o-8W_5sR6!w!;k#3CXBVqlnR5B<#I^155N+C7IzAo`7cZ>O z``7Ze;_YR9v7O%Aqw?46ty+GUW;wz2E_}SdUbk}Qr)Hx4Y2$L{n)@~cpo2=Zx&szd z_i&7q+Y@!$BBP>G<{gRGr=%?(tK|p5aw*=Mrf9TV&`SBb|GJo2_s#8KxSQS8`)Ba= zx~%{(16OD%F5M9Skh@-QC$Df&Jee>UrgC=>gPp6{dU5*s0E*eWP0 zmMCOw;NppaCtq4hYH(1Z@zZH9HmLs5QBjSv%z5y@kzs3V%jx_pV%Sb{+ynRn#l(X0 z1AE#-Gl0*DUqAal(6>!^!MO+kQ~vLj`kz{waIFG<&!dx*O*Ma%%%7=5PS|E0QUv^n znUOv-f%2!nzh8)%`JcUc7EQ>x%w82FFChGRxaA;bU7o2%GdEOhri@K(M!&-H=Tm;I zAuGIXJz35djevV(&ua#6FgrTx2%f+KEtr5#a{Yj2<)Dx>dVGUN**x0_T45;M-lBAd zxjth^TJ{o2mAgWm=s4sL_QmU0=R>R#Cb#>@I99v`cRwXPe+ z*~ag!qx85PS{fS#4ZCN!F;=Gc_e;!1-qp7TL*Q6>lA86(=5{6L>o9m&eA^s#ow8M( z5l5a*(sD2&nXDej#?FlRj;GCkUR}iyyziS>Z$)`(S)#Ji7yIi5Rsa|@9~~WA+t}<# z8yHk8=Wg1Lz4ut1TreM=JOX{Fvzyz}+>#hu2mz3e;JKKbT~f~0n~C_{s?47|f%k1i zT~#&M^CybCL66Va+}zGQ&5i{tw6@ugj%H&zz}Hg;hRmy}ugJr~(&+>LT_6lXU7GWp zUJNn2n4aExp9mR3jOY#<=j`|IBy8jjRSI1s^rnuje&4*nksoCwFHc2dAqFgi5)vkm z?7L$EZtI0n99kt_KE8_bW@2ovwuZ;4DexERU-d3HbF1a`B}i*gvEmnFx6)u^khw?Od@Wl^QaECOB#mz01ewlH}`#lYVb6q2ZJS=@F( zWe-gGkZXkGMpf5g}ZA~ zaEP_`U-k7nLnS3r4D{Ozt6((v-Sup3Up<3Z zHV9m{MoKaaR+qic-NMeCl&ml+ZNUiWd0*ahagl!D{5_0jQtEL@h%l=%64!5NcqY>G zTn1~uAlUAN1Z!<-+XRNsOZTcYdGHAu026s2_i=M`o4}g_RKQ4(py$=#_&jthUNY>@ z|As(7i;1ZzP-|t{gWvk#5 z^iEX@1Y&ux+A1v?BsuX7j)-%9{*U~&ZC1Ys1Rj*IhHt+l8g*K130QYPMc>ihvCZ%R zX+x3198MxPO=aX%H6n9xDaJ&9Sb!TOAbX1GMtyoH1ulE+#|#_j#bB0~g{)HKU)b;SX5><9LSZF(wknAz2Tk{n6l01))!dQ=}^ zPzCxXX0O2Xh>~GWK40YUq2H*D!Hd479}yK55gB{STCx&e$K`Au&LzO9rn7S$#4b32 zp|qWqy*>PTxV^+^Tz@|)DX9tx;j!NZ1p&CW37|0-+x-jIFjm(lf@0NxPUTs^@0*Bg_9SSEe&*%pw=kas-n7)g zJ_(d;UUszldQveO5m|Egn=f5Tg_(c`46^@xpmgc_X&YoOOlAG$G8?`L3K}sbz!gD& zABQ1|+Bt@3!oovsCxW?IBTV&M*~ZlJ$%(cm=RLWNwgRsaTxbrYFK;q_c@mf<152-7>2q#{&m;J0|d*?LPxR@VIT-kffq73g2Z<%JU6p^JR7 zy@USlPn|6Nwr7JF60Lb`aJF2G#asRbMdRSa13q zO!0Olwf=n=A=}?ze%PskNAhA#jgf4=FVplrUWy`#|78=W2%EQg-7>5&b~%XyP3rd# zqRmns_)NA6?XW}_kPI+KAY;x5#ewRbF~y35&wBmBQv^FCEQGouE)0g! z;$ac%zt{uP?Cg3Y(;R*<%-hAh8Q(Hz_Rm*|72tHa=NMxB!T4`ovF6{J}A_O*nDL{uMi~}rFY8EO^)+L zvUP_bkbzDW4oTyRBcu0v$+6vLatGZ4giLTjEqdBT<%yUcJvd1rEgP< zZ`PEATzB+5Gobc{@Hxr*a&fVB>j9bB#4poUqXrqANV>(ROAbkMas_4ZVXWKP#@HGh zF#zB3_ATq{>yw7B-WYNtu*&bVU!5bK?_c`-=^ha_WqnITHfIbG;WMN_-UBI+zIuPnJG6@Uw zISR2wu<>_ApHgIzGeZKYA0K}I5Wg>VE31Qop=9r}USIn8>g%LT1W%_A(vt!Mp&G!9 z{}A<^0ssiX;OFuMstKo1z>&;5FPs|C)KqIg>F&S(kK2xcgxu@q?4lBD~OHTottHeW!j)TMqsvyG`K^vxTBP2dCjJp^$C z{KBqwfJpjO|)hOb@ntOB#|dByyNQUroxB_SJPXcXobSZ;?-B67socBji(%Tu7^lL$_sQPk^4S=d$^@zM^f$ z317*~%-pPAx(&oD5sEXCQ+vlwn7}~_o|yVI;G9>C;>O^2TB_0kqSk-H{&5GPz(5+3 zIEfgTmfr!2wOwx%53xWj+8bEc*b1FaH?)m?%MxHkHgyV0$@@Gu_7m9W!q`BvSMa8; zj!wgQuh{DR{JiB%4w^bV9*ly=+qVbkqM{0wSemM;svaI>E|vJV|HPEbJj!hl`1DRH z5EoS>5#&!{1$!8xSwRz$W#a!wIRL(hfny1G*PBBu6}CZ}&nD>JK}YZvNEuj}RfT49 za>y*ed54+F=V18myW0ham(k$$rCGHSt~lmc9s+W_oJ4ND%MmuB|N2rj{!V^u9!zw^ z;fzKQ1iQ7VPGm9qfY{ifza~5d%}xSsemY@FNXSRU)Pa$r^PK-R@xYHJ&P{W1-GK{_ zoF1PElM?*KcCtiYA!tY~_zd_X09tua#a?*3h-z>^gtQTX88y+00Iv^SyOY)nCt@5W zC!hrf3r5ALoWSkyRmCf(0zxMzDG7%kON;djZ)``3^g@(v>w zk@(JpkgHgTTuAx@C6%_5ld5Z&a=G~zXlm3#r2f8%1h!o)RyxZ5BfaTaNP5U6qnA^k zrZ!#KDgeC=z;9O?;1$p*G8LhYsbY6=i-N#pBa`xQ5#YlnCM{~5KzRUS*DShH24S?Y zFs2TG$;et}!8oQsLuf_>o*eH+50F3y!rD_JI$|Nao?P3J3!0X1jwmYuL@wZd$8-Yc zN!|j20YZg{L%3dcLtPR=^z)ZQv=iR9Nm&>`A`n8w*ap8Gsa22DkVBAk1Zv@JNq*(F zTJNwhF$wrS;>HwxrM>o;kb*Xc_oO0e^SFerNZ~@}HP#X}?b6;JW>!(%_ql&r z?u~XZH(Z`eA2F5x8ukBu>IF$D>KwP*6C?3^W>P}0e_t`|%Ok6&fA%8lz0y>dReG4k|1p%g_r0it{Ew2rlIL|>-65qpOq5>xoGshn&RRr zyizMlF&23>i_kVh;%jS~{HfihQFp~ve<;wS%%4jz?~Gp6Zg*tEMUeK8!uuxb(hk&T z{gI(rE6exyKK=OMU-Q$c<$o_#IgS4NaJ^2_jy;YO_ikpw;Y*9ZYBNJ6)+KN?g2G?O z^Qx$+=?1{N3~v)&1jvVgejE%9pq>{zW?ecRpKk%gJszqy7-^67?lU>STP0NcWHAIp zsNITjI5punbOV5In#mP5T5hP=LI;pnH(<35-q4DN$wh220`K5Y9AO8f6Qt{jW9A&! zbA5KMYSa0Uj<~c*cBkh~flI|buZz9wgYg%BMzs-So)X5mV|)$b@85IbAKq3pW8NWF z|JP0XDwOL-=maD`lgr(ql9FL&y%tAT*Q0eFpV_=X(0PHq7nCP27bd=}zFc@B(V#a& zK}Ch=u}3Ud1i}kD|3YMBti+*>V>GHp`EoGnx4Ohi09%Lxhgwr}I45FWYB z?}0rlN#GlqDTpb|zWT7Vg$u%*Mn^}t(^i35L{r0G`gkI(mERrr=)`%jl;VTcSzXB? z-GT~Za<(;+P^j)P-0>9SzQS9oDxxUgXl#_%M=~ehCj8#{e2V9&vBh5%kF(3w8=VNN zcvN-*0f{CVE!M?6ruP>G1(b7taz%7j8v`JJLF2w4*`}$f31;uYE{7_DCySb8a>;}^k&MwwOil1A-ndeWwezz62vk>|h--*kqr!o4W z*;#SD7f+wlgEgW7Ze$T0o24pt4vxvpzi5p-_*Y<9fTP{r>--dG2h7Z?!5PrQ;Sk)dwtD`niEGKoC~wvB9`pn` zNyDc2`wl-khDJt4eoVbd^zdrAwLPgf7H#>p$DaNfgkOQKDKD$;-UP+z+;$b6o!(DwIdq|&oqAx1+|~_9!Sw?G?t+Mwv(0W`eqG<(tN{Xj%vNIe z;9!VbPLAQ(I+YfffN^tw1mU5`Z6tv}cZP;}5foS}YqmA9v)J2P6l(HzkGY|T?B=qW zh=KY015XzeDhVEoencPJFBoWOa!gvXvPWps5FsR0=oRfHN86#L=mpkfHV0o8H}HQE?2Kc5`8PegPqiI5L| zW18yZzrUE64f62k_Oj$OG(5Z!?5-TZ%^m!#>h${RXJ}{$7z`6=SO!MMe>R9qN(B{T zat*|a2A|c24nvaU%k})Qw0w?SIr(S>)MDzD?Vq$)4cx7A67t=mvrk z`VCVzg6?s!v7upLJPpHqW)GS_f6v_N#O4J9kK$rUV3Uo84O(meLQB0-t}ZRaR<<-z zX#muh&7K$JFFQ4$ixfM(Rp=>H=3twZJ{bQ*%16d+n;sX}Lj4sy?nG?H5S(rB#2}y% zuQc0eeb5{Ryu~aHlio)gbrn)zn*r8$j1^)o7SR2-xj5E|OKU2(SUgK@dl1}T?fv{p zOXJ2J1J%28Km76wx!2u41{+~LKA!XyRSn*_X&^Q5mLi7-QWrKWL!IRcWjxcgfXk`j zSNI#`@}i;L0-ws2Vn;zi5OxY1zsKs#3=c@rvNOC<+XmzG%*y%g?Ykw5~NIc5VU6VyWbl%jX)8jk8R+T9mX;p%fAHUp-N&kArM>Zbc%3}Lme$)8vfI9#y1Qzn zRXyH+-tn2*tcpd)^`9${G;R$$WtR##IzB)6bDVNx;8+JAp{6cQ5<~Ar@1divPQ`i- zJ40yY9gKi>qc$}0>eusGuIt~Spj`#_k#7NMBS376BNLu>YZTXlQX=Lsj~M(2#|3<{ z;vBsKKm&#a9+u^NaZ_8^K~F%da{I?-$KbPffpF7bu|D{05lV`(b4yDS0l=vQv=(E! zbcZ?df&s6x{k7m1)3rx451;2?~RD2mtIu!G)@ZX0aF!kOtL)EG^ z=(M!5+WzQG3d3Y(X_=Imn6KdPlRY@mU*YjEUo08YC3HH%50IEznj|2TTLC@3 zsv;?k<{F(^<<%cBB*S680|#c3wBw?wxX$5KH~8ERnK_u;qPf5|?h-jdEd-o4)J zqj9_&zIqQ7OunzFsTGxlv8iFH7=`#!ieRDv+$L~v@O3lR5Mw+x5~&`21 zb`?#ZP9{Au8X%}F%r69JPNbtlZ2BskU0p3pSay!S)1IxPY?-ArS#O}ooy`|FhJ|^F z1o(SB4$2-Kjb>F>Pc?m39}+?C^8bTw$;C7d&Q;^d66Nd_kR$6Aok%6Uvc7&vh6han z#%Bs3A13(+j{vY1AB~NTfi2C=$!VWQQL3)34Zn_JCJQzh_tzq5E+cGq2O~#Q04R+w z0H|v}nkNx4E2!63kTZ$zTlf>|I!Of6-^WM5{#WU=(-9aB0eW2e4%i+gH;3b7t-lYG z3?EhLG5P)6_+yqK-=teJ@w_t|_p+rZs6m&E+7J$+Ofcb1-g8dH_ z!;cn@AWx8_Ts$d(;VK@r)#jXlfFQrH@D_0Lc-V)Fjh}jZe09(YYMyRSqC38^S%F9m z8F|HO3vd$a(9d?~Pr#-CV3OJMx$U1!nRp)vM|@}n0|S#MGg_+h^z~i-9hd}xmX_-1 z093wZ!D(;qpYP5lWN|#5pO00`3RM^6DrJ<_1-9{&Qqb+tOlY#N&g6t#y0Sm$c+{S! zC2(MH){T#kgFyk#0mp#M#&@tpRbQnxIlVPYRB%t;1iy`lWrm4%n z#hNaqV5(@|1~$M_kmC?DSUKab6vT4g!`Lw&onv0~5INK~X6XcdrhDvVj4 zJuK9GT|(0{s+8JPrQ!3SM-LD*IG&=$s*I${eWm(mV+eFsCcnl0H@m+7zzS36X;`aW z;x*GAMz-~sT$_T9o$}`*nL>QH7Y%LKVxaUb>o{$R-0HPnd{|v$&CJaxj;3px+maWrd7fj=j!Um#d@vYZ?=P@ zqL>vYjPk^q2GVMQ`t}oeUVA-k(m@#j(y+dd&kwAPTZ7da+l*;_w$=cy8%sVHPC0#Iqru@W;S}0a^Q~V*dZMEJz@Uwab|WabE+vftMLP}Fh?Z*OIl zb0gRos6sI0RU-=GaG~U);VNzZT6D-c?c%i!p)BS>P??l2ozH$j_H5N5_l&_T^~S%% zO9c+qUf^hz;d>+k@FQRzzHk+M_-xT9r6i|dwfS5Neu3pL(Ue|`T%&Kl{&yt=5lETq zV}roK9BLGx?lxQZh5wMDZ~~uc{;@*F;u+D8gY~a{Ko}S<5fBjpoK5rQk^dfk znHd>wzc-Ld)NO&Kp*f{8`Z^4aXx4tn5!u|_99Yx_9^G7A5Krc)xGcm#vMVa;EeO;O z38jO_zEj{O0i@i>h@O_#$o%}q))p(C?7Em~_s)8SSv zYuI1h0EqZMN7BBfB~Z!#h0y!MT$6p)JlE5p3sX=2=Yj=s?V|LLcPISp%*<@$edB8! zjEpBFt?Zm@JAiBhpIKZK7`SyiJ8yq4M*DyIAkY;b9Q=|e3Zt&}4j2b0!|8?qbEG{@ zfocA2W(I?=l&Wv5*44(nIh7e6J)-D87EJt5$>la%ohd&-NE1Vy zf30c8mck$+ zj5h{lO1H0G$7&Xb<2e|l0F)tYc;u366vl)c3P^T}L_86O$QmC%q7&nL=E3IPEm+`ZteH=U|gsUDKwGCz}yS{5n_!i{^R@40~wV z21saULdGHz2G>`}O8O3Vc5rSu-4&iX1_pM()>+k0^*QEJQ6YxH@roj#sviXe+l8Z( zV0Yu{MT0Tp>g=pBsPJNbVlEEH63rdi|IlsxOKklKBtR?0#o796Y=3+D1Ga+T%LhT- z6H!UYA&{^FS_~li_I(5$qIAum4Kg_f_}0WAA=G5Jp8$>l|5)vIwk9hC@o2Z0z`GTY z3BXs?z9CDB&G5*RXtFs0XT7$7%4tMI1Sm8Tc&?x@vArrwOaIxx-hCQ{g8OrM$8f)v zQwI4R1itnK8lt4pd(qJ@eU$BnvNAf1_@yK_O$?CT;_K@>K2h9)Jy%dt@?mTHvv4~O zt;Q*>*7EDbc$d%appzpWrL>u`$h8R3d$w8OFH+_v>AG=ocK{dLMKgrdD`s#=a>NIE z1Fc3Rk&lnhG-kbJZ+{=${@`|q89}VZw!!Z_=xDBKQ3!`ZK9dJ?!EdWAEKD}zW`}lj zoAT!?3^|lJL?Mvl>PZBut!Q#0Pj{9ljLKyk2A+QyCnDVS4dO<=IA$1Y(o4!e2ZW3Y z%I?FKKiClnQ<h@_SqXAW8~ zu8=^(3Fg!w>O$WcpjZCSbZaen)SPDNJ6-+gZV ziZIYGQX!u9*mGrEQ2MGjV;cjktv(2udHFht11 zaJIx2XCd>~cDEqw55$SpWj?eUgz$mD`s!*$(4_ix8DX$4H~(!I_l$`n2?pLvnj)AB zG;DWforb}M!CwHYE=U{r0)~>tlw$(Jb5znI+D?~Flbr9!#bmQx&w73K#x0V0`1mq- z*siayv6vlL3%4(B{`?81F0_wEc&wIyx=o z%;G{`A?88=jKN+C(x7GDmR~FuVIx99cO+rS4G5`P|v`nIIuw!F_qEpg-4cm6d3#bXJ_mDg(=nm+yw64 zp*k2(N`pX^C}%CnDZhP#g*{&_9j{`AVlDi^D}q`+1Z=+IX)dm=DsTmF5t0ehKpZ4K zD~N#x*Y`|}k8`k*2c-Rj+z(yo73}RDw)-cjB>%{4|SB}N;hBd#VEY7uwGP$ zKo#mp<;A~pjtdWA6|V)3){iXwL1@IheSIS7=|RaCC}gTZ-RkKE3PU@{`2%X7A3@>X-d;u~{>e$J_1SMBum|cbJqClj zO2WPt7LLQUD8d47BN(FpUTu^X_-mJ#naN?ZG%0neZt+Y+e%*i^;HI3-3zBXUQc^5# z5-7l4!w-`5z<42^gulb*p#fa3vv9kw`Lh5d%gV^K0;7PG!=mfi^{NEqLF?nk0_3RZ zXn*&@SAc&5_Sm)xU30h>_FoO4z5Q_A0PbaY_wF4yJJ*~>~t*G2=|gYs2>-X4r^Au}M8o6Mm$IT@*~xT;El?>+ct!l$Bf0sD6W zEV>1W2L60QB`~08Tmb2?SX}74-%G7>(AcdV?vNLHM&9y3ksk!q}hbb ze*M*^K%oBfOSZho3Kue@3U34(fhhFM_yaPIQh&i(iUlGjgPrTWp*GOT);bYr#DpAv zJm$16qA;acFg8!*-!e73?M1 z??1J)wx-q8a5J5ZkLyaXfvXgNmmQP>e7r01L_BUoQE$L|a&vKg2EBVGnN2t7d5Ax7 z`iYnq)z>FxWibx?gtV$bo`a}BVA$bFYgBBkC^b0Uni?DJPUhf~$0?!u0wN=kfZNaD zgS%lJxi>i6K!JICc}Xg0ooxQsf^8tLiiecR!-0ri};t<1cZsbkIj2p`spw5=up7 z8*od2J&KJvtSzkO^4sA3rH-n_Ba)m@2NYS@hz4?6@TR5)Tv4Yxb0rQQWMi+z(ReJJ zT`4h5MyWeQt$F7%SuTJ?TVF^3qnT9I^f#D2p+qC_piLFi>IWde13i&yoM*I{nXjs zPOsZDm=o#>Zyga6vu&4gdRm3YoC(aAznDd1mSA9@0q!7QMat=CvQ@x&)Fa8(-_^B- zLCl+1Q88>N9s(XR08hXy;atng;M>{QT;E?(T|v!OfN@Ny<>^Q7tpWfJu4?On7Bof~ zrKCWb$o&R$l5J4)A~~#M?eX@6It+NsslI^}^_`vW6ZXRrg`Ak8nQXpq_TfK4&qPRQ zJ(0S6ss{^P`s?%aL0fg{37MI@t4qNcz{vZR#oz-#QU2xl#=C(N^+LbZjrm~#rf5-4 z+1-_7{gS)_Xjg|vM<5nHiC~T{sHLSu0(gsI5G3SWf)O+ZHYQy@olT{)p*GalOG!tg zOWjn!C&3SXwf^UMn~W>cu{3{PO7LvQ%Uc3R1Bld1!g3MBC*~U6+B(0rp+BcX{idU< zOIWIugWFy4=PSP_N4$gXc2&RYIc-`+Q|<=%3-ns7Hru}(M7#<-!ol9393B1I+f!v* zSpWoXT|2b}RPI1R+N4=PKX6h4t%|5$GKytuLTX(^``sAj;i6i=G+ z8=D>~w)xw)Z!}*ktUAVij(~-E)s>ws&;vSDze=?f5vAj`1DuckBTD^1TRi0Um>U`% z4hfb0W8?=c%pkl1bZ20KDZz@48E4GOczFeYRopK96Lk{AfJtw!ifxOOCsz5p2V2Cx zV34}Y!#NAaICQ;R0@RVO_~%mzc8yA4%1JXqo7>>aP@J6?TQIR z$JTu3a?=TDCGjxS9nIfhVA~{GHaX${@05hz2S#jKG&D5h$UakSUz_0401(I-IM)X~ zle@e|XteUjz)1N07Z%~o+VC`@9#%gPln*EtbsRHo>jEt@21fYnna_P=K6p6Ez08ncv$@Y{X}!! zFl;VL)Jxy?6bL}tlLFha*Z31QGiLhTUW;IO$Vr>S7+?=cb$z=ez+80c<2Dw8H$R}6WAw~S3uwf36VNA% z^YX|M5WF!kFy4NmogD#AVc@QNml0yn;!<8%C}_G*MD4*xVd5eq!xO2B6a^$Jkg)qc zg@`uB$&tkafgpGvbWfysoY_$Q819l+qpO6RryXuNn4%_NtHt%f4 zRIV__0Jw~4Uoy7g23&gyvgyVK(rvVAA0It{8B#-_7DndgU$P|rXgzRMVZsffm=OqO z6p76tfe`WUV{=ekbe_ZV_yQi7EcJvT#2qe2sDh%B5kq)1+kq5>PlN>6APLzp;lE-5 zEAiScp9kk($j(w+q9E!&8ESrd^uDFmaLlUV|F0(dU)d&i|8)MBERNqFKFd}P7F@EabFg>$cfmTiNBY!Y-TtRclCP2R-@sYp z0P8&J=$ju_m8y>J%71K)LRc^!okV5nqt&s?Dd;=9lwl?@PJf=R3;lMV!kA<|ja121e29xIUS({Qjd@>zQyyL5HqnPR&7de2saO=e7AInzB~zuBED|Jk~$ z_4bFt?&+AcWC4nbVk-#^(eblb;VI^19EemfdK``O{J&2x~0{@fmpv_J(Z`uY3x zx>5GWr%(2$N*fV-IXRnmcurkCe0(|%1AF9%WJ;Fbaazm=%MS-hS7^IKR2wf`K6*24 zWD(K29vYS4();Xu2a~(v`X0Qy9MW?+GxWw zzF~lQ7V3lDx%gqbJa5=Yc-AlYsy~g7*;|?I^Zv#{D1s|Phhx!{&h$4Nej{tqr7B0# zZ_fuCB3f$2u zYfTl^1QDQo7F=LPVm;XW#Es)HUGqYd?mqQ42jBCf;=#zlA~pG(1{LOq2z-sZFT!%Q zcyLtl`q)%beTO_R|vbXLv3U~QN9Oc_j36iOX7IsEy}n6O{dE9M}I0|PaiS-ZXW zs*NQFkvw;+^)e_DihhbgqTuSCM#{2 zkgR}a1Nt~EO>Sov{u0MsiEqvRyw2s8bDXtp=|a_ygaKSXc_WW{Z`S?Su=mz*7sCUu zYre)~dt@VsVc7fw1_O2&tWIQN?%e@fxLUtxUtA+r-o*%dtlN=PW!c%!0 z)PQ~@U_{B`XUN}1nsie{`L(wP>Z7EGAW9A;u z+eiE;q4AiZ7g0>;$E0Fnbk-Wdt*D@4o<={OUw?}o{E)lxFKU&opox*5E{mjq1hbvA_FeTmn=v6q2WZ2d+yTCoSY-NdF{<6_)-)vi1~hBM$3&3RyKZ_QuN1~=I<RsJP zQJZ8DNw}f6WR?ak=wfIH(-)5o>>(XEH!{&%go1B_zkey^6O6mr;*&#WqHhdEAHffj zq|htDyngg@+PxfG_*?r**(Bwf6U2!GLh2@DSg?4Id3HzJnxX8teDl zlD9rVKL=3;GZ#V=r!U4~sajbr=o*xxXXx4JNvq=DDHk8C_m6I?CZ>&5uxSs98ekhK zB)*!M_-fM+uru9%Mj^dc#P>K3js7ItbKHcMYl|H=_)eD3-gI=N)QJ>yhfAQog5~IU@QyCyfQgf<*_*IEY4 zSAU_en=EfBPgC3YNOD#ceOO8l6exp;X_|vm%x7cX+wuJMdG}%y*Mn}F^!^Czn(AeO z#(sM3qA>P*ck_$DTRn|;(?#o(wOUW~-S3a4uBf;YV_G4_9|N2}?gzNTp;t>(9?a+V zAc^a8PYf#Cm9R`tkoVOL)TuXlv2>TfXE#acyq!C4A0&~M{PWT-0Y%smkCT=w-- zzY{h4;z{s(IdayEyk;r-;)@d&_p=MU+GrUQiq%Sffq%#|ZQjOuTSh+F z73;u2Zo^5#Wy?qoH!uH*4(se*Z2)a58C@&nH|xY~e=jL+<}$veU48JEn(>XvI{P)-%#J*>xyBa-6Aj< zE?bP|`(85q&QyG2m^C?Sxmz}rPj)hwr(pj-iz$kwUNk)GLoJP|2eW))q07-t|*x$(v}^WP7I5)e3$HpH#Wkl&EfO; zd*RlU#18$o)y7MtseC&IP8&*dRf0@kO3r@5G#8qq6rFV(z=qR<|5NWE_QOfV9-}yS zu`k0Q)GMt_AXx4+zkl_&qY4?qPb250LDFNa`TlKeZ>s6u}!6vXp-J^H+x39^Fb1&?uOYU&vJhGpike?s`-fvZD*td zp93yG+V@a)Rsj_C}q8kOxaWuX){tgv?Y<^a8a7AaivTI?glYgo> zi=tQ?dzURY^Y{+k;1iD0L|Sywo8S{#h(7%9^Q8za4bh>DV|cMs3wba{C!!h0PHo(g^$~tpAyI-nad*{|r#P==znlLRwxRElrDSHTISNK|VGsdEJd=d8i4YQO^&Q2beIAyX{6TSgu z;O|q$$>c$VS_}3D@HV5>0e*M6)oR@r&PBvZEplA(6Id(#8;#^p9t>1`l(H+Wi>UalOR|TmYcLK6ymcq9qAkalKTes#tywY1}pI zI{z0{-xwrX(}Ov-ZQHhO+qSJcwr$(CeaE&vcWi6t{kHbU{yd#@Ctc~vsdOh#4486C z${Xfw?dikJRI0j+wP7H|Sc35{jFLxoySTpSjF)*|vNz+*em}#yF-mfdV^x@?x@P_} zlth^XHSyX!^j;|^+x5+ zS&Dlc7njG=nhX2~h~BP1WchAX`_v(8hEsgQg)ZsNQ3buNn|#d=Tu0n>a5BM(BVNii z?ALZ7t14exzs9-CtOHi!G+n>x%sAi`pb~%I`HXb+Z^O+9nt@;b6-A)RD{(y5c*Ng9hKK-RW+}`^&G;)_6A_LdFFXc)uQP8-oSzAYUd6)lY(k%)fasl+_ zMWHhn#1W^uJqt;)Am>=mHD%G_V*XZ-wR&;NNWEj1GFrOJj=M5xD+~IZ3qWc6mJ1=Q z5ZWp+6PLRTDZ)iu3muz1XF<({8#^+V-EN1wQZ^^_CQOcR_(X!e!c+>ea$aiy;QH$} zp(u0tSb{UVUGvH9cXOg!)mpW`?hgs8C$|0VQsUsG>1$-#d_lYC*F7DacsV|3ra3xu zV?4`%jsLnO+R$mTZ0<8gcVEYKALW21>$naRl}IgQj2;tb6YEeF%m_%Dt#;{~fxfHx zQ`md<$A9z#Nlkrt&NJF^oQ_6jmo96@c4zPK*e?MkyRUr4JxAVjWdoyeL#K~}+wM;# zpeXLA=Us&wTz_OgmDq<0tj8;0Sy6{5vkxPOo?<|T`(um&w5>}geeq>z@A3^=7t zz3^Tg^>rkUGxclxo+cG*mOBZ2FWR^2a(@_xeiZGXOfVK8leZXQ)h0y+@9yxY``bokfu&|P$aB^v;wfb7x~hrEFMjr z43VaCkLgM3(7s%oA~g7+P8|JY;oOm!UX)!nqlRFGje>U@(Ae)+pOA0t%h1UMZz0Xz zkj0#bj#3VCEwI2QP4#yiz|_B{tvFoX&4D-H-wwqu=rn5BdeQl{-J#jOnjZ^aCy^OV z#^=y`=D!A`sw;d#`H^y>@qo}Y9dG*&K%r~M>Gi@P_mu93HlEtZo&DCOA)Kpkz95wI zM)mf@`>P6AcVq-sfktQEJ*RyxjO!uGV1A|!$=OY;00cdP5yfixmGhtv9)a~sfb&pa z@4{l(jaAm8kwR}@;Gpb}OXPcv$ct`_ty?0DtOu(*+H@K-j^9$FKs6Zz$h9&J>^fGs zV7{kHUrDz*CEVrG?EVQx6Yx_43$>cq4b#X>M6xA?f0+(_dc4^{a^p2=VruRh5on!T zH0gm87@->I&3i-R{i5SEa;j0mRmTxP32UhnG%-kLcACxCD(|eXaJbw(F6nAT+WXwO zP>cB#RQOJs(F_ygn^Dh(9fkPJc)Fd2I5xO!$G>L-zUn@Fn^c^AcH zL7uX+Fqsu(W_UahB}hMH1!%b1yLlDm?b*H+$_T|x*I)+qdRotjRI}(mtB5@WSuSzj zVIFG*@^%&3`%DG)WxHgHP;t)@O!h>RJwU|$^^|N*V1nLU3x*ST;|* zhG~zO*2jF>*GLj>&o&LS474|fEZt{=Uj61Ex9U=l_TlkkUg-4Q2w>2u*BQtYvY3j1A}k+;aHs(NN+YU{$p#8aAb=m_dMFWsEz;VM$8|^Pvq_ghtdf z;ZzJmR0@Ypg^*M{bQs54!VI0%Sg$5fCJTBAVD9!x*0Ol-9&Th~H0Uhx*48QKOEiX7_N7L%mQ!=&L5%*iA0J>nzlPg+lb9-64gv->V zZmT$IL9ffWh-Cd4l`iOVAUY2QfC_LGyrlY0ype9-T3ISmhzTW_an?M%S7R(n= zr?C5-rIf-P>oK4P;kY=W77XJCDzL))14WDhfC;$-GP)+dh!u_~0l$dhJPDuYE%?fT zx_}o$L8^gtB}qsR0LvQ5r*$VKG|_^M^Zj)9n|+=NZ%&Lx`Ekz^J&3d?kR{4X{uiX^ z<1&09x>Pi9F@U$euiW^0K95lm0XV_JO~dNCA=-gASp zm{Qbef2W`~8MiMMwWn4}F<&=3!T)DWVwyX_NVbt;59m0GkUvXDpw^~re6&zmPq4++ ztpRRI1iyo}W~HYJ$F@LJCmbiAfSnDk45O{Avniov9-wA@$+r29Y4(pz zQHq+=dcH2(hO(_>R=HS>xB@vT-yfl3*$V2GIW{i%7{1YK^45MmY^LCwh3viPX+^D^ z90=+TqbkW!IcX3r;q8U`D{w0P{u$(3Zx_YBS7(L@xmz-le-zKDXg1go_e#$}FX1XA zmn@aNbUhY;3Z(j}Ee{~|6*M)C;h$fLWtgd%EDK`p#j=&8S1L_#U6B#ZmF=&kZ@jR-Ud00@$!ZV#W!U6Fd_|<8wpLNbuv8Hn8z32ECAw ze+q2EjlAnmT!%ocOC+f;vLuqx?>G(+DPW}{0IkAbS4B;l0)?}9PE*c!4Y?wPL#}f{ z_JNZ%l0}K7L5o#vg&4TNUy=K(;P4veyNC^|#!U+6$5O{p7%ohbuQd_4y{z^SwU=O| z0U~5Yg^-Ef#s>%gLJ(-bM#jMWCO81c>^?H!cM)y@0Tlv!N=K?rEl;s~ zHf}Sz$7HY`Kd>G^O%f0p0NXJzL{bFFvnoNM-%O*Z>WY?SqI{m6<3Fwl!8I5ookL?6Y4j5mWFkQUx39r~<8a%fo0}X=-A{H~~BRdihfd98gCOv;{Xa3F9LfHj}BVN?@cX=!JADoH^72 zF*Fk^WhKys2f?gtHvEjCNr|kCF9U$?((OVL$B8pJC4sC2IX0uzJpdvE5j{~giwzCt zeE^n@DRInB5|ytH^gv_>hovwp^^yDQI@V`sIngjDvJFILf_R~eOhCbKK)4c8cBqYB zD1Ml~`CtLMFIx#5BhpJc4Ix#en6bzsATdX$FT%Th@ zQHl*8?nuDqP^Ez%g!_7g-r!e0r1;BAW#;hTX6-Fs&iW0MFTzw-g)v`usq<#Z}+)%m3&LP^^=YidB2f+<)Vh7-P}!;KYDM8!1pK`thqmM<)( zGMLGEnypXbtGjbzVm{lGnCgbbK)2_TAmZrE(f1-P2sTRv>id~Kx^6QQy;)mWe@0Nv z>g;^p_+YV*$7toBfZC$9Oacn2+Gx&WLqV^{Xp3ArSl4s5nf{n6H+3ws(~~Y#1&|oO zH|8HT4xr4rKigDfHeYDQ-v=@g{RxqybVcaBDQIrW5YNQ{L~&D9P}6y(EIvT=zP$|( z%yBp|>I2~Sw)z9HpI;|=md|slBS=?m@B8`oJ>(6Q?D434yx)hUmAB0$)+(RL^hv_@ zaiBk}=ulE@-sqBkx46D0UXdty`p;V%s;XK!iAy29H^xjF#+9BrZ17Q(7BrH|CAQao zq`PtZAI_hq@f8#I)sCx&1XX8rQ_-LvOzs1JVqLZ~oE!_9&bAeo+U`yXeN%>aI?l94 z+H>Sk=d}ptN@d;RI(&e}6-!uL-|^nqo85b6#o}4(5adzeEzSDSA88dOJgV9AlddBj zW|RcNfdJ{e%r`EpYyEhqoXVvIZWW|95yf8@)MM>?S^v0YDDFir$86;zcug$BI=fxj z;k;EcWoim>z87D#ev+^2f_hYzdSupvEQslbWY)=Q5EDZP)&eF^m-Vy6+0G=&$#7*q*eH8|OMs~+q2-MKI#Li&ZbZ3h&9B#QrzeE;* zCr2)dPZp+kr;KllO~i7QPToe&3*5bKd&7U)FnfoU;pJ7y|Ac@6JQjUP0yE)9WfI{> zh83EwMpbf!XD>G%DEk?X`*zI)m1seVDpwRQfImz&ubdmXClfigQK<%30b1g&0>PZZ ztDK+I^JVgA7%>A1q1Lcy_4c{*u4RKY@SMPnVKsjb6b?7PKFd?tvh(N9%LBU44b5~Y z+Z<8&cxxvIVl<<)=E|JpHFR#IdBk{;3F7^5X#!gDD5@NJM-5Gmz;>WGKGT_VF1jhR z|MZmFXEOIAndxdYLp)T^I<`KZ7bnHD9py9hRszRGg+v|Oc;$T+B!6R-iU(zl>IB|YbX1w}-j*)>5^%rqEWNTQwU~4iH`mucVrP=Z#E3Id6I2br!YYLj^(KQzUXym#qFgK2XsKnroGr^T zIXPGsXe+&A1L=#SZcY=c_m;r00~g(|@+v0|UoF035i>ILU^M?CdtQIHL?lD;j38JHLNd+?oAXd2vhO@Q~!dyXI4zS5xwb`UM1L`xD*DPcIFgyV~ zrSA|lWI-m~^!iyT%mc5nFRtw@)`JS3$novCqqj_BEm3hzo*X466e~dz#}bLuT`UD+%KyYkzp3YLUnhBK8|Qhj6P|*i>vw!&!NGdmtNl zlW(rjD2Yr;M2|@h!xm?3NkDEnJKSu~>?yx)`&>2{@xJ(flPi9HfC2vh^b1bkc@8#O z0D$r|Kme#;4rdon8&l{1WncW+j6IZadhP-23(6M-?m|~N(;$!DNI%Qn!2GS)G_Lv! zTx|$L5s}y~n*b!~>N=fb*cVI>gTdgt_p`g#$G8{u2f5E*e;^?Nb6kdr60an&vkKc8 zfjJ}WmFPDKn>b1TYr8CF_3dA90`}|Tb^hv&8;&0yjgBAd)%WN3Oy{**;o38LEBfn9 z^T$7t?LP0fHophedYw+^Q#ZsZckI7$H59&&+2z2~Z}T-*U0Igy={iM9FHZ_lj7-zkF5l0tb&98l$ zcg6D+f81ER+jtz@J2`nj5T_XS`+5~yaX0F^WMNlO$Ia>6oXW1h+_b5t0JcKbk(gj3 z6p=y|#2gQ{Cx|f8v7e*kA{;I>6HoF78=QHx5(FZ09ASjUX-ty&Qu7y_v zov+qT6tw??(KA*x1uR?3Pp}1!f21B zjQ(RgKdJ_==j3}#~pq7))OY#D%0 zz-X_z4j?y-!MZA<(J#taJ-_mb&Dm+y<^F;yl-um2yb&#j-0%{ z8;L@*@|=o<{1i+l+K_>c5Jwng?4m-#ACKKPV}!bG&Qk$VXW1?*&2I*3XEv)AYy;R) zjMdv4A;eEFY;eWX7HnJIk9meU7te2lC|0q6z>(Vf(EJ87_x<4Q_c30+QGAp)y^aZo`Dba{xchO@!=t1~+aV@~Nggg@xX$ojYD zf)Je(M(u-GJn%fTJ7NTxEL~x9G5h3d>25u9k>-z;R~^*1B^pW5cXS@78w{2r8^Vig z1A%vL*!--Z-wHX9H^$)BX7w@KG1Jxb&xKEWbm=2FVccbJ27`NqtVkY-xT9bY6HqI$ zU0TSRO~fiyd#@OH_&Da)BLfo=t5eUd?v8UlTh4zUlz`3SmJ)=2zebK*+b$cMjcbLF+M~nzn$vsoYN493bJ;@+IVH2VfoRuNvQYgP+kDjjq`~ z=1trfSiC`PtB;S4l9smOtKsdsTYXsc-xQqx#T>ez4*+Xa3gfsU*sTgcy>mk2egv^P z_h*7y$G3%)(z$2Q)U)H3(+D09vRu6*2=za=J_m|pC>(HDi&$fK7E66%T8|Cx^t(h4 z1SWIXxPSBP6d0Q@G6mjQe-Ml-39Nh2u(1F*z!kZm%lS70i5M^in;!w=IT{4W!MZiH zKy8DmnH&`7lS}9F6&kz+E5=>q3O8~zoT7n5*u;b1Q!ACw-0pGam2O9`!vznF z;s=-B4fF`jl2`_yE5g5_nvko6Y>aX;v`(?aka}yK9G8YB$d&7Qyox}9&4B$O#78OH zA@2?LL8udytyxj~YzJj{o6KI)0LREsP4bzDsy~~%(=o5;8&Zn_M;~;8M>qzgSD@n8 zV2Xdr<_IlOaOyKuLHx)6FYbZ#X6DfT4?vK93Z`lLCP5%;^4Y+5RIG_5j?mHfXePEz z3D5Xn5qswX5;l4;7}S|mK`=tr!gOu^5d$4tQ?!k* zYgSn3&q z1<75NlyRAM;<{=0*zRctXHqr+)w3U#3A0(YT8+uP2QlqnVjsFuYZ%sNv42H$Grkpi z7J<6@b>M4g`q&uI#{pI&VM}1cMe57<_C=>I02?|v!XpW%97rCdXb$Zd0NIi<%6MUF zAuGxzsS(GlF5QYA0|a0fKr(d-fxtRV9#aXk`X2`$K6mX?KewSiIkn_Lo8C2a+@3e> z58jJR8|GSrmZ6C5J_VcH_@HeEzPXXvVN~ab)t0mM*y;M^RCSRFQL}zL-s+^uRW+2ZDPBf*Rp%)(w|74-#m z)^dVtBr)JOT>#JT3%dU}gG)1zQ&$Z@FB>rS4sk0Uw6B5M(M{wikRDNkz|Rb34uAoB zgVMOOFoS$VxPbGK?cuV~K)3qmmszeJ7|Tximdu)b?*SE)2eCB2;yHl&kX)jhxY#f|R4kDOSYl}sMWWXX<1gXJ)v;?c&1JmyqO%;buWgV4q zxLwZ1@&@sbC=Uhe+Xi@NBS^tBvl;ibz;jeMM<7f*g7t#IIWhH@x_n4e8dGA+9Y&A8 zd1~<^W;ZDQ9@YJTl?fKTak-@3?ae;4M6dsIR;wCV$8RB$&5f~|?T)#_C=~J%^U1|1 zJ!F|3FF?&Q&7f&o`WOfEDJ5gTb`$Ps^@KDpEbBJH{FB;&zg9W+%2Jvgf#x}w!DR3( z$7Dbwr-6TgxO^Kn+Ce2Fj9ScV0hc$Q{FhDie&3fR#!^4Hv_YYj-GI}uWez7r#Q8D$ z#Fxcd(N8Dw{m}gUrmS~PO@|Z9xyWjtnKEMb2>Ndsnj^h5(#t(F2_0Pn_y!5eI#&xr z2UW!QGBa7FrRfsKl&@R~@zUT?CkfeV9y%H20;5%BYaOFzP&KKsp%HDvftJEna`3^) zLm-i+8hmjhT=J>{)}ehihfC_D{%%(T@y*cOA8cdPd&QErp1+Ey9SBDzCA!K+H&SrK z-6|h6{i|Ka_I_Xd*7j-HKr7}ph^4&etPdi4L$L7<4uW$4m# z!!<2Rpq{J`MaX~&1SLqCXcSU65}W?q zTa$)cPG*=4UQ#Jtj9>9qG;dnx-orux!u}z>OHG@zD25=N=w}ho%#oGby%OQBS}>Y5 zRrRD_H)OtAL#=cz;r-KhU0QMW47T97tGK{LYsR%(PbJyPwOld4Ct`&B28w;;)b)ytdLNJBaCnT?Z!6&bWCqUKl0?w>tvv3-=j^VcRsP!)2Bp!SUQ2X08G^)sWYN;$WBt}7M#*) zir@2Rk=ipOex^ggY0Nv+LPG3MyaP+e?dM}`Aw;n|0C^W#GHR|Csh9&xI48WMvqfvu zp#b~pVfT{S9U82HRoWx4p!l_n#Ww&B7tl>aUE<<3kX_MGmFK)1qN&Y#rki)M!f$oH z1MghZS27}t0})k?p+Lh17b1o@p2T=#GEHRxXoPcC27xKZX(o3vDyKOUW<9f%rP#Wk ztAKSj^O3+t7w3`3u zc~L9bE1Vsm$qV4%@|(}oA}67;%vOIgaSzaiFjq~3k{3P$;}zEP{_Hj`>l9Z*A~a+N zRvZCD)^M}3sso%$4!NaY52~XkLtlLIEax&r7kq|p*yZ2aK4`ZDAe0sI-U0mLTZf8o zJUMjV3C-$;OORCS3hgJ;v}!l5O6Yt7O_V-al=(-}MKT|oMidiQu%Lr>$AzM^imXPW z4rDNbs|Cv!NL>aEnqx~QU9R*m(kKZg64>x4*n%xE%%3iII0IqkRAoCMxZ9Ot2qZGWFfg>fEmsNR;s?AN5?fIazX*D~rxZ+6wJzvpxHS z{90qGvZB`CmZ(d`?4y77Ounp3^CHzmN^pMIBjhR4{8}2#*!oz&YjDpb&T*z_2{qUF z4x#8w$Z}gY2gN7<)tWCzI>o5LCYsnLQ&+Bw0HMbgVwRZ@8CGi^BmNeH7h_;dnuH1- zQm_(H(GntWG}ixV-UNJdV#sf~##|cCNH7FIF8>`=fTtNe9A{l0nzbOekZxKEZl&Sj zZmy#f_YAwrTPS0tIwq#F@iY&DwAJ)*vltTBzprI_OPo(-=S`nW4KWX8^AUT#C%Y*u zr^mGQx3?$ZC`3wwsBD>7vaFt10hA9)F*STPFZQ7sYOn_r~< z9*&1VSF!@wtqkFSbeBh*#?l5%dH#zkpWc@iEG@&S7c#1mWWXS;_(T}=)YE8PdML)4 zO8{NrHYGQ{Eiq|c0|NU1`*qnn-%4cTzaKIDS0j@8Fg$RJqGsa`xkzg#a;V-YkW`A| z4CIqgLy-guy5KFT$;BYZ^E#b1H#u8|SIIk?^GtWhOsAyh7ySQL(Mo;ZVT6qT4gJc% zxyPB)GvG}Y>J;^cH>Gre8@~6mBXqWu)3Db~kqQ%4CJO}!vuOMCg72eB!XEH|pQH9? z)Nycb$M*gKRI>(7)tf4VB2FITbL0(Sw%Z^#$@p$YAxJ|Vtn%g7{yezSr-Yz&8(RrM zd%ecc{c6Zu-Ow$2o>Q0{KS{2^ud&$5h=7xq(*B!}m#5^pDnjF3DpS7>O0mWFzFcrp zlC&#WkLnL5O1FYH`g@s!>4#l#9s(KK!nkRrVu%83hdhTP*2TCzV44{}BF$vaXw+i+ zT=St0Ek84rmhKp67#|ZAl-{4!OKUQ!@rUJXt&580Y>ha@Tt-RqxV;Xq0!o(t&tU14 zx{2$d+U9dL#8LaY33DXCn;9)%r}PfL1d{8kz@1#Qh4WO;P;o+rhAYE=C`$ zM>JzLSh~CQ2eE2;rVCz3#-f=8X$6U3lVbU zm2-+#Dg`RQLt^36-$}Q&h>DtC+I-$)a!Gw|!nb;RQ|Guo=XwRja@J~1#8qw@+npxp z>gXtvMx?B6BCRILuU^Uml;sWv_sJ|iSrB{hc(3~hm3znfKg>R}d=rP9Z#;!dH}&XT z2Qi(+9O!_yLMF#dWlSt;m2E-?M$xk9BCsF#7BP;d`&iU36nA_h8k?=k=7UShm{yfH z4mm4eo0T=CV)LyFRkE}!F=~bgqUV2>I%ocJ;Z`pxTB~Xr7r=5%D6`lax}xf5ZHp`r zh@4+@lEjXTu2q;gHmdFeav*-t8Bl~*%68QS;&x3{KdgA>t0Cj-l-gRgJhIku^jCL2 zcW%$|yuHZzWL$N9g-tqDAwuKQ&}^Fic+3{G#onzNPZ-`ugN(>M5!sR;)^@aLezI ziYpyoXK|~9P33kp!C4hm3Vjvcghyufsk=1Gkj!7nUtgV5x=&dW3q)($?$dRUk~#yQ z5px>@;p4xoRP}Cbx1J2HnlOIpTG!9+*kWOA(yUZMm1C}VIzcGb3JV5uePUaWC1O&& z2SW|Z=u5j)8Xu0|NL3!>vo<$QGh|k)gUci3MdUwKl+37aHUGnKPTASeK&X`I+84H0 zfX}&W*J{01GRDb6PUX7L67Go^lwfF3e@ImVh2WX+3Emmt=`{46sxQ2@;IN#O@!4t6 zG#INSC6WLg(7behg7ulPJ@9X{i6Zm{^Tk_zGuH$Yn0Nm|!s-jIdronuT+XLfvdPGDIaT9+FrFN>r!5JoL#cFv{7erDVeGgE@_MW*OD3<58qo9GjZgF#ofWoO~D|3xtJT%ATWc! zD(xpFlVi#vlBH@vZt>jXh%Yj~v5tw`r!uPrIEAu&Z5oBXjwbbuQM^!iT8Ba!onS}N z6<(AD8<`7IF4sXRR+zYthiF^5DI)r6qazh{{)O}-tFGqAMTt5zXi*O*5v5NI{s)0i zObC+xF;n`&ZSQxh=E4lG_SKccfZ7mz7lRXjreLWTu3AIUYBgZ%-od%}`b#DxM8WSh z8~!zC;2KnyG4|d#)7TS4+<5CG0n%R;FGo^(IVa?<#=34-*t+>jS9f<{KZk?J7G@T` zQTo>f9g5STsDh|L)*wItHBFMiVXf@bG=1MMOLS&S6ZWp1rnj$54TUce)vWCs_p z#6};U(5v>t%IlSuNuitaA=-JC39kPa{Mn0HfVUk*abN9)X6%xOVw)B<8EVD{fKM(o zTR(aK7YJgnE{Bl;={6I&RdD^kkMX9HuuZJu-`*1+>;Rr z8_7?MwO!TN-={{nIds`zvUjr{{Z8o`7wLPv?r$IeAo`6nD^0g<<@S(=Vy-FWCb7MJ zS$_XBzQ1~0s5uUOw8=rSKExPYp3Ng9wXrt`t;u$UKgl65^O4;Sx=IE`Nox1YI$knR z6uvvX=8vV211IS)_Yzw>908U$(-?rGF$^|g+tZ51X0Uo^yRBQHZz5QLFNq>VT{ro< z9Yzh&&)V?}ugN$)U5+*}kdB^DOl&q`>(kiJ+WEwG^LE{(9AB-+(5JSUv-64XSHi0g zPT0_woB`=xq;?L8%50aAo%;9-$*vrQvJ>VCbW|C{cy3Vh%x>{ux2G(l=fD7L9 za5!z5`v{$CtQQ`%@gMkT9Ce1opix*rT0)6LiLw*WaPd4qr>wcCu;C8pZ zSUewI?2EmMnen4b7livqw8qm;Z4W3xu7cV8dZTb8QeO7g$Sn-pHN|iY1ne0dQ|jqT zj?rP|-`Ak-`23va z{rJHyZxR2;z<%hslQ5Ker&v?VzHS*%j>6RpAnt)5W2+J5;u}7(q5~mFUd5krd5-b>^hX=qm}n)# z(1#QA#8fI5cy!Ml%|M1#31d|w0-X1M6j;AlW6PGh@_{ybfOM;3fZ7HmcrTHPCLoVB z>|2%8A@9MGJ5?T27bn$I419~f13UE=6BFz0x9hW} z3s6G<8(&of|O~;NY7Sk=wi9GL|DW za=bRncv7g81ir{(lC4>gfr}Qw8+%07qSQ%dYWtN3c_(FkQ|ft$4KdM(7g7Z1uY*c1 z5IG|&0syxIRsi*4!NklT8X_3=2yfR&A4!V@f~V)c3Xs8GfG8{*QGpA!JY~7(nX+P& z9|MKVmg&+?IT5IA_NJu;A84wr+dh?MH8=N91}M}xTH7byT83N6-^Sld8bXzo+{?)s z56r8n(9Sp!@K|r1XuH7O-lGsscPW8^d$WkNlurgA)Hu%C54;H+qqJHH^O;UO=MqbD zY!nezf*QgFTf|`dpM8>0sReEH@bO~eKHuAQ{2jo9RiwRiA`r2!G!MDrWJ#x~FC)r5 zF|lErDP>rR=+R-1>j^hOMMSJ{(O_t>ZQM`wHk%MM7)G%`H1)*ekXKx&e*Z#569mPH z&E0*Z|544seetylFGClO8U%BS=2Ur{c9H;aZ>UspeUe8&MmLu$smiY2AdaJzY=~8%|w8Xbs3bD zyvN*!CMldv(l`U^eCmD$tVI!OLDr~QaBeGo)cgt&p%ZaLMEpOm7|spvSWMBMR8%P{ znOUeMoPmK)31=Em{Gf0XKe%m~IwTlG%Gfh9*LFJheGB_zXXs_yro+5?gerH~KQ zFK-LG6=aUvD-ZlK^ss(Ik$>nw+(sVT(zgvI1w+XuCR%l848FvDQfD+~6q zmcm2x^2XO`NR*M3RUsQfxDqT_-6ksZ1q}pmq5Vs+uuyac(m+-lwKWG*VPu1rE5X7pV`ZjiGhJTGFxYxXdP=Im z7e@_<(fg-bS_FFy_Y0{&kyf?q5%A^+P^Y4T=ekKJ@b!4 zX|tCOtgjK^KSi~K(c@<1b)4-nX;QFnn=>(R?tly`LcwfkWqJ7c190)h4XXYbjo=Hd zDC!dUIjFzHW9+R?Eu}WuOQhBC#!%|7-ef#;kG1gH?3loFl6T_FS9@u8q~b^ zPRFjN?0Pa2tv=6S>yRdq_~eA$ZPUOkpp`QvjvrMLmWy)RH@n+-Ur*$@;ra<)jIQKz zuS@}Uxb026?pW}r9~8DXPk1gACA}rU^KA$Pb1R&7bx0IsAyUevqy=!?lK_MM0_$5!he_u4=^tjyKw8#EWv z3MOZ5&=Rb+`hFb@qS^*fF#~7;w2)qL@rhrs@(az!`l{Zd?StU~_xmaH^zZoJ<&h-A zf=x3|^upZ#(^ z0H5R@3Xt+{*b#WbFu;|Pgf80wz&apNKlAFrhbQm2U&8)}mz`J-HdtmU4lxY(Q9R2O zpg}PKJ$&EJ9k*bNQ2%ezr}&Q}i`G)_PTAWGz11$uX734`^A{}Y!nLt{V#l)KO@V7*P+@?0RNzhPb*B5~sF}wXK?b-@`qXGMM zi^U9dWvi*kVnY{9aLO0D%JX_uV_s>$583tmh$d(5?lfbf$>2`oJcgomXzks?n>$=# z@)dg1S%PVP%*ULy0K|?VEM>g$(9-??rqGONSpG{8)r4QXUeV*cB&xp$@jt>e{T=~! zDe+UZ_IH9~88blluDx-%w`8OW-}@Pc-t7lRyjkaU?rZdJb+miTJfJQKQqqZII4}x? zD60=Q{(Toq6ZVY+sgfjR%F#6_GR3^=5rcEjS{wx#FkSy1jI3{vtp|v`z05e&OkWP> zz#dJkBsz({p#`3W#>)<2^$sreH)-I#Xw)8Lb8C0{GwGb#FY=|g1IOV#69|)SH~O~t z#t!@>eL(cWS$QyME>$2Ej63YEahOm1@k}jb)H~$Zsle? z&7ku0J$d#0MBH2Yc=w^D`nTinc7xlk)d!eQH~!1;5%tZC-t*_)J*Z%o*F~}>{!06% z@6EfbYv6r|aUqJqs=mJ{%avArhyzUbQL7dAz3SohdymI{*tEP%?>%4ZOfJ4o?-88~ zw})vsMY}`l^GwhbAOws??iWNVDJo@L zV+3e-Web$9gQBs6%9VqmBRwmeJBBer>_IM`0||;%8+$Ey>={*ao3%ULG@i`L2eBUp zW9{(?LQ7{IWF>W`3V8#>RoG_9h3BFjipO=~W`aBc(Glo=^GDafQKKL1H$^JQUT7C% zwEf&oAHr-Q2MnLTHl0>DU+rEX%k!9*1NvR&+rn4D>q@JV#MR5+p}X)m`El>J9)ajV z_ivT_s@W~Qx_g7lG`N_Ird2e)Z>~O1T&uCC6 z0VBd{mn)>_`COUXRDK~ju`AK;0RKg>Hm8r&FN#E}|9sf%91jL+kSrd?xm*vf| zF^L#9CL+b67?_tAs-VREyI)E>$F_(tp6T797f&Xhgd?@5RIisbrdkMV7%jTYq`E!r zP>Ypy{z+9^`u@I4RQ_pITjsu%a#jAns=Du;^rzCxA}A zZE0aaqkt2`&L?hOn+ zcOo*SB3=X|H6}|gzvDbwJrOW*YW74!h09rE4i-;jGdY4C+_l3{EX*(4*lsE$%Hpmg zggXKD(0Om2?A^uT41D_B*H*BIp9A^soCuL!2EkBL4Xa4$}F!# zznMmwcA;zC@HHM}5rX5GYDYGpBZ>Kf_~66Xkc2d(Qewp6Jhx>`p>yVb|11+J5@WKZn@(AO47VhzZIGhA?PzKMz8B8W221PXk1@O5OwGZyX?AmzxcM zpfTR5FVc+$As|XH5wI9?oB7n-lE2*j!$4nZW@I4M3=|btaRP!r%z1zp0x$~zcchXtDd}${UJb2B zKqGIOmoUR<+-hfsd4nrR`4cgw<2HORX|-mld8W@8O7=F%qW@ zQCW~bk3d1keWmwIrf$rO9HJNYOkxq(I?--o2xz!7iR%PxsP|xT#yxmVXRxm3g9btq z#F$}?rab$s&K=&`=pCV;I31LOABLdy`KGr&T4*R0$~A9@#2J03qg_ce^v|?D?R5yD z4|F{pl(3u(rV)-H`TQN1{}#9S-&C%jMu@-)D5$fc=B*$h<333@9ziLLP3uFA2dt~Q zHI)KhfXaAjxd*KDjJ}(*xTdoMii*_>+8lOo0dbuDg5zyrWf79tdhKC4{97T zNA#Fcc`hUYfvq+YtRp-|5qaFnBo!1*VPd2tCz@eegrglXO^RAvKar0VO(gs#;{dQG zwDe|_08TuKBw0O zTVazI+~LsS(b#m;0NDvqAs&;HNDPc0l+m~w6kVd1`r(bL%)G5`1j}&kUhx23ii^j+ z+1LxtUfv;E+Iq!S-qOj0&`AU~J`PSlVXuC5uh67{V^cp5*scW)aoe~v4xh2VZ-3|X zI`O%ZpX@)J_mHCMTod2>1?n+DV4a&#t_+?*(87G}r`VFxaq7tjNpPOQ)Q7Om{_ZIY zp-(Amkk0QN_fx2ufV@M#5_!te-vKddyAMHpLDqjebiw72+HiA1ulDwz2JNiqyNXig z2^}@Uqt7>4;PUjpgLO$jdzs80=HL!h{-25e$Y-iPC?Y-E{mrp?%Kz#gx_q9V-xPY` zCtJvN;l@99H{$ku4xd|JA=JiDUYa%~r&X3CpIy0%Z^7(;N z+0}Eyvu8|sTSY&cVW!|7ek|5vro?aB-m z?=60R=CQ(?J$3(UFX9PJYCIhMS??YrN8%dx$V&zJxH zeQtHa=9@n^B=VRPJ(G{H@@Q9I<{tC;%<{W}-Ex2S3cKa}Ivi&o%y{G7qo>vroIk2{ zaL)dvD`E6#NzUoM;*ulVGfWG3dqgOO)aS`NDc4?=@MaJ1FKPF*m=N%Zv`U*0}C4i0}qN0Um&kI zwWK67FCDx}8(n8(=Vqg~Ks5(|?h!@NDGwC!bq#UU_4ISo&rQtBOiL{WAG3#U1gmRF zCl@ONLx3QKv)1G2qp7@{?1KJ$xPJG z%uP&BHPkD}OGmd8{S-ii0WGyCX9A*YL|?y-(8xR=c{O{0H!CnK85r1sa0W1B6VHHn E0J~{iMgRZ+ diff --git a/docs/en/assets/em002-2/md/README_template.adoc b/docs/en/assets/em002-2/md/README_template.adoc new file mode 100644 index 0000000..6b85c07 --- /dev/null +++ b/docs/en/assets/em002-2/md/README_template.adoc @@ -0,0 +1,72 @@ += README Template +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +== Project Title + +A brief description of what this project does and who it's for + +=== Features + +* Light/dark mode toggle +* Live previews +* Fullscreen mode +* Cross platform + +=== Documentation + +https://linktodocumentation[Documentation] + +=== Installation + +Install my-project with npm + +[source,bash] +---- + npm install my-project + cd my-project +---- + +=== Usage/Examples + +[source,javascript] +---- +import Component from 'my-project' + +function App() { + return +} +---- + +=== Screenshots or Demo + +Insert gif or link to demo + +image::https://dummyimage.com/468x300?text=App+Screenshot+Here[App Screenshot] + +=== Support + +For support, email fake@fake.com or join our Slack channel. + +=== Contributing + +Contributions are always welcome! + +See `contributing.md` for ways to get started. + +Please adhere to this project's `code of conduct`. + +=== License + +https://choosealicense.com/licenses/mit/[MIT] + +=== Roadmap + +* Additional browser support +* Add more integrations diff --git a/docs/en/assets/em002-2/md/README_template.md b/docs/en/assets/em002-2/md/README_template.md deleted file mode 100644 index 8e51f4c..0000000 --- a/docs/en/assets/em002-2/md/README_template.md +++ /dev/null @@ -1,62 +0,0 @@ - -# Project Title - -A brief description of what this project does and who it's for - -## Features - -- Light/dark mode toggle -- Live previews -- Fullscreen mode -- Cross platform - -## Documentation - -[Documentation](https://linktodocumentation) - -## Installation - -Install my-project with npm - -```bash - npm install my-project - cd my-project -``` - -## Usage/Examples - -```javascript -import Component from 'my-project' - -function App() { - return -} -``` - -## Screenshots or Demo - -Insert gif or link to demo - -![App Screenshot](https://dummyimage.com/468x300?text=App+Screenshot+Here) - -## Support - -For support, email fake@fake.com or join our Slack channel. - -## Contributing - -Contributions are always welcome! - -See `contributing.md` for ways to get started. - -Please adhere to this project's `code of conduct`. - -## License - -[MIT](https://choosealicense.com/licenses/mit/) - -## Roadmap - -- Additional browser support - -- Add more integrations diff --git a/docs/en/em002-1.adoc b/docs/en/em002-1.adoc new file mode 100644 index 0000000..1a27c12 --- /dev/null +++ b/docs/en/em002-1.adoc @@ -0,0 +1,557 @@ += Em002-1 Practical Guidelines for Open Source Software in the Federal Administration +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +== 1. Use of these guidelines + +Under Article 9 of the Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), the Confederation is required to disclose the source code of software that it develops or commissions for the performance of its duties. footnote:[SR 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/de] The DTI Sector of the Federal Chancellery has derived overarching objectives from this legal mandate in the Strategic Guidelines for Open Source Software. + +This document serves as practical guidelines on the legal and strategic requirements. It is designed to assist federal administrative units in the use, procurement and release of open source software. It provides all interested parties with a comprehensive overview of the subject and refers to additional information in the other resources. + +However, depending on your prior knowledge and needs, you may wish to read the guides selectively before moving on to the other tools. The following outline will help you find the appropriate starting point. If you are unsure, it is recommended that you read through the guidelines first. + +=== Intention / Stakeholders + +General introduction to open source software + +* Section Definitions +* Section Potential and challenges +* Section Findability of OSS solutions +* link:em002-5.adoc[Em002-5 OSS Tools information sheet] +* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] +* link:em002-6.adoc[Em002-6 FAQ about OSS] + +General introduction to EMOTA for decision-makers + +* link:em002-5.adoc[Em002-5 OSS Tools information sheet] +* link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] + +Procurement only of software to be used + +* Section Maturity levels for OSS in the Federal Administration +* Section Use of unmodified open source software +* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] +* Software Procurement and Art. 9 EMOTA information sheet [KBB-MB] +* OSS in Procurement guidelines [BBL-WL] + +New IT development and release + +* Section Development with open source components and release of source code +* Section Collaboration in open projects (contribution) +* link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4.adoc[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] + +Procurement of created software (service or work) + +* Section Maturity levels for OSS in the Federal Administration +* Section Development with open source components and release of source code +* Section Collaboration in open projects (contribution) +* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] +* FOBL toolbox, including the Open Source in Procurement guidelines +* CCPP public administration learning and template platform (www.perimap.admin.ch) including Software Procurement and Art. 9 EMOTA [KBB-MB] +* OSS in Procurement guidelines [BBL-WL] +* link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4.adoc[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] + +Legal clarifications for release + +* link:em002-6.adoc[Em002-6 Frequently Asked Questions about Publishing OSS (OSS-FAQ)] +* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] + +Working principles for project managers + +* https://www.hermes.admin.ch/[HERMES documents] +* link:em002-5.adoc[Em002-5 OSS Tools information sheet] + +Contributions of software to third parties and collaborations + +* link:em002-4.adoc[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] +* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] +* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] + +The following diagram gives an overview of the documents relevant to OSS in the Federal Administration. + +image::./assets/em002/media/image2.png[Overview of OSS tools in relation to Art. 9 EMOTA] + +Figure 1: Overview of OSS tools in relation to Art. 9 EMOTA + +== Definitions + +[cols="1,3a"] +|=== +|Open source software +|Software is considered open source software (OSS) when it is published under one of approximately 80 licences recognised by the Open Source Initiative OSI [OSI2019]. Specifically, the definition of open source sets out ten criteria that all open source licences must meet _[PE1999]_. These can essentially be summarised in four points: + +. The software may be used for any purpose. +. The source code of the software is freely accessible. +. The software may be copied and distributed without restriction. +. The software may be modified and distributed in modified form under certain conditions. + +|Free software +|Before the term 'open source', the Free Software Foundation (FSF) introduced the concept of 'free software' in the 1980s. In essence, free software meets the conditions of open source software, but aims to ensure that the software is always freely accessible and, wherever possible, is not integrated into proprietary software. footnote:[See: https://en.wikipedia.org/wiki/Free_software] + +|Proprietary software +|With proprietary software, a supplier develops software and sells a usage licence to the user. Generally, the user does not know the software code and may not redistribute or modify the software. They can only use the software according to the licence terms (e.g. End-User Licence Agreement, EULA) in return for payment of licence fees. For example, the software may be authorised to be used by only a certain number of users or a certain number of processors. footnote:[See: https://en.wikipedia.org/wiki/Proprietary_software] In return for the usually annual maintenance fees, the supplier commits to fixing errors within a reasonable timeframe and to continuously developing the software. + +|Licence +|A licence is a document that contains binding guidelines for the use and distribution of software. In the case of open source, licences that comply with OSI are usually used. footnote:[See: https://opensource.org/] + +|Community +|A community in the context of open source software is broadly defined. It can be a loose ecosystem or a structure with governance that develops the software. The document link:em002-4.adoc[Em002-4 OSS Community Guidelines] covers this topic. Community members can jointly manage the product, develop, test, translate, provide feedback or simply use the software. + +|Third-party rights +|Even with open source software, protective rights may exist (copyright, trademark law, patent law) and can be asserted by third parties, e.g. when using source code created by third parties. + +|Exceptions under EMOTA +|Exceptions according to Art. 9 para. 1 EMOTA include third-party rights and security-related reasons. Both are covered in Section 3 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. + +|Source code +|In computing, source code (or source text) is the human-readable text of a computer program written in a programming language. footnote:[See: https://en.wikipedia.org/wiki/Source_code] + +|Publication +|Publication primarily refers to the release of the source code under an open licence according to OSI. For practical reasons, this usually also includes documentation and automated instructions for building the application from the source code. Automated tests and test documents are also typically included. To enable a community to develop, a platform is used that then takes on several functions of a development platform (build, test, support). + +|Digital sovereignty +|We use the definition from the FDFA's Digital Sovereignty Report [St2024]: 'Digital sovereignty of a state or organisation necessarily includes complete control over stored and processed data as well as independent decision-making about who may access it. It further includes the ability to independently develop, modify, control and supplement technological components and systems.' + +|Repository +|A repository is a storage location used by a version control tool for files and metadata about the code base. Repositories allow multiple contributors to work on the same files and store different versions. Most also allow issue tracking, release management, automated builds and documentation. + +|Fork +|A fork footnote:[See: https://en.wikipedia.org/wiki/Fork_(software_development)] of an open source project is the process of setting up an independent development of the original project. + +|Contributor Licence Agreement (CLA) +|A Contributor Licence Agreement footnote:[See: https://en.wikipedia.org/wiki/Contributor_License_Agreement] is a document that describes the conditions under which intellectual property can be contributed to a project or venture. + +|Source code management (SCM) +|Source code management footnote:[See: https://en.wikipedia.org/wiki/Version_control], also known as version control, is a tool that effectively manages changes and version numbers, particularly in software development. The free software Git footnote:[See: https://en.wikipedia.org/wiki/Git] for managing distributed SCM has become established. + +|Open source software development (OSSD) +|In open source software development (OSSD) footnote:[See: https://en.wikipedia.org/wiki/Open-source_software_development], in addition to publishing the source code, the entire development process is carried out publicly. Everything from requirements (issues) to source code is transparent. OSSD is supported by public communication tools (mailing lists, forums, etc.), a version control system (git), bug and feature lists, roadmap and developer tools. + +|Software Package Data Exchange (SPDX) +|Software Package Data Exchange (SPDX) footnote:[See: https://en.wikipedia.org/wiki/Software_Package_Data_Exchange] describes a standard format for Software Bill of Materials (SBOM) with the aim of facilitating the correct handling of free software or open source software. + +|Copyleft effect +|If software is under a licence with a copyleft provision, any modification or extension of the source code must be released again under the licence of the modified open source software (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). +|=== + +== Potential and challenges + +There is enormous potential for open source software in today's world of IT. At the same time, the use of open source solutions also brings challenges. These two sides are explained in more detail in the following section. The information is based on, among other things, the results of the Open Source Study Switzerland 2018, 2021 and 2024 by the University of Bern, in which respondents provided information about the recognised advantages and disadvantages of open source software. + +=== Potential of open source software + +The following points describe the potential that can be realised when using and releasing open source software. + +[cols="1,3a"] +|=== +|1. Digital sovereignty +|This involves the ability to use and control digital services. Digital sovereignty extends over the entire lifecycle of a digital system. Open source software promotes digital sovereignty, as it guarantees interchangeability, design flexibility and influence. footnote:[We use the definition from _[St2024]_: 'Digital sovereignty of a state or organisation necessarily includes complete control over stored and processed data as well as independent decision-making about who may access it. It further includes the ability to independently develop, modify, control and supplement technological components and systems.'] + +|2. No licence fees +|There are no licence costs for using open source software. However, when obtaining complex standard open source software packages, it may make sense to purchase support subscriptions, for which a fee is paid. + +|3. Cost savings through cooperation with other users +|As software under an open source licence can be used and further developed without restriction, costs of further developments can be shared or existing additional developments from other administrative units can be adopted according to the principle of 'develop once -- use multiple times'. At the same time, there is the opportunity to benefit from the experience and developments of others. + +|4. Community building & knowledge sharing +|Open source software facilitates community building and knowledge sharing, for example between the different federal levels in Switzerland. Software can be jointly further developed, errors fixed and individual experiences shared. The increased exchange of knowledge between different administrative units leads to a better understanding of what others are working on, so that duplication is avoided and the best solutions can spread. + +|5. Lower dependence on manufacturers +|Vendor lock-in (dependency on software suppliers) is considered very high in computing. Using software under an open source licence reduces vendor lock-in as operation, maintenance, support, further development and other services for open source software can be openly tendered. Instead of completely re-procuring an entire system due to vendor lock-in, extensions or lifecycle services for an OSS solution can also be put out to tender separately. This can save significant migration costs. + +|6. Open standards and interoperability +|With open source software, compatibility with other software solutions and IT systems (interoperability) is generally higher than with proprietary software. Open source solutions also use almost exclusively open data formats, which is why they can be easily exchanged with other systems. + +|7. Transparency about the structure of the software +|As the software is also available in the form of source code, its quality can be checked, for example, through external reviews. In addition, documentation can be created based on the source code (e.g. with regard to new tenders for further development services or the replacement of open source software at the end of its service life). + +|8. Security and trust through transparency +|Because of the open nature of the source code, the security of open source software can be higher than that of proprietary software. Moreover, it is much more difficult to build backdoors and other loopholes into open source software, which leads to more trust in the software. + +|9. Higher quality and modularity of code +|The quality of open source software can be higher than proprietary software because the motivation to write good code may be greater when developers know that their source code will be published. In addition, open source solutions tend to be highly modular, so that individual modules can be easily replaced and the remaining modules can continue to be used. footnote:[Another aspect of security is that it is easier to document the libraries used (including dependencies) than in proprietary software. This in turn means that when vulnerabilities occur, they can be quickly identified and fixed (see also SBOM).] + +|10. Easy customisation +|Access to the source code allows users to make further developments themselves or through external suppliers. This means the software can be quickly adapted to their own needs. + +|11. Rapid innovation and integration +|There is rapid, continuous further development of open source software by the community. For example, new technologies and data standards are often published as open source programming libraries. This enables the rapid realisation of innovative software solutions. + +|12. Employer attractiveness +|The use of modern open source technologies and informal collaboration with international communities promotes employee motivation and thus increases employer attractiveness, which in turn facilitates the recruitment of young, qualified professionals. +|=== + +=== Challenges in dealing with OSS + +The following describes the typical challenges encountered in practice with open source software and outlines some possible solutions. We do not address general challenges that affect all software at this point (e.g. the need to check for cybersecurity and the need to secure appropriate support for critical software). + +[cols="1,3a"] +|=== +|1. High switching costs due to existing dependencies +|Replacing proprietary software with open source solutions can be very costly if the application is closely embedded in the existing IT system through interface integration or other dependencies. These switching costs mean that introducing open source software often only pays off at the end of the proprietary software's lifecycle. + +|2. Missing features or no suitable open source solution +|When procuring standard software, it may happen that there is no open source software alternative to the (previous) proprietary solution, or only one that is functionally inadequate. As a solution approach, there is the possibility of jointly developing the missing features together with other users of the open source software and adding them to the open source project. footnote:[Project or application managers are responsible for such new features. The project determines exactly how this is done. Em002-2 and Em002-4 help with detailed decisions. Depending on the size of the feature, it may not make sense to go through the instructions in full. Procurement law aspects for resources must be observed.] + +|3. Higher integration costs +|Short-term cost savings resulting from licence savings when using open source software are often offset by higher integration costs. Therefore, it is important to recognise that the professional use of open source software is not 'free' but actually generates internal or external costs. + +|4. Unclear responsibilities and support +|Open source software is often criticised for the lack of support and maintenance by external companies. However, there are now a variety of suppliers offering commercial services (long-term support, ongoing maintenance, further development, liability and warranty, etc.) for open source solutions. The different business models with open source software are explained in Annex D and the different support models in Section 8. An up-to-date overview of open source service providers and their services can be found in the Open Source Directory (https://www.ossdirectory.com) or in the OSS Study 2024 footnote:[See: https://www.oss-studie.ch/] _[OSS2024]_. + +|5. Small market with few suppliers +|As certain open source applications, such as desktop applications, generally require little or no support and maintenance, there may be little market for open source providers of support and maintenance. In this case, a tendering process for open source software services can help to create a market that increases competition between suppliers. The existence of a broad development community for the software in question and the quality of the development documentation are of practical importance when tendering for such services. + +|6. Low visibility +|Communities of open source projects focus primarily on product development and rarely on marketing. In contrast, manufacturers of proprietary software invest heavily in marketing and selling their products. This lack of advertising for open source software often creates the false impression that there is no alternative to proprietary products. However, there are platforms such as alternativeTo footnote:[https://alternativeto.net/] that provide an overview of solutions for specific tasks (more on OSS alternatives in Section ). + +|7. Lack of acceptance by end users +|Due to different user interfaces, missing functions, low user-friendliness and little advertising for open source software, there is a lack of acceptance by end users for certain open source products. Appropriate communication, documentation and training offerings can counteract this challenge. The fact that open source software can be further developed according to users' needs can also lead to higher acceptance. + +|8. Little or no in-house expertise +|Open source solutions evolve rapidly and at the same time require in-depth technical understanding. Thus, it may happen that internal employees have little or no expertise with certain open source software. In-house OSS know-how can be built up through further training and opportunities for self-study via online sources and building in-house wikis, etc. + +|9. Difficult future assessment +|It is often difficult for outsiders of an open source community to recognise how the project will develop in the future. Therefore, it is important to be able to make a realistic assessment of the future development of an open source solution. In this regard, Section Fehler: Verweis nicht gefunden introduces the Open Hub platform, which allows an assessment of the activity and heterogeneity of the developer community. This makes it possible to better assess the future development of an open source project. + +|10. Legal uncertainties +|The multitudes of different open source licences and small number of court rulings on interpretation issues to date can sometimes lead to legal uncertainties with open source software. These practical guidelines are intended to provide an overview of the most important open source licences and their characteristics and compatibilities. Sources for in-depth answers to legal questions can be found in the documents link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and in link:em002-6.adoc[Em002-6 FAQ on OSS and Art. 9 EMOTA]. + +|11. Too extensive offering of open source software +|The number of open source software products has increased dramatically in recent years. Potential users of open source software therefore complain about the multitude of existing open source solutions on the market. For this reason, the section 'Findability of...' introduces two platforms, alternativeTo and Open Hub, which enable a comparison of Open Source solutions. + +|12. Coordination effort involved in collaborative development +|When the Federal Administration participates in and contributes to collaborative projects, this results in a coordination effort within those collaborations, but also when a community needs to be brought on board. Ideally, this additional effort should still be worthwhile thanks to an improved solution, greater acceptance or increased participation from third parties. +|=== + +== Constellations for using/working with OSS + +=== Maturity levels for OSS in the Federal Administration + +When using and developing OSS in the Federal Administration, there are various constellations regarding the obligations related to open source licences: A typical maturity model footnote:[Maturity model based on https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels] for introducing open source into organisations can look like this: + +. Denial -- No or unconscious use of open source software +. Consumption -- Passive use of open source software +. Participation -- Engagement with open source communities +. Contribution -- Pragmatic contributions to open source projects +. Leadership -- Strategic involvement with open source to drive business value footnote:[Creation is not mentioned, as Art. 9 EMOTA directly requires this.] + +[options="header",cols="1,2a"] +|=== +|Constellation |Impact + +|The mere *use* of existing open source software (without modifying the code). +|There is *no obligation* to share the source code. + +|The *completely new development* of software that is be published under an open source licence. +|*In this case, there is complete freedom regarding the licence under which the software is published.* The document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] should be used for the Confederation. The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. + +|*Further development* (internal or external) with existing open source components (with or without copyleft effect footnote:[Explanation of the term 'copyleft' in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]]), as long as the software is used *exclusively within the same organisation* and not redistributed. +|The OSS components can be combined with third-party components as required. There is generally no publication obligation from the licence, as long as the software is used exclusively within the same organisation and not distributed (exception: AGPL). Since it is not legally conclusive how far the concept of 'distribution within the same organisation' extends, this scenario only applies in exceptional cases for OSS components with copyleft effects. In these cases, consult your organisation's legal department. See link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-6.adoc[Em002-6 FAQ about OSS and Art.9 EMOTA]. The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. *As there is a publication obligation under Art. 9 EMOTA, the changes must be re-released. The easiest way is as changes to the existing open source project.* + +|*Further development* (internal or external) *exclusively with* existing open source *components without copyleft effect*, if the software is to be distributed externally (e.g. to cantons). +|The OSS components can be combined with third-party components at will, and there is no publication obligation from the licences (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). *However, release is mandatory within the framework of Art. 9 EMOTA. Ideally, the release should made be via the existing project (no fork).* The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. + +|*Further development* (internally or externally) with existing open source components *with copyleft effect*, if the software is to be distributed externally (e.g. to cantons). +|*There is an obligation to publish* due to the copyleft licence (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] regarding the copyleft effect). The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. + +|*Contributing* to an existing open source project. +|*There is generally a publication obligation according to EMOTA. The governance and licence of the project are used.* The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. + +|*Joint development* of a new or existing project with a community and cost sharing. +|*There is generally a publication obligation according to EMOTA.* The documents link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] are used *to set up the project and its governance.* + +|*All variants of development or further development* are carried out *via a supplier or commissioned third party.* +|*There is generally a publication obligation according to EMOTA.* Based on link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. If possible, the prerequisites for publication should be established during the procurement process and, if necessary, the requirements for software approval should be communicated to the supplier/third party. +|=== + +=== Use of unmodified open source software + +When using open source software, it is generally not relevant under which open source licence it is published, as all open source licences (see Section 2 'Definitions') allow the unrestricted use of open source software, regardless of how many workstations, simultaneously logged-in users, number of servers and processors, etc. the software is used on. + +When using unmodified open source software, *no publication obligations* arise even for programs that are under a licence with a strict copyleft effect (exception: AGPL licence, Affero General Public Licence). + +As long as open source software is introduced and operated by internal federal service providers, this can be done *without a public procurement procedure*, because "the OSS licence alone generally costs the procuring entity nothing and is therefore not relevant to procurement in itself." + +If an external service provider is commissioned for maintenance, support and other services for the open source software, the requirements of public procurement law must be observed. Different support variants are described in Section 9. It is also important to use appropriate suitability and award criteria when procuring open source software. The basis for this is explained in Section 8. + +=== Development with open source components and release of source code + +With the publication obligation according to Art. 9 EMOTA, the procedure described in -2 link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] should be followed here. +The documents link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must also be consulted if necessary. The goal is to release the project in a controlled manner using the three checklists _link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1], link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2], link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3]_. + +=== Collaboration in open projects (contribution) + +Possible considerations for the Federal Administration's contribution to open, already existing projects are listed in the BITKOM guide _[BITCOM2024]_ Section 4.2. footnote:[See https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html in, Section 4.2.] Depending on the importance of the project for the Federal Administration, it should be examined how much responsibility the respective office wants to and can assume. + +Collaboration in open projects and direct development in open projects can also take place using the documents for release. The focus is on link:em002-4.adoc[Em002-4 OSS Community Guidelines] and the associated checklist _link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]_. + +== Properties and selection of open source licences + +The properties and selection of open source licences are described in the document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. + +== OSS procurement + +Strategic issues relating to procurement and OSS are dealt with in link:em002-7.adoc[Em002-7 Strategic aspects of procurement and open source software]. + +The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled _Software Procurement and Art. 9 EMOTA https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ as well as two documents 'Sample criteria -- EMOTA procurement and open source' and 'Sample contract texts -- software development'. + +Further assistance is available on the https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[FOBL intranet] (accessible only on the federal network) with the https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf.download.pdf/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf[_Open Source in Procurement Guidelines_] _[https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf.download.pdf/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf[BBL-WL]]_ and the https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx[_Checklist for Art. 9 EMOTA Blanket Exception_] _[https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx[BBL-CL]]_. + +The enterprise readiness of open source can be found in the document _Selection Criteria for Enterprise-Ready Open Source Software [Gu2024]_ footnote:[See _[Gu2024]_] or in the Bitkom guide. footnote:[See https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software[Best practice recommendations for open source software | 2025 Guidelines | Bitkom e. V.], Section 3.3] + +== Findability of OSS solutions + +Various platforms allow interested organisations to find and analyse open source software before use or procurement. The resulting data provide a basis for deciding on the use or procurement of open source software. + +A compilation of minimum requirements and possibly a market analysis should serve in any case. + +=== OSS Catalogue + +The federal authorities are required to publish the source code of software they develop or commission for the performance of their duties. The OSS Catalogue footnote:[https://www.opensource.admin.ch/] lists all software developed by federal authorities since 1 January 2024 and released as open source. It provides an overview of available software and makes it easier to find and reuse open source solutions. + +If a new repository or organisation is created, it should be reported for inclusion in the OSS Catalogue by email to opensource@bk.admin.ch. + +OSS Catalogue: https://www.opensource.admin.ch + +=== OSS Directory + +The OSS Directory operated by CH Open footnote:[https://www.ossdirectory.com/en/home] makes it easy to find qualified providers offering professional support for open source software. + +Open source providers use success stories to show which users (customers) they have helped implement specific open source products. +The Directory also features current open source news from existing platforms, curated top news, events, communities, job listings and knowledge-sharing articles. The OSS Directory is available in German, English, French and Italian. All entries can be added and updated directly by registered users. + +OSS Directory: https://www.ossdirectory.com + +=== alternativeTo + +A practical tool for finding alternatives to software is 'alternativeTo - Crowdsourced software recommendations'. footnote:[https://alternativeto.net/] As the name suggests, the alternatives and their ratings have been created through crowdsourcing, i.e. the input of many individual users. alternativeTo distinguishes four types of software solutions, of which only the first is considered open source software in the sense of Art. 9 EMOTA: + +[cols="1,3a"] +|=== +|Free open source +|Software that is published under an open source licence. + +|Free +|Free software (freeware) but whose source code is not freely available and may not be modified. + +|Freemium +|Such software offers a free and a premium version, with all important functionalities already available in the free version. This category does not include software that can be tested free of charge for a certain period of time (e.g. a 30-day trial version), which falls into the 'Commercial' category. + +|Commercial +|This is proprietary software for which licence fees are charged when used. +|=== + +=== Open source repositories + +Currently, the world's most popular open source development platform with over 30 million users and over 100 million source code repositories is GitHub. footnote:[https://octoverse.github.com] Today, practically all IT companies, especially manufacturers of proprietary software, as well as many other types of company and organisation, have a GitHub presence. More and more public authorities -- about a dozen from Switzerland footnote:[https://government.github.com/community/#switzerland] -- also publish their own open source software on 'GitHub and Government' at https://government.github.com. This process can also be carried out with other repositories. + +Examples of other repositories are: + +* GitLab +* Bitbucket +* SourceForge +* LaunchPad + +On GitHub Insights, numerous relevant statistics of an Open Source project on GitHub can be read: + +[cols="1,3a"] +|=== +|Pulse +|Overview of the recent activities of an open source project on GitHub: Summary of the most important information about development intensity, community heterogeneity, open reports, improvements (pull requests), etc. + +|Contributors +|Display of which developers have been active and when. This is an important indicator of whether everything depends on one person or whether there is a larger community behind it. + +|Commits +|Display of which contributions were made to this open source project in which time period. + +|Code frequency +|Visualisation of how much source code was added or removed and when. + +|Dependency graph +|Dependencies of the open source project on other open source software (e.g. relevant for identifying security vulnerabilities and updates). + +|Network +|Display of when which developer contributed to which development branch. + +|Forks +|List of all copies of the open source project on GitHub. Indicator of the popularity and distribution of the open source software. +|=== + +=== Open Hub + +If information is to be collected on an open source solution that is not necessarily developed on GitHub, Open Hub by Black Duck is a good option. footnote:[https://www.openhub.net/] A wealth of important information is clearly summarised for around half a million open source projects: + +[cols="1,3a"] +|=== +|Project Summary +|A brief description of the open source project. + +|In a Nutshell +|The most important facts about an open source project, such as the number of commits, contributors and lines of code, as well as the most used programming language, the time of the first commit and last change. In addition, an assessment of the code base and the size of the development team is listed (e.g. 'Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits'). + +|Quick Reference +|Contains information about the organisation, links to the project and the code, as well as references to similar projects. + +|Licences +|Indicates the licence(s) under which the open source project is licensed and what consequences are associated with it. + +|Project Security +|Provides information on the security and vulnerabilities of the open source project. + +|Code +|A graph showing the number of lines of code over time, broken down by programming language. + +|Activity +|A graph showing the number of commits per month. A summary of the last 30 days and 12 months is also provided. + +|Community +|A graph showing the number of active contributors per month is displayed. A rating of the project is also displayed on a five-star scale. +|=== + +Open Hub also allows you to compare different open source projects. footnote:[https://www.openhub.net/p/_compare] This quickly provides an overview of which project has the most active community, the longest development time or the most suitable licence. + +=== Special code repositories + +Larger organisations have their own code repositories. Particularly noteworthy is, for example, the German repository for authorities opencode.de. footnote:[https://opencode.de/en/home] Repositories from other public administrations are of particular interest here. + +== Support models for OSS use + +Open source software already available on the market can basically be used in three ways: + +. Use without professional support +. Use with internal support +. Use with support from an external supplier. + +These three types of use and their advantages and disadvantages are briefly explained below. Which of these scenarios makes the most sense in a particular case must be decided on a case-by-case basis. Which support model is suitable depends on the strategic relevance of the open source software, the technical integration and the available personnel resources. + +For critical software, support must be provided professionally in any case, whether internally or externally. The planned lifecycle should also play a role in support planning. It may also be that support is obtained from multiple providers. + +=== Use without professional support + +Open source software is available on the internet to download, install and use free of charge. + +[cols="1,3a"] +|=== +|Advantages +|* Low cost +* Rapid implementation + +|Disadvantages +|* No guaranteed support +* No liability claims + +|Risk and safeguarding +|High risk: There are no support contracts or guarantees and there is little or no developer expertise in the organisation. + +|Typical area of application +|Standard open source software that can be updated independently of other systems. +|=== + +=== Use with internal support + +A company or public sector organisation builds up expertise and resources in specific open source solutions for long-term use. This approach is particularly common in business-critical areas. + +[cols="1,3a"] +|=== +|Advantages +|* High flexibility thanks to internal know-how +* No supplier lock-in + +|Disadvantages +|* High investment and time required to build up expertise +* Higher internal fixed costs for staff + +|Risk and safeguarding +|Medium risk: Support depends on know-how and availability of internal IT. + +|Typical area of application +|In-house development, strategically used open source software for which in-depth know-how is available. +|=== + +=== Use with support from external supplier + +An external open source provider is brought in to professionally accompany the rollout and maintenance of the open source software. This approach is particularly used in business-critical areas where in-depth know-how of the software must be immediately available. This can also include parts of or the entire release. + +[cols="1,3a"] +|=== +|Advantages +|* Direct access to the know-how of open source developers +* Fixes and enhancements on a contract basis +* Selection of different open source suppliers +* Commitment, safeguarding against compliance risks + +|Disadvantages +|* External costs through open source suppliers +* Know-how dependency on open source supplier + +|Risk and safeguarding +|Low risk: Warranty is provided according to terms of reference or service level agreement + +|Typical area of application +|Business-critical open source software where little or no in-house development expertise is available +|=== + +== Contact point + +There is no single point of contact in the Federal Administration that acts as an Open Source Programme Office. In principle, federal offices are responsible for implementation themselves. + +General enquiries about the OSS tools in the Em002 document set can be directed to the DTI Sector of the Federal Chancellery: opensource@bk.admin.ch. + +== Annexes + +=== Changes from previous version + +* Section 4.1: Maturity levels added +* Section 6: Procurement of OSS supplemented and adapted with the new FOBL documents +* Section 7.1: New federal OSS Catalogue (opensource.admin.ch) +* More minor editorial changes and improvements + +=== References + +The references to the Em002 document set can be found in the link:em002.adoc[Em002 Strategic Guidelines]. + +=== Abbreviations + +A list of abbreviations can be found in the main document Em002. +A glossary can be found in the document 'link:em002-6.adoc[Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS)]'. + +=== Business models with OSS + +Open source software is not a business model per se because, unlike with proprietary software, it is not possible to sell software under an open source licence. Nevertheless, there are different possibilities for companies to operate business models based on open source software. For example, if professional external support is to be obtained for an open source solution, then the procurement of corresponding commercial services is necessary. The four most common business models for open source software are explained below. Additional aspects of these and other business models are explained in the BITKOM guidelines _[BIT-KOM2023]_. + +==== Services and products based on OSS + +Companies can offer commercial services such as web hosting or cloud computing based on open source software, which would be much more expensive with proprietary software. As a result, most start-ups, online portals and e-commerce providers today build their platforms on open source software. Other technology companies such as telecommunications companies, streaming providers or even manufacturers of proprietary software integrate open source software into their software and hardware products as well as online services. This allows companies to continue to offer innovative solutions that would be difficult to achieve with proprietary software. + +==== Services for OSS + +Open source providers provide services for selected open source software. They have experienced open source developers and can therefore offer support, maintenance, operation, development, consulting, training and other services for open source software. These can be obtained from the open source supplier as a mandate or under a contract for work and services. Such services for open source software can be publicly tendered as there is no vendor lock-in. What is important for such tenders is the consideration of appropriate criteria so that the service providers that are actually competent are selected (see Sections 0 and 8, _[BITKOM2023]_ Section 3.3 and _[Gu2024]_). + +==== Subscriptions + +If services for open source software are provided in a standardised, recurring form as a kind of service level agreement (SLA), these are called subscriptions. As part of such subscriptions, companies guarantee, for example, continuous security updates, support by email or telephone, compatibility with other software and hardware products through certifications, long-term maintenance services and safeguards against legal claims (copyright, patents). In return, customers pay subscriptions per workstation or CPU, similar to licence fees or usage fees for proprietary software. Unlike proprietary software, however, subscriptions for open source software are not a prerequisite for using the software, but merely a way of paying for the added value of the services provided by the open source supplier. + +==== Dual licensing + +If a company owns the intellectual property of a software solution and all integrated open source components are under a permissive licence, then dual or multiple licensing can be applied. This allows the developer company to publish the software under a copyleft open source licence and also sell it under a proprietary licence. This commercial version is often called the Enterprise version and typically includes certain additional features, such as exclusive interface integrations or permission for buyers to integrate the software into their own proprietary products. Depending on the extent of the restrictions of the open source version, caution is advised when using dual-licensed software, as obtaining the Enterprise version may be unavoidable, making the vendor lock-in as high as with typical proprietary software. diff --git a/docs/en/em002-1.md b/docs/en/em002-1.md deleted file mode 100644 index f513061..0000000 --- a/docs/en/em002-1.md +++ /dev/null @@ -1,1430 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# 1. Use of these guidelines -Under Article 9 of the Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), the Confederation is required to disclose the source code of software that it develops or commissions for the performance of its duties.[^5] The DTI Sector of the Federal Chancellery has derived overarching objectives from this legal mandate in the Strategic Guidelines for Open Source Software. - -This document serves as practical guidelines on the legal and strategic requirements. It is designed to assist federal administrative units in the use, procurement and release of open source software. It provides all interested parties with a comprehensive overview of the subject and refers to additional information in the other resources. - -However, depending on your prior knowledge and needs, you may wish to read the guides selectively before moving on to the other tools. The following outline will help you find the appropriate starting point. If you are unsure, it is recommended that you read through the guidelines first. - -## Intention / Stakeholders - -General introduction to open source software - -- Section Definitions -- Section Potential and challenges -- Section Findability of OSS solutions -- [Em002-5 OSS Tools information sheet](em002-5.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) -- [Em002-6 FAQ about OSS](em002-6.md) - -General introduction to EMOTA for decision-makers - -- [Em002-5 OSS Tools information sheet](em002-5.md) -- [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](em002.md) - -Procurement only of software to be used - -- Section Maturity levels for OSS in the Federal Administration -- Section Use of unmodified open source software -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- Software Procurement and Art. 9 EMOTA information sheet [KBB-MB] -- OSS in Procurement guidelines [BBL-WL] - -New IT development and release - -- Section Development with open source components and release of source code -- Section Collaboration in open projects (contribution) -- [Em002-2 Instructions for Publishing OSS](em002-2.md) -- [Em002-2.1 OSS Preliminary Assessment Checklist](em002-2.1.md) -- [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- [Em002-2.3 OSS Release and Publication Checklist](em002-2.3.md) -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) - -Procurement of created software (service or work) - -- Section Maturity levels for OSS in the Federal Administration -- Section Development with open source components and release of source code -- Section Collaboration in open projects (contribution) -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- FOBL toolbox, including the Open Source in Procurement guidelines -- CCPP public administration learning and template platform (www.perimap.admin.ch)including Software Procurement and Art. 9 EMOTA [KBB- MB] -- OSS in Procurement guidelines [BBL-WL] -- [Em002-2 Instructions for Publishing OSS](em002-2.md) -- [Em002-2.1 OSS Preliminary Assessment Checklist](em002-2.1.md) -- [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- [Em002-2.3 OSS Release and Publication Checklist](em002-2.3.md) -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) - -Legal clarifications for release - -- [Em002-6 Frequently Asked Questions about Publishing OSS(OSS-FAQ)](em002-6.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) - -Working principles for project managers - -- [HERMES documents](https://www.hermes.admin.ch/) -- [Em002-5 OSS Tools information sheet](em002-5.md) - -Contributions of software to third parties and collaborations - -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) - -The following diagram gives an overview of the documents relevant to OSS -in the Federal Administration. - -![Overview of OSS tools in relation to Art. 9 EMOTA](./assets/em002/media/image2.png) - -Figure 1: Overview of OSS tools in relation to Art. 9 EMOTA - -# Definitions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - **Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# 1. Use of these guidelines -Under Article 9 of the Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), the Confederation is required to disclose the source code of software that it develops or commissions for the performance of its duties.1 The DTI Sector of the Federal Chancellery has derived overarching objectives from this legal mandate in the Strategic Guidelines for Open Source Software. - -This document serves as practical guidelines on the legal and strategic requirements. It is designed to assist federal administrative units in the use, procurement and release of open source software. It provides all interested parties with a comprehensive overview of the subject and refers to additional information in the other resources. - -However, depending on your prior knowledge and needs, you may wish to read the guides selectively before moving on to the other tools. The following outline will help you find the appropriate starting point. If you are unsure, it is recommended that you read through the guidelines first. - -## Intention / Stakeholders - -General introduction to open source software - -- Section Definitions -- Section Potential and challenges -- Section Findability of OSS solutions -- [Em002-5 OSS Tools information sheet](em002-5.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) -- [Em002-6 FAQ about OSS](em002-6.md) - -General introduction to EMOTA for decision-makers - -- [Em002-5 OSS Tools information sheet](em002-5.md) -- [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](em002.md) - -Procurement only of software to be used - -- Section Maturity levels for OSS in the Federal Administration -- Section Use of unmodified open source software -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- Software Procurement and Art. 9 EMOTA information sheet [KBB-MB] -- OSS in Procurement guidelines [BBL-WL] - -New IT development and release - -- Section Development with open source components and release of source code -- Section Collaboration in open projects (contribution) -- [Em002-2 Instructions for Publishing OSS](em002-2.md) -- [Em002-2.1 OSS Preliminary Assessment Checklist](em002-2.1.md) -- [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- [Em002-2.3 OSS Release and Publication Checklist](em002-2.3.md) -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) - -Procurement of created software (service or work) - -- Section Maturity levels for OSS in the Federal Administration -- Section Development with open source components and release of source code -- Section Collaboration in open projects (contribution) -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- FOBL toolbox, including the Open Source in Procurement guidelines -- CCPP public administration learning and template platform (www.perimap.admin.ch)including Software Procurement and Art. 9 EMOTA [KBB-MB] -- OSS in Procurement guidelines [BBL-WL] -- [Em002-2 Instructions for Publishing OSS](em002-2.md) -- [Em002-2.1 OSS Preliminary Assessment Checklist](em002-2.1.md) -- [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- [Em002-2.3 OSS Release and Publication Checklist](em002-2.3.md) -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) - -Legal clarifications for release - -- [Em002-6 Frequently Asked Questions about Publishing OSS (OSS-FAQ)](em002-6.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) - -Working principles for project managers - -- [HERMES documents](https://www.hermes.admin.ch/) -- [Em002-5 OSS Tools information sheet](em002-5.md) - -Contributions of software to third parties and collaborations - -- [Em002-4 OSS Community Guidelines](em002-4.md) -- [Em002-4.1 OSS Community Checklist](em002-4.1.md) -- [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) -- [Em002-3 OSS Licensing Guidelines](em002-3.md) - -The following diagram gives an overview of the documents relevant to OSS in the Federal Administration. - -![Overview of OSS tools in relation to Art. 9 EMOTA](./assets/em002/media/image2.png) - -Figure 1: Overview of OSS tools in relation to Art. 9 EMOTA - -# Definitions - -
- Open source software - - Software is considered open source software (OSS) when it is published underone of approximately 80 licences recognised by the Open Source Initiative OSI [OSI2019]. Specifically, the definition of open source sets out ten criteria that all open source licences must meet [PE1999]. These can essentially be summarised in four points: -

-
    -
  1. The software may be used for any purpose.
    2. -
  2. The source code of the software is freely accessible.
    3. -
  3. The software may be copied and distributed without restriction.
    4. -
  4. The software may be modified and distributed in modified form under certain conditions.
    5. -
-
- Free software - - Before the term 'open source', the Free Software Foundation (FSF) introduced the concept of 'free software' in the 1980s.In essence, free software meets the conditions of open source software, but aims to ensure that the software is always freely accessible and, wherever possible, is not integrated into proprietary software.⁶ -
- Proprietary software - - With proprietary software, a supplier develops software and sells a usage licence to the user. Generally, the user does not know the software code and may not redistribute or modify the software. They can only use the software according to the licence terms (e.g. End-User Licence Agreement, EULA) in return for payment of licence fees. For example, the software may be authorised to be used by only a certain number of users or a certain number of processors.⁷ In return for the usually annual maintenance fees, the supplier commits to fixing errors within a reasonable timeframe and to continuously developing the software. -
- Licence - - A licence is a document that contains binding guidelines for the use and distribution of software. In the case of open source, licences that comply with OSI are usually used.⁸ -
- Community - - A community in the context of open source software is broadly defined. It can be a loose ecosystem or a structure with governance that develops the software. The document Em002-4 OSS Community Guidelines covers this topic. Community members can jointly manage the product, develop, test, translate, provide feedback or simply use the software. -
- Third-party rights - - Even with open source software, protective rights may exist (copyright, trademark law, patent law) and can be asserted by third parties, e.g. when using source code created by third parties. -
- Exceptions under EMOTA - - Exceptions according to Art. 9 para. 1 EMOTA include third-party rights and security-related reasons. Both are covered in Section 3 of Em002-2 Instructions for Publishing Open Source Software. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Open source software - - Software is considered open source software (OSS) when it is published underone of approximately 80 licences recognised by the Open Source Initiative OSI [OSI2019]. Specifically, the definition of open source sets out ten criteria that all open source licences must meet [PE1999]. These can essentially be summarised in four points: -

-
    -
  1. The software may be used for any purpose.
    2. -
  2. The source code of the software is freely accessible.
    3. -
  3. The software may be copied and distributed without restriction.
    4. -
  4. The software may be modified and distributed in modified form under certain conditions.
    5. -
-
- Free software - - Before the term 'open source', the Free Software Foundation (FSF) introduced the concept of 'free software' in the 1980s.In essence, free software meets the conditions of open source software, but aims to ensure that the software is always freely accessible and, wherever possible, is not integrated into proprietary software.⁶ -
- Proprietary software - - With proprietary software, a supplier develops software and sells a usage licence to the user. Generally, the user does not know the software code and may not redistribute or modify the software. They can only use the software according to the licence terms (e.g. End-User Licence Agreement, EULA) in return for payment of licence fees. For example, the software may be authorised to be used by only a certain number of users or a certain number of processors.⁷ In return for the usually annual maintenance fees, the supplier commits to fixing errors within a reasonable timeframe and to continuously developing the software. -
- Licence - - A licence is a document that contains binding guidelines for the use and distribution of software. In the case of open source, licences that comply with OSI are usually used.⁸ -
- Community - - A community in the context of open source software is broadly defined. It can be a loose ecosystem or a structure with governance that develops the software. The document Em002-4 OSS Community Guidelines covers this topic. Community members can jointly manage the product, develop, test, translate, provide feedback or simply use the software. -
- Third-party rights - - Even with open source software, protective rights may exist (copyright, trademark law, patent law) and can be asserted by third parties, e.g. when using source code created by third parties. -
- Exceptions under EMOTA - - Exceptions according to Art. 9 para. 1 EMOTA include third-party rights and security-related reasons. Both are covered in Section 3 of Em002-2 Instructions for Publishing Open Source Software. -
- Source code - - In computing, source code (or source text) is the human-readable text of a computer program written in a programming language.⁹ -
- Publication - - Publication primarily refers to the release of the source code under an open licence according to OSI. For practical reasons, this usually also includes documentation and automated instructions for building the application from the source code. Automated tests and test documents are also typically included. To enable a community to develop, a platform is used that then takes on several functions of a development platform (build, test, support). -
- Digital -sovereignty - - We use the definition from the FDFA's Digital Sovereignty Report [St2024]: 'Digital sovereignty of a state or organisation necessarily includes complete control over stored and processed data as well as independent decision-making about who may access it. It further includes the ability to independently develop, modify, control and supplement technological components and systems.' -
- Repository - - A repository is a storage location used by a version control tool for files and metadata about the code base. -Repositories allow multiple contributors to work on the same files and store different versions. Most also allow issue tracking, release management, automated builds and documentation. -
- Fork - - A fork[^10] of an open source project is the process of setting up an independent development of the original project. -
- Contributor Licence Agreement (CLA) - - A Contributor Licence Agreement1 is a document that describes the conditions under which intellectual property can be contributed to a project or venture. -
- Source code management (SCM) - - Source code management,1 also known as version control, is a tool that effectively manages changes and version numbers, particularly in software development. The free software Git2 for managing distributed SCM has become established. -
- Open source software development (OSSD) - - In open source software development (OSSD),1 in addition to publishing the source code, the entire development process is carried out publicly. Everything from requirements (issues) to source code is transparent. OSSD is supported by public communication tools (mailing lists, forums, etc.), a version control system (git), bug and feature lists, roadmap and developer tools. -
- Software Package Data Exchange (SPDX) - - Software Package Data Exchange (SPDX)1 describes a standard format for Software Bill of Materials (SBOM) with the aim of facilitating the correct handling of free software or open source software. -
- Copyleft effect - - If software is under a licence with a copyleft provision, any modification or extension of the source code must be released again under the licence of the modified open source software (see also Em002-3 OSS Licensing Guidelines ). -
- - -# Potential and challenges - -There is enormous potential for open source software in today\'s world of IT. At the same time, the use of open source solutions also brings challenges. These two sides are explained in more detail in the following section. The information is based on, among other things, the results of the Open Source Study Switzerland 2018, 2021 and 2024 by the University of Bern, in which respondents provided information about the recognised advantages and disadvantages of open source software. - -## Potential of open source software - -The following points describe the potential that can be realised when using and releasing open source software. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1. Digital sovereignty - - This involves the ability to use and control digital services. Digital sovereignty extends over the entire lifecycle of a digital system. Open ource software promotes digital sovereignty, as it guarantees interchangeability, design flexibility and influence.[^16] -
- 2. No licence fees - - There are no licence costs for using open source software. However, when obtaining complex standard open source software packages, it may make sense to purchase support subscriptions, for which a fee is paid. -
- 3. Cost savings through cooperation with other users - - As software under an open source licence can be used and further developed without restriction, costs of further developments can be shared or existing additional developments from other administrative units can be adopted according to the principle of 'develop once – use multiple times'. At the same time, there is the opportunity to benefit from the experience and developments of others. -
- 4. Community building & knowledge sharing - - Open source software facilitates community building and knowledge sharing, for example between the different federal levels in Switzerland. Software can be jointly further developed, errors fixed and individual experiences shared. The increased exchange of knowledge between different administrative units leads to a better understanding of what others are working on, so that duplication is avoided and the best solutions can spread. -
- 5. Lower dependence on manufacturers - - Vendor lock-in (dependency on software suppliers) is considered very high in computing. Using software under an open source licence reduces vendor lock-in as operation, maintenance, support, further development and other services for open source software can be openly tendered. Instead of completely re-procuring an entire system due to vendor lock-in, extensions or lifecycle services for an OSS solution can also be put out to tender separately. This can save significant migration costs. -
- 6. Open standards and interoperability - - With open source software, compatibility with other software solutions and IT systems (interoperability) is generally higher than with proprietary software. Open source solutions also use almost exclusively open data formats, which is why they can be easily exchanged with other systems. -
- 7. Transparency about the structure of the software - - As the software is also available in the form of source code, its quality can be checked, for example, through external reviews. In addition, documentation can be created based on the source code (e.g. with regard to new tenders for further development services or the replacement of open source software at the end of its service life). -
- 8. Security and trust through transparency - - Because of the open nature of the source code, the security of open source software can be higher than that of proprietary software. Moreover, it is much more difficult to build backdoors and other loopholes into open source software, which leads to more trust in the software. -
- 9. Higher quality and modularity of code - - The quality of open source software can be higher than proprietary software because the motivation to write good code may be greater when developers know that their source code will be published. In addition, open source solutions tend to be highly modular, so that individual modules can be easily replaced and the remaining modules can continue to be used.[^17] -
- 10. Easy customisation - - Access to the source code allows users to make further developments themselves or through external suppliers. This means the software can be quickly adapted to their own needs. -
- 11. Rapid innovation and integration - - There is rapid, continuous further development of open source software by the community. For example, new technologies and data standards are often published as open source programming libraries. This enables the rapid realisation of innovative software solutions. -
- 12. Employer attractiveness - - The use of modern open source technologies and informal collaboration with international communities promotes employee motivation and thus increases employer attractiveness, which in turn facilitates the recruitment of young, qualified professionals. -
- -## Challenges in dealing with OSS - -The following describes the typical challenges encountered in practice with open source software and outlines some possible solutions. We do not address general challenges that affect all software at this point (e.g. the need to check for cybersecurity and the need to secure appropriate support for critical software). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1. High switching costs due to existing dependencies - - Replacing proprietary software with open source solutions can be very costly if the application is closely embedded in the existing IT system through interface integration or other dependencies. These switching costs mean that introducing open source software often only pays off at the end of the proprietary software's lifecycle. -
- 2. Missing features or no suitable open source solution - - When procuring standard software, it may happen that there is no open source software alternative to the (previous) proprietary solution, or only one that is functionally inadequate. As a solution approach, there is the possibility of jointly developing the missing features together with other users of the open source software and adding them to the open source project.[^18] -
- 3. Higher integration costs - - Short-term cost savings resulting from licence savings when using open source software are often offset by higher integration costs. Therefore, it is important to recognise that the professional use of open source software is not 'free' but actually generates internal or external costs. -
- 4. Unclear responsibilities and support - - Open source software is often criticised for the lack of support and maintenance by external companies. However, there are now a variety of suppliers offering commercial services (long-term support, ongoing maintenance, further development, liability and warranty, etc.) for open source solutions. The different business models with open source software are explained in Annex D and the different support models in Section 8. An up-to-date overview of open source service providers and their services can be found in the Open Source Directory (https://www.ossdirectory.com) or in the OSS Study 2024[^19] [OSS2024] . -
- 5. Small market with few suppliers - - As certain open source applications, such as desktop applications, generally require little or no support and maintenance, there may be little market for open source providers of support and maintenance. In this case, a tendering process for open source software services can help to create a market that increases competition between suppliers. The existence of a broad development community for the software in question and the quality of the development documentation are of practical importance when tendering for such services. -
- 6. Low visibility - - Communities of open source projects focus primarily on product development and rarely on marketing. In contrast, manufacturers of proprietary software invest heavily in marketing and selling their products. This lack of advertising for open source software often creates the false impression that there is no alternative to proprietary products. However, there are platforms such as alternativeTo1 that provide an overview of solutions for specific tasks (more on OSS alternatives in Section ). -
- 7. Lack of acceptance by end users - - Due to different user interfaces, missing functions, low user-friendliness and little advertising for open source software, there is a lack of acceptance by end users for certain open source products. Appropriate communication, documentation and training offerings can counteract this challenge. The fact that open source software can be further developed according to users' needs can also lead to higher acceptance. -
- 8. Little or no in-house expertise - - Open source solutions evolve rapidly and at the same time require in-depth technical understanding. Thus, it may happen that internal employees have little or no expertise with certain open source software. In-house OSS know-how can be built up through further training and opportunities for self-study via online sources and building in-house wikis, etc. -
- 9. Difficult future assessment - - It is often difficult for outsiders of an open source community to recognise how the project will develop in the future. Therefore, it is important to be able to make a realistic assessment of the future development of an open source solution. In this regard, Section Fehler: Verweis nicht gefunden introduces the Open Hub platform, which allows an assessment of the activity and heterogeneity of the developer community. This makes it possible to better assess the future development of an open source project. -
- 10. Legal uncertainties - - The multitudes of different open source licences and small number of court rulings on interpretation issues to date can sometimes lead to legal uncertainties with open source software. These practical guidelines are intended to provide an overview of the most important open source licences and their characteristics and compatibilities. Sources for in-depth answers to legal questions can be found in the documents Em002-3 OSS Licensing Guidelines and in Em002-6 FAQ on OSS and Art. 9 EMOTA . -
- 11. Too extensive offering of open source software - - The number of open source software products has increased dramatically in recent years. Potential users of open source software therefore complain about the multitude of existing open source solutions on the market. For this reason, the section ‘Findability of…’ introduces two platforms, alternativeTo and Open Hub, which enable a comparison of Open Source solutions. -
- 12. Coordination effort involved in collaborative development - - When the Federal Administration participates in and contributes to collaborative projects, this results in a coordination effort within those collaborations, but also when a community needs to be brought on board. Ideally, this additional effort should still be worthwhile thanks to an improved solution, greater acceptance or increased participation from third parties. -
- - -# Constellations for using/working with OSS - -## Maturity levels for OSS in the Federal Administration - -When using and developing OSS in the Federal Administration, there are various constellations regarding the obligations related to open source licences: A typical maturity model[^21] for introducing open source into organisations can look like this: - -1. Denial -- No or unconscious use of open source software - -2. Consumption -- Passive use of open source software - -3. Participation -- Engagement with open source communities - -4. Contribution -- Pragmatic contributions to open source projects - -5. Leadership -- Strategic involvement with open source to drive - business value[^22] - -| ***Constellation*** | ***Impact*** | -| :--- | :--- | -| The mere **use** of existing open source software (without modifying the code). | There is no obligation to share the source code. | -| The **completely new development** of software that is be published under an open source licence. | **In this case, there is complete freedom regarding the licence under which the software is published.** The document Em002-3 OSS Licensing Guidelines should be used for the Confederation. The document [Em002-2 Instructions for Publishing OSS](em002-2.md) and [Em002-4 OSS Community Guidelines](em002-4.md) must be observed. | -| **Further development** (internal or external) with existing open source components (with or without copyleft effect1), as long as the software is used **exclusively within the same organisation** and not redistributed. | The OSS components can be combined with third-party components as required. There is generally no publication obligation from the licence, as long as the software is used exclusively within the same organisation and not distributed (exception: AGPL). Since it is not legally conclusive how far the concept of 'distribution within the same organisation' extends, this scenario only applies in exceptional cases for OSS components with copyleft effects. In these cases, consult your organisation's legal department. See [Em002-3 OSS Licensing Guidelines](em002-3.md) and [Em002-6 FAQ about OSS](em002-6.md) and Art.9 EMOTA. The document [Em002-2 Instructions for Publishing OSS](em002-2.md) and [Em002-4 OSS Community Guidelines](em002-4.md) must be observed. **As there is a publication obligation under Art. 9 EMOTA, the changes must be re-released. The easiest way is as change - - - - -# Potential and challenges - -There is enormous potential for open source software in today\'s world of IT. At the same time, the use of open source solutions also brings challenges. These two sides are explained in more detail in the following section. The information is based on, among other things, the results of the Open Source Study Switzerland 2018, 2021 and 2024 by the University of Bern, in which respondents provided information about the recognised advantages and disadvantages of open source software. - -## Potential of open source software - -The following points describe the potential that can be realised when using and releasing open source software. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1. Digital sovereignty - - This involves the ability to use and control digital services. Digital sovereignty extends over the entire lifecycle of a digital system. Open source software promotes digital sovereignty, as it guarantees interchangeability, design flexibility and influence.[^16] -
- 2. No licence fees - - There are no licence costs for using open source software. However, when obtaining complex standard open source software packages, it may make sense to purchase support subscriptions, for which a fee is paid. -
- 3. Cost savings through cooperation with other users - - As software under an open source licence can be used and further developed without restriction, costs of further developments can be shared or existing additional developments from other administrative units can be adopted according to the principle of 'develop once – use multiple times'. At the same time, there is the opportunity to benefit from the experience and developments of others. -
- 4. Community building & knowledge sharing - - Open source software facilitates community building and knowledge sharing, for example between the different federal levels in Switzerland. Software can be jointly further developed, errors fixed and individual experiences shared. The increased exchange of knowledge between different administrative units leads to a better understanding of what others are working on, so that duplication is avoided and the best solutions can spread. -
- 5. Lower dependence on manufacturers - - Vendor lock-in (dependency on software suppliers) is considered very high in computing. Using software under an open source licence reduces vendor lock-in as operation, maintenance, support, further development and other services for open source software can be openly tendered. Instead of completely re-procuring an entire system due to vendor lock-in, extensions or lifecycle services for an OSS solution can also be put out to tender separately. This can save significant migration costs. -
- 6. Open standards and interoperability - - With open source software, compatibility with other software solutions and IT systems (interoperability) is generally higher than with proprietary software. Open source solutions also use almost exclusively open data formats, which is why they can be easily exchanged with other systems. -
- 7. Transparency about the structure of the software - - As the software is also available in the form of source code, its quality can be checked, for example, through external reviews. In addition, documentation can be created based on the source code (e.g. with regard to new tenders for further development services or the replacement of open source software at the end of its service life). -
- 8. Security and trust through transparency - - Because of the open nature of the source code, the security of open source software can be higher than that of proprietary software. Moreover, it is much more difficult to build backdoors and other loopholes into open source software, which leads to more trust in the software. -
- 9. Higher quality and modularity of code - - The quality of open source software can be higher than proprietary software because the motivation to write good code may be greater when developers know that their source code will be published. In addition, open source solutions tend to be highly modular, so that individual modules can be easily replaced and the remaining modules can continue to be used.[^17] -
- 10. Easy customisation - - Access to the source code allows users to make further developments themselves or through external suppliers. This means the software can be quickly adapted to their own needs. -
- 11. Rapid innovation and integration - - There is rapid, continuous further development of open source software by the community. For example, new technologies and data standards are often published as open source programming libraries. This enables the rapid realisation of innovative software solutions. -
- 12. Employer attractiveness - - The use of modern open source technologies and informal collaboration with international communities promotes employee motivation and thus increases employer attractiveness, which in turn facilitates the recruitment of young, qualified professionals. -
- - -## Challenges in dealing with OSS - -The following describes the typical challenges encountered in practice with open source software and outlines some possible solutions. We do not address general challenges that affect all software at this point (e.g. the need to check for cybersecurity and the need to secure appropriate support for critical software). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1. High switching costs due to existing dependencies - - Replacing proprietary software with open source solutions can be very costly if the application is closely embedded in the existing IT system through interface integration or other dependencies. These switching costs mean that introducing open source software often only pays off at the end of the proprietary software's lifecycle. -
- 2. Missing features or no suitable open source solution - - When procuring standard software, it may happen that there is no open source software alternative to the (previous) proprietary solution, or only one that is functionally inadequate. As a solution approach, there is the possibility of jointly developing the missing features together with other users of the open source software and adding them to the open source project.[^18] -
- 3. Higher integration costs - - Short-term cost savings resulting from licence savings when using open source software are often offset by higher integration costs. Therefore, it is important to recognise that the professional use of open source software is not 'free' but actually generates internal or external costs. -
- 4. Unclear responsibilities and support - - Open source software is often criticised for the lack of support and maintenance by external companies. However, there are now a variety of suppliers offering commercial services (long-term support, ongoing maintenance, further development, liability and warranty, etc.) for open source solutions. The different business models with open source software are explained in Annex D and the different support models in Section 8. An up-to-date overview of open source service providers and their services can be found in the Open Source Directory (https://www.ossdirectory.com) or in the OSS Study 2024[^19] [OSS2024] . -
- 5. Small market with few suppliers - - As certain open source applications, such as desktop applications, generally require little or no support and maintenance, there may be little market for open source providers of support and maintenance. In this case, a tendering process for open source software services can help to create a market that increases competition between suppliers. The existence of a broad development community for the software in question and the quality of the development documentation are of practical importance when tendering for such services. -
- 6. Low visibility - - Communities of open source projects focus primarily on product development and rarely on marketing. In contrast, manufacturers of proprietary software invest heavily in marketing and selling their products. This lack of advertising for open source software often creates the false impression that there is no alternative to proprietary products. However, there are platforms such as alternativeTo1 that provide an overview of solutions for specific tasks (more on OSS alternatives in Section ). -
- 7. Lack of acceptance by end users - - Due to different user interfaces, missing functions, low user-friendliness and little advertising for open source software, there is a lack of acceptance by end users for certain open source products. Appropriate communication, documentation and training offerings can counteract this challenge. The fact that open source software can be further developed according to users' needs can also lead to higher acceptance. -
- 8. Little or no in-house expertise - - Open source solutions evolve rapidly and at the same time require in-depth technical understanding. Thus, it may happen that internal employees have little or no expertise with certain open source software. In-house OSS know-how can be built up through further training and opportunities for self-study via online sources and building in-house wikis, etc. -
- 9. Difficult future assessment - - It is often difficult for outsiders of an open source community to recognise how the project will develop in the future. Therefore, it is important to be able to make a realistic assessment of the future development of an open source solution. In this regard, Section Fehler: Verweis nicht gefunden introduces the Open Hub platform, which allows an assessment of the activity and heterogeneity of the developer community. This makes it possible to better assess the future development of an open source project. -
- 10. Legal uncertainties - - The multitudes of different open source licences and small number of court rulings on interpretation issues to date can sometimes lead to legal uncertainties with open source software. These practical guidelines are intended to provide an overview of the most important open source licences and their characteristics and compatibilities. Sources for in-depth answers to legal questions can be found in the documents Em002-3 OSS Licensing Guidelines and in Em002-6 FAQ on OSS and Art. 9 EMOTA . -
- 11. Too extensive offering of open source software - - The number of open source software products has increased dramatically in recent years. Potential users of open source software therefore complain about the multitude of existing open source solutions on the market. For this reason, the section ‘Findability of…’ introduces two platforms, alternativeTo and Open Hub, which enable a comparison of Open Source solutions. -
- 12. Coordination effort involved in collaborative development - - When the Federal Administration participates in and contributes to collaborative projects, this results in a coordination effort within those collaborations, but also when a community needs to be brought on board. Ideally, this additional effort should still be worthwhile thanks to an improved solution, greater acceptance or increased participation from third parties. -
- - -# Constellations for using/working with OSS - -## Maturity levels for OSS in the Federal Administration - -When using and developing OSS in the Federal Administration, there are various constellations regarding the obligations related to open source licences: A typical maturity model[^21] for introducing open source into organisations can look like this: - -1. Denial -- No or unconscious use of open source software - -2. Consumption -- Passive use of open source software - -3. Participation -- Engagement with open source communities - -4. Contribution -- Pragmatic contributions to open source projects - -5. Leadership -- Strategic involvement with open source to drive - business value[^22] - -| ***Constellation*** | ***Impact*** | -| :--- | :--- | -| The mere **use** of existing open source software (without modifying the code). | There is **no obligation** to share the source code. | -| The **completely new development** of software that is be published under an open source licence. | **In this case, there is complete freedom regarding the licence under which the software is published.** The document [Em002-3 OSS Licensing Guidelines](./em002-3.md) should be used for the Confederation. The document [Em002-2 Instructions for Publishing OSS](em002-2.md) and [Em002-4 OSS Community Guidelines* must be observed](em002-4.md). | -| **Further development** (internal or external) with existing open source components (with or without copyleft effect1), as long as the software is used **exclusively within the same organisation** and not redistributed. | The OSS components can be combined with third-party components as required. There is generally no publication obligation from the licence, as long as the software is used exclusively within the same organisation and not distributed (exception: AGPL). Since it is not legally conclusive how far the concept of 'distribution within the same organisation' extends, this scenario only applies in exceptional cases for OSS components with copyleft effects. In these cases, consult your organisation's legal department. See [Em002-3 OSS Licensing Guidelines](./em002-3.md) and [Em002-6 FAQ about OSS and Art.9 EMOTA](em002-6.md). The document [Em002-2 Instructions for Publishing OSS](em002.md) and [Em002-4 OSS Community Guidelines](./em002-4.md) must be observed. **As there is a publication obligation under Art. 9 EMOTA, the changes must be re-released. The easiest way is as changes to the existing open source project.** | -| **Further development** (internal or external) **exclusively with** existing open source **components without copyleft effect**, if the software is to be distributed externally (e.g. to cantons).| The OSS components can be combined with third-party components at will, and there is no publication obligation from the licences (see also [Em002-3 OSS Licensing Guidelines](em002-3.md)). **However, release is mandatory within the framework of Art. 9 EMOTA. Ideally, the release should made be via the existing project (no fork).** The document [Em002-2 Instructions for Publishing OSS](./em002-2.md) and [Em002-4 OSS Community Guidelines](em002-4.md) must be observed. | -| **Further development** (internally or externally) with existing open source components **with copyleft effect**, if the software is to be distributed externally (e.g. to cantons). | **There is an obligation to publish** due to the copyleft licence (see also [Em002-3 OSS Licensing Guidelines](./em002-3.md) regarding the copyleft effect). The document [Em002-2 Instructions for Publishing OSS](./em002-2.md) and [Em002-4 OSS Community Guidelines](em002-4.md) must be observed. | -| **Contributing** to an existing open source project. | **There is generally a publication obligation according to EMOTA. The governance and licence of the project are used.** The document [Em002-2 Instructions for Publishing OSS](./em002-2.md) and [Em002-4 OSS Community Guidelines](em002-4.md) must be observed. | -| **Joint development** of a new or existing project with a community and cost sharing. | **There is generally a publication obligation according to EMOTA.** The documents [Em002-2 Instructions for Publishing OSS](./em002-2.md), [Em002-3 OSS Licensing Guidelines](./em002-3.md) and [Em002-4 OSS Community Guidelines](em002-4.md) are used **to set up the project and its governance.** | -| **All variants of development or further development** are carried out **via a supplier or commissioned third party.** | **There is generally a publication obligation according to EMOTA.** Based on [Em002-2 Instructions for Publishing OSS](./em002-2.md), [Em002-3 OSS Licensing Guidelines](./em002-3.md) and [Em002-4 OSS Community Guidelines](em002-4.md). If possible, the prerequisites for publication should be established during the procurement process and, if necessary, the requirements for software approval should be communicated to the supplier/third party. | - - - -## Use of unmodified open source software - -When using open source software, it is generally not relevant under which open source licence it is published, as all open source licences (see Section 2 \'Definitions\') allow the unrestricted use of open source software, regardless of how many workstations, simultaneously logged-in users, number of servers and processors, etc. the software is used on. - -When using unmodified open source software, **no publication obligations** arise even for programs that are under a licence with a strict copyleft effect (exception: AGPL licence, Affero General Public Licence). - -As long as open source software is introduced and operated by internal federal service providers, this can be done **without a public procurement procedure**, because \"the OSS licence alone generally costs the procuring entity nothing and is therefore not relevant to procurement in itself.\" - -If an external service provider is commissioned for maintenance, support and other services for the open source software, the requirements of public procurement law must be observed. Different support variants are described in Section 9. It is also important to use appropriate suitability and award criteria when procuring open source software. The basis for this is explained in Section 8. - -## Development with open source components and release of source code - -With the publication obligation according to Art. 9 EMOTA, the procedure described in -2 [Em002-2 Instructions for Publishing OSS](./em002-2.md) should be followed here. -The documents [Em002-3 OSS Licensing Guidelines](./em002-3.md) and [Em002-4 OSS Community Guidelines](./em002-4.md) must also be consulted if necessary. The goal is to release the project in a controlled manner using the three checklists *[Em002-2.1](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt), [Em002-2.2](Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt), [Em002-2.3](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication%20.odt)*. - -## Collaboration in open projects (contribution) - -Possible considerations for the Federal Administration\'s contribution to open, already existing projects are listed in the BITKOM guide *\[BITCOM2024\]* Section 4.2.[^24] Depending on the importance of the project for the Federal Administration, it should be examined how much responsibility the respective office wants to and can assume. - -Collaboration in open projects and direct development in open projects can also take place using the documents for release. The focus is on [Em002-4 OSS Community Guidelines](./em002-4.md) and the associated checklist *[Em002-4.1](./Em002-4.1%20Checklist%20OSS%20Community.odt).* - -# Properties and selection of open source licences - -The properties and selection of open source licences are described in the document [Em002-3 OSS Licensing Guidelines](em002-3.md). - -# OSS procurement - -Strategic issues relating to procurement and OSS are dealt with in [Em002-7 Strategic aspects of procurement and open source software](./em002-7.md). - -The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled *Software Procurement and Art. 9 EMOTA [KBB-MB]* as well as two documents \'Sample criteria -- EMOTA procurement and open source\' and \'Sample contract texts -- software development\'. - -Further assistance is available on the [FOBL intranet](https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html) (accessible only on the federal network) with the [*Open Source in Procurement Guidelines*](https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf.download.pdf/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf) *\[[BBL-WL](https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf.download.pdf/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf)\]* and the [*Checklist for Art. 9 EMOTA Blanket Exception*](https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx) *\[[BBL-CL](https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx)\]*. - -The enterprise readiness of open source can be found in the document *Selection Criteria for Enterprise-Ready Open Source Software \[Gu2024\]*[^25] or in the Bitkom guide.[^26] - -# Findability of OSS solutions - -Various platforms allow interested organisations to find and analyse open source software before use or procurement. The resulting data provide a basis for deciding on the use or procurement of open source software. - -A compilation of minimum requirements and possibly a market analysis should serve in any case. - -## OSS Catalogue - -The federal authorities are required to publish the source code of software they develop or commission for the performance of their duties. The OSS Catalogue[^27] lists all software developed by federal authorities since 1 January 2024 and released as open source. It provides an overview of available software and makes it easier to find and reuse open source solutions. - -If a new repository or organisation is created, it should be reported for inclusion in the OSS Catalogue by email to . - -OSS Catalogue: - -## OSS Directory - -The OSS Directory operated by CH Open[^28] makes it easy to find qualified providers offering professional support for open source software. - -Open source providers use success stories to show which users (customers) they have helped implement specific open source products. -The Directory also features current open source news from existing platforms, curated top news, events, communities, job listings and knowledge-sharing articles. The OSS Directory is available in German, English, French and Italian. All entries can be added and updated directly by registered users. - -OSS Directory: - -## alternativeTo - -A practical tool for finding alternatives to software is \'alternativeTo - Crowdsourced software recommendations\'.[^29] As the name suggests, the alternatives and their ratings have been created through crowdsourcing, i.e. the input of many individual users. alternativeTo distinguishes four types of software solutions, of which only the first is considered open source software in the sense of Art. 9 EMOTA: - - - - - - - - - - - - - - - - - - -
- Free open source - - Software that is published under an open source licence. -
- Free - - Free software (freeware) but whose source code is not freely available and -may not be modified. -
- Freemium - - Such software offers a free and a premium version, with all important functionalities already available in the free version. This category does not include software that can be tested free of charge for a certain period of time (e.g. a 30-day trial version), which falls into the 'Commercial' category. -
- Commercial - - This is proprietary software for which licence fees are charged when used. -
- - -## Open source repositories - -Currently, the world\'s most popular open source development platform with over 30 million users and over 100 million source code repositories is GitHub.[^30] Today, practically all IT companies, especially manufacturers of proprietary software, as well as many other types of company and organisation, have a GitHub presence. More and more public authorities -- about a dozen from Switzerland[^31] -- also publish their own open source software on \'GitHub and Government\' at . This process can also be carried out with other repositories. - -Examples of other repositories are: - -- GitLab - -- Bitbucket - -- SourceForge - -- LaunchPad - -On GitHub Insights, numerous relevant statistics of an Open Source project on GitHub can be read: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Pulse - - Overview of the recent activities of an open source project on GitHub: Summary of the most important information about development intensity, community heterogeneity, open reports, improvements (pull requests), etc. -
- Contributors - - Display of which developers have been active and when. This is an important indicator of whether everything depends on one person or whether there is a larger community behind it. -
- Commits - - Display of which contributions were made to this open source project in which time period. -
- Code frequency - - Visualisation of how much source code was added or removed and when. -
- Dependency graph - - Dependencies of the open source project on other open source software (e.g. relevant for identifying security vulnerabilities and updates). -
- Network - - Display of when which developer contributed to which development branch. -
- Forks - - List of all copies of the open source project on GitHub. Indicator of the popularity and distribution of the open source software. -
- - -## Open Hub - -If information is to be collected on an open source solution that is not -necessarily developed on GitHub, Open Hub by Black Duck is a good -option.[^32] A wealth of important information is clearly summarised for -around half a million open source projects: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Project Summary - - A brief description of the open source project. -
- In a Nutshell - - The most important facts about an open source project, such as the number of commits, contributors and lines of code, as well as the most used programming language, the time of the first commit and last change. In addition, an assessment of the code base and the size of the development team is listed (e.g. 'Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits'). -
- Quick Reference - - Contains information about the organisation, links to the project and the code, as well as references to similar projects. -
- Licences - - Indicates the licence(s) under which the open source project is licensed and what consequences are associated with it. -
- Project Security - - Provides information on the security and vulnerabilities of the open source project. -
- Code - - A graph showing the number of lines of code over time, broken down by programming language. -
- Activity - - A graph showing the number of commits per month. A summary of the last 30 days and 12 months is also provided. -
- Community - - A graph showing the number of active contributors per month is displayed. A rating of the project is also displayed on a five-star scale. -
- - -Open Hub also allows you to compare different open source projects.[^33] This quickly provides an overview of which project has the most active community, the longest development time or the most suitable licence. - -## Special code repositories - -Larger organisations have their own code repositories. Particularly noteworthy is, for example, the German repository for authorities opencode.de.[^34] Repositories from other public administrations are of particular interest here. - -# Support models for OSS use - -Open source software already available on the market can basically be used in three ways: - -1. Use without professional support - -2. Use with internal support - -3. Use with support from an external supplier. - -These three types of use and their advantages and disadvantages are briefly explained below. Which of these scenarios makes the most sense in a particular case must be decided on a case-by-case basis. Which support model is suitable depends on the strategic relevance of the open source software, the technical integration and the available personnel resources. - -For critical software, support must be provided professionally in any case, whether internally or externally. The planned lifecycle should also play a role in support planning. It may also be that support is obtained from multiple providers. - -## Use without professional support - -Open source software is available on the internet to download, install and use free of charge. - - - - - - - - - - - - - - - - - - - -
- Advantages - -
    - - Low cost -
-
    - - Rapid implementation -
-
- Disadvantages - -
    - - No guaranteed support -
-
    - - No liability claims -
-
- Risk and safeguarding - - High risk: There are no support contracts or guarantees and there is little or no developer expertise in the organisation. -
- Typical area of application - - Standard open source software that can be updated independently of other systems. -
- -## Use with internal support - -A company or public sector organisation builds up expertise and resources in specific open source solutions for long-term use. This approach is particularly common in business-critical areas. - - - - - - - - - - - - - - - - - - -
- Advantages - -
    - - High flexibility thanks to internal know-how -
-
    - - No supplier lock-in -
-
- Disadvantages - -
    - - High investment and time required to build up expertise -
-
    - - Higher internal fixed costs for staff -
-
- Risk and safeguarding - - Medium risk: Support depends on know-how and availability of internal IT. -
- Typical area of application - - In-house development, strategically used open source software for which in-depth know-how is available. -
- - -## Use with support from external supplier - -An external open source provider is brought in to professionally accompany the rollout and maintenance of the open source software. This approach is particularly used in business-critical areas where in-depth know-how of the software must be immediately available. This can also include parts of or the entire release. - - - - - - - - - - - - - - - - - - - -
- Advantages - -
    - - Direct access to the know-how of open source developers -
-
    - - Fixes and enhancements on a contract basis -
-
    - - Selection of different open source suppliers -
-
    - - Commitment, safeguarding against compliance risks -
-
- Disadvantages - -
    - - External costs through open source suppliers -
-
    - - Know-how dependency on open source supplier -
-
- Risk and safeguarding - - Low risk: Warranty is provided according to terms of reference or service level agreement -
- Typical area of application - - Business-critical open source software where little or no in-house development expertise is available -
- -# Contact point - -There is no single point of contact in the Federal Administration that acts as an Open Source Programme Office. In principle, federal offices are responsible for implementation themselves. - -General enquiries about the OSS tools in the Em002 document set can be directed to the DTI Sector of the Federal Chancellery: . - -# Annexes - -## Changes from previous version - -- Section 4.1: Maturity levels added - -- Section 6: Procurement of OSS supplemented and adapted with the new FOBL documents - -- Section 7.1: New federal OSS Catalogue (opensource.admin.ch) - -- More minor editorial changes and improvements - -## References - -The references to the Em002 document set can be found in the [Em002 Strategic Guidelines](./em002.md). - -## Abbreviations -A list of abbreviations can be found in the main document Em002. -A glossary can be found in the document \'[Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS)](./em002-6.md)\'. - -## Business models with OSS -Open source software is not a business model per se because, unlike with proprietary software, it is not possible to sell software under an open source licence. Nevertheless, there are different possibilities for companies to operate business models based on open source software. For example, if professional external support is to be obtained for an open source solution, then the procurement of corresponding commercial services is necessary. The four most common business models for open source software are explained below. Additional aspects of these and other business models are explained in the BITKOM guidelines *\[BIT-KOM2023\]*. - -### Services and products based on OSS - -Companies can offer commercial services such as web hosting or cloud computing based on open source software, which would be much more expensive with proprietary software. As a result, most start-ups, online portals and e-commerce providers today build their platforms on open source software. Other technology companies such as telecommunications companies, streaming providers or even manufacturers of proprietary software integrate open source software into their software and hardware products as well as online services. This allows companies to continue to offer innovative solutions that would be difficult to achieve with proprietary software. - -### Services for OSS - -Open source providers provide services for selected open source software. They have experienced open source developers and can therefore offer support, maintenance, operation, development, consulting, training and other services for open source software. These can be obtained from the open source supplier as a mandate or under a contract for work and services. Such services for open source software can be publicly tendered as there is no vendor lock-in. What is important for such tenders is the consideration of appropriate criteria so that the service providers that are actually competent are selected (see Sections 0 and 8, *\[BITKOM2023\]* Section 3.3 and *\[Gu2024\]*). - -### Subscriptions - -If services for open source software are provided in a standardised, recurring form as a kind of service level agreement (SLA), these are called subscriptions. As part of such subscriptions, companies guarantee, for example, continuous security updates, support by email or telephone, compatibility with other software and hardware products through certifications, long-term maintenance services and safeguards against legal claims (copyright, patents). In return, customers pay subscriptions per workstation or CPU, similar to licence fees or usage fees for proprietary software. Unlike proprietary software, however, subscriptions for open source software are not a prerequisite for using the software, but merely a way of paying for the added value of the services provided by the open source supplier. - -### Dual licensing - -If a company owns the intellectual property of a software solution and all integrated open source components are under a permissive licence, then dual or multiple licensing can be applied. This allows the developer company to publish the software under a copyleft open source licence and also sell it under a proprietary licence. This commercial version is often called the Enterprise version and typically includes certain additional features, such as exclusive interface integrations or permission for buyers to integrate the software into their own proprietary products. Depending on the extent of the restrictions of the open source version, caution is advised when using dual-licensed software, as obtaining the Enterprise version may be unavoidable, making the vendor lock-in as high as with typical proprietary software. - -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the Ordinance *of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: [SR 172.019](https://www.fedlex.admin.ch/eli/cc/2023/682/de) - -[^6]: See: - -[^7]: See: - -[^8]: See: - -[^9]: See: - -[^10]: See: - -[^11]: See: - - -[^12]: See: - -[^13]: See: - -[^14]: See: - - -[^15]: See: - - -[^16]: We use the definition from *\[St2024\]*: \'Digital sovereignty of - a state or organisation necessarily includes complete control over - stored and processed data as well as independent decision-making - about who may access it. It further includes the ability to - independently develop, modify, control and supplement technological - components and systems.\' - -[^17]: Another aspect of security is that it is easier to document the - libraries used (including dependencies) than in proprietary - software. This in turn means that when vulnerabilities occur, they - can be quickly identified and fixed (see also SBOM). - -[^18]: Project or application managers are responsible for such new - features. The project determines exactly how this is done. Em002-2 - and Em002-4 help with detailed decisions. Depending on the size of - the feature, it may not make sense to go through the instructions in - full. Procurement law aspects for resources must be observed. - -[^19]: See: - -[^20]: https://alternativeto.net/ - -[^21]: Maturity model based on - https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels - -[^22]: Creation is not mentioned, as Art. 9 EMOTA directly requires - this. - -[^23]: Explanation of the term 'copyleft' in [Em002-3 OSS Licensing Guidelines](./em002-3.md) - -[^24]: See - - in, Section 4.2. - -[^25]: See *\[Gu2024\]* - -[^26]: See [Best practice recommendations for open source software \| - 2025 Guidelines \| Bitkom e. - V.](https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software), - Section 3.3 - -[^27]: - -[^28]: - -[^29]: - -[^30]: - -[^31]: - -[^32]: - -[^33]: - -[^34]: \ No newline at end of file diff --git a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc new file mode 100644 index 0000000..a234ca2 --- /dev/null +++ b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc @@ -0,0 +1,175 @@ += Em002-2.1 OSS Preliminary Assessment Checklist +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +This checklist is part of the document _Em002-2 Instructions for Publishing Open Source Software_. It should be completed at the start of a project or when clarifying whether software does not need to be published. + +The description of the checklist can be found in _[Em002-2]_, Section 3. + +This checklist can also be used to define whether development will be as open development directly on a public repository. + +For legacy code (developed before EMOTA came into force on 1.1.2024), additional questions are provided. + +Important: If software is not to be released as OSS, this checklist also serves as justification for such a decision. + +== Subject matter + +=== Name and brief description of the software + +Enter the name of the software. + +This name should be identical in all subsequent OSS checklists to ensure correct allocation. + +[cols="1"] +|=== +a| + +|=== + +Describe the goal and purpose of the software as well as the scope. + +If a URL link exists, please also provide this. + +[cols="1"] +|=== +a| + +|=== + +=== Contact person and review + +Name the federal authority (organisational unit), contact person and the persons responsible for the legal review (e.g. ISBO/DSBO) who have verified compliance with the publication requirements. + +[cols="1"] +|=== +a| + +|=== + +== Checklist + +[cols="1,6"] +|=== +| +a| +*New software or legacy* + +Is this new software or an existing project (see [Em002-2] Section 3.1). + +☐ Legacy (further development) + +☐ New software + +☐ Legacyfootnote:[Not required by EMOTA, but it is also possible to release existing software.] or further development of legacy software + +☐ Existing third-party project ( Complete _Em002-4.1 OSS Community Checklist_) + +| +a| +Life cycle + +In what stage of the life cycle is the software currently (see [Em002-2] Section 3.1).footnote:[Replacement of existing software should be noted here as 'planned'.] + +☐ Planned + +☐ In development + +☐ In operation + +☐ End of life + +☐ Archive + +| +a| +Users + +Are there potential or known individuals or organisations using the software? Are there potential customers for the software? Possible and known users can be named in the textbox. + +☐ None conceivable + +☐ Potential users + +☐ Known users + +| +a| +*In-house development, joint development or third-party project* + +What is the basic structure? Is this an in-house development by the Confederation, a collaboration, or is it based on a third-party project? + +The structure of co-development and third-party project can be listed in the textbox + +(see [Em002-2] Section 3.1). + +☐ In-house development + +☐ Joint development (_Em002-4.1 OSS Community Checklist_ to be completed) + +☐ Third-party project (_Em002-4.1 OSS Community Checklist_ to be completed) + +| +a| +Who is publishing the software? + +☐ Federal authority + +☐ Service provider + +☐ Supplier + +☐ Third party + +| +a| +Depth of release + +Outcome from _Em002-4.1 OSS Community Checklist_. + +☐ Minimal publication: Publication of the source code and other artefacts + +☐ Issue tracking: Errors can be reported and will be handled. + +☐ Community + +|☐ +a| +There is no violation of third-party rights (e.g. patent rights, intellectual property, trademark or design protection). + +Reviews according to [Em002-2] Section 3.2 have been carried out. The ownership of the software lies with the Confederation, or it is being developed by employees of the Confederation (internal or external). Justification must be given, especially if this is not the case. It must also be explained why the rights do not lie with the Confederation and what checks were made regarding proprietary parts, as well as what was done regarding possible obstacles (e.g. patent protection), or how far investigations went. + +|☐ +a| +There are no security-relevant reasons preventing publication. + +Reviews according to [Em002-2] Section 3.3 have been carried out. + +|☐ +a| +There is agreement in principle and feasibility exists for publishing the application as open source. + +Reference to minutes or decision-making body with date. + +|=== + +== Concluding remarks + +Comments and references to other relevant documents. + +If a Contributor Licence Agreement (CLA) is used, this should be noted here (see _Em002-3 OSS Licensing Guidelines_ Section 8.9). + +[cols="1"] +|=== +a| + +|=== + +*Filing of form* + +Please file this form with the project documentation and/or in accordance with the specifications of your authority (organisational unit). + +*Licence of the checklist template: CC0 1.0 Universal* + +This document is published under the CC0 licence. It may be freely used, modified and distributed, including for commercial purposes and in any format. diff --git a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc new file mode 100644 index 0000000..0ff664f --- /dev/null +++ b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc @@ -0,0 +1,138 @@ += Em002-2.2 OSS Analysis and Preparation Checklist +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +This checklist is part of _Em002-2 Instructions for Publishing Open Source Software_ and is intended for ICT professionals. + +It serves to review the documentation and source code of a project. In doing so, it helps ensure that the quality level of the documentation is sufficient to publish an application as open source. It can also be used to verify that the source code and all third-party components used by the project do not pose any legal risks. These measures minimise security risks. + +Information about this checklist can be found in _[Em002-2]_ in Section 4. + +Furthermore, this checklist ensures that the project documentation addresses both end users and technical professionals equally. + +== Subject matter + +=== Name and brief description of the software + +Enter the name of the software. + +[cols="1"] +|=== +a| + +|=== + +=== Contact person and review + +Name the organisation, contact person from the specialist office and the persons responsible (e.g. ISBO/DSBO) who have verified compliance with the publication requirements. + +[cols="1"] +|=== +a| + +|=== + +== Checklist + +[cols="1,6"] +|=== +|☐ +|_Em002-2.1 OSS Preliminary Assessment Checklist_ has been completed and no problematic points were identified. + +|☐ +a| +The source code to be published has been analysed. + +* Review how the existing code quality and guidelines have been implemented. +* Ensure no sensitive (test) data is included, e.g. data based on real people or cases. +* Current documentation (see [Em002-2] Annexes D.1. and D.2.) +* Delete unnecessary files or outdated documents. +* Check code for secrets/credentials.footnote:[https://www.ncsc.admin.ch/ncsc/en/home/aktuell/im-fokus/2022/git.html] +* Conduct targeted security tests and subsequently establish a (public) bug bounty programme.footnote:[https://www.ncsc.admin.ch/ncsc/en/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Review all libraries used to ensure licences are present and corresponding lists (attributions) have been created. +* Description of the deployment (CI/CD pipelinefootnote:[https://en.wikipedia.org/wiki/CI/CD]) and possibly setup of a demo instance. + +|☐ +a| +Licence selection + +* Check for any dependencies on existing licences. +* For third-party code, check terms of use for compatibility with intended licence and replace code if necessary. +* Select the appropriate licence using the guide 'Em002-3 OSS Licensing Guidelines' (primary recommendations are AGPL for copyleft and MIT for permissive). + +Selected licence and justification + +|☐ +a| +The documentation is stored with the source code (see [Em002-2] Annex D.1.) + +Justification/storage location + +|☐ +a| +The documentation addresses both end users and technical professionals. + +List of the central documentation + +|☐ +a| +Detailed documentation of the source code (OSS specific) + +Important standard documentation (README, LICENSE, CONTRIBUTING, etc.) is available. + +|☐ +a| +The source code, including history, contains no sensitive, protected or confidential personal data. Or the history has been completely deleted. (see [Em002-2] Annex E.2.) + +Explanation of review (if not filed as separate document) + +|☐ +a| +It has been clarified with the supplier and all involved developers within the Federal Administration whether author information (names, email addresses) may be published. + +Alternatively, the source code including history has been cleaned/anonymised. + +|☐ +a| +The libraries used by the project are compatible with the project's licence. + +Explanation of review (if not filed as separate document) + +|☐ +|The project uses a package manager to manage its dependencies. + +|☐ +|The project declares its licence in the corresponding descriptor of the package manager. Creation of a Software Bill of Materials (SBOM), which lists all open source components used. + +|☐ +a| +The source code contains a _THIRD-PARTY-LICENSES.md_ file listing for each library used: the project name of the library, the homepage of the library, the SPDX identifier of the library's licence, and a link to the library's licence. + +|☐ +|For applications, an 'About' dialogue is available that references the _THIRD-PARTY-LICENSES.md_ file. + +|☐ +|As part of the code review process, it is ensured that the _THIRD-PARTY-LICENSES.md_ file is updated with every change to the libraries. + +|=== + +== Concluding remarks + +Comments and references to other relevant documents + +[cols="1"] +|=== +a| + +|=== + +*Filing of form* + +Please file this form with the project documentation and/or in accordance with the specifications of your authority (organisational unit). + +*Licence of the checklist template: CC0 1.0 Universal* + +This document is published under the https://creativecommons.org/publicdomain/zero/1.0/[_CC0 licence_]. It may be freely used, modified and distributed, including for commercial purposes and in any format. diff --git a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc new file mode 100644 index 0000000..83e52bd --- /dev/null +++ b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc @@ -0,0 +1,147 @@ += Em002-2.3 OSS Release and Publication Checklist +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +This checklist is part of the document 'Em002-2 Instructions for Publishing Open Source Software'. + +It concludes the instructions and results in release of the software under an open source licence. The description of the checklist can be found in [Em002-2] Annex D. + +== Subject matter + +=== Name and brief description of the software + +Enter the name of the software. + +[cols="1"] +|=== +a| + +|=== + +=== Contact person and review + +Name the organisation, contact person from the specialist office and the persons responsible (e.g. ISBO/DSBO) who have verified compliance with the publication requirements. + +[cols="1"] +|=== +a| + +|=== + +=== Repository names and developer permissions + +State the planned repository names of the software to be published and the chosen publication platform.footnote:[A repository under the GitHub organisation of the Federal Chancellery (http://github.com/swiss) can be requested from opensource@bk.admin.ch.] + +[cols="1"] +|=== +a| + +|=== + +Specify who (GitHub username, name, position, function) is working on the repository. If this is in a repository of an office, it must be stated who authorised the person. That person is then also responsible for the solution if the first person leaves the organisation or changes their position. It should also be specified whether individuals are acting as private persons or as part of the office. Name the GitHub user account that should be assigned the role of Repository Administrator. There can be several administrators. + +[cols="1"] +|=== +a| + +|=== + +== Checklist + +The checklist is to be completed before actual publication. + +[cols="1,6,1"] +|=== +|☐ +|'Em002-2.1 OSS Preliminary Assessment Checklist' has been completed and no problematic points were identified. +| + +|☐ +|'Em002-2.2 OSS Analysis and Preparation Checklist' has been completed and no problematic points were identified. +| + +|☐ +a| +Licence has been selected. + +Selected licence and justification + +| + +|☐ +a| +ISDS concept has been created. + +The relevant reviews have been carried out. Refer to documents/reviews. It is defined how security-relevant reports by third parties will be handled. + +If applicable, the software will be subject to a bug bounty programme. + +There may also be OSS checks in the repositories. + +The relevant configuration is described and the person responsible is named. + +| + +|☐ +a| +Community and support is regulated (via 'Em002-4.1 OSS Community Checklist') + +The checklist is attached. The key points are included here. + +| + +|☐ +a| +Level and method of support have been clarified. + +Indication of how this has been regulated. + +| + +|☐ +a| +A *publiccode.yml* was created for the publication. + +The metadata standard https://yml.publiccode.tools/ describes the software. The defined format makes the publication easier to find and reuse. + +This must be saved in the main directory of the repository. + +If a new repository or organisation is created, this can be reported via opensource@bk.admin.ch for inclusion in the OSS Catalogue. + +| + +|☐ +a| +Transferred responsibilities + +Indication of whether responsibility for release was transferred to a third party (supplier, support, association) during procurement or subsequently. + +| + +|☐ +a| +Green light for open sourcing from the application and budget managers + +Names and date + +| +|=== + +== Concluding remarks + +Comments and references to other relevant documents + +[cols="1"] +|=== +a| + +|=== + +*Filing of form* + +Please file this form with the project documentation and/or in accordance with the specifications of your authority (organisational unit). + +*Licence of the checklist template: CC0 1.0 Universal* + +This document is published under the https://creativecommons.org/publicdomain/zero/1.0/[_CC0 licence_]. It may be freely used, modified and distributed, including for commercial purposes and in any format. diff --git a/docs/en/em002-2.adoc b/docs/en/em002-2.adoc new file mode 100644 index 0000000..2db5c38 --- /dev/null +++ b/docs/en/em002-2.adoc @@ -0,0 +1,627 @@ += Em002-2 Instructions for Publishing OSS +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + + +*Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code.footnote:[Recommendation for Federal Administration IT in accordance with ++[++P035++]++ _Section 4.6_]footnote:[For definitions of the INTERNAL and CONFIDENTIAL classifications, see the _Ordinance of 8 November 2023 on Information Security in the Federal Administration and Armed Forces (InfoSecO; SR 128.1)_]footnote:[See footnote 1]footnote:[Planning areas in accordance with the _Federal Administration IT Strategy 2020-2023 of 3 April 2020 (SB000)_] For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +''''' + +== Management summary + +These instructions describe the procedure for disclosing source code of software that federal authorities develop or commission for the fulfilment of their duties in accordance with Art. 9 EMOTA.footnote:[Federal Act _++[++EMOTA2023++]++_] Exceptions are made if third-party rights or security-relevant grounds preclude or restrict such disclosure. Publication means that anyone may use, further develop and distribute the software. No licence fees are charged. + +These instructions are intended for individuals responsible for and implementing the publication of source code. + +image::./assets/em002-2/media/image1.png[Overview of the OSS publication process] + +The subject matter is divided into three main parts: + +* The first part (Section 3) covers *preliminary assessments* and exceptions according to EMOTA. +* The second part (Section 4), *Analysis and preparation*, examines source code and prepares it as needed. Furthermore, the choice of licence is made. +* The third part (Section 5), *Publication and announcement*, describes the actual publication and further measures such as communication and building a suitable community. + +*Three checklists* accompany and document the process. + +Technical additions are listed in the annex. + +== Introduction + +When releasing open source software, a distinction must be made between *contributing source code and documentation to existing open source software* and *publishing it as an independent open source project*. + +The former typically involves bug fixes and feature enhancements. Depending on the licence type and software deployment, the source code must or can be released under the existing licence of the open source project. A release agreement may have to be followed. + +In the second case, starting a new open source project, governance and licence can generally be freely chosen. The only consideration is the licence under which any software elements integrated into the new project are published. Further details on licence selection can be found in the document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. If value can be generated for the Federal Administration from a community or if the Federal Administration wants to create an ecosystem, link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] should also be completed according to link:em002-4.adoc[Em002-4 OSS Community Guidelines]. + +The release of open source software is more than just a technical measure. It also means establishing an appropriately open culture and getting people on board. A successful open source culture is a mixture of openness, technical excellence, strong social interaction and a shared commitment. + +The following diagram describes the instructions and different characteristics. + +image::./assets/em002-2/media/image2.png[Decision tree for software release] + +Figure 1 – Decision tree for software release + +== Preliminary assessment process + +*Objective:* Understand the advantages and possible consequences of publishing the software. Decide whether the software can be published and if so, whether building an active community is worthwhile. NB: link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed as early as possible in the project, as this can influence the way the software is developed. + +=== Release under EMOTA + +According to Art. 9 of the Federal Act of 17 March 2023 ++[++EMOTA2023++]++ on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), the Federal Administration (specifically Art. 2 para. 1) must disclose the source code of software that it develops or commissions for the fulfilment of its duties. Exceptions apply when third-party rights or security-relevant grounds preclude or restrict this. + +For custom software created on behalf of the Confederation, the General Terms and Conditions of the Confederation ++[++BBL-AGB++]++ generally apply. Under clause 25.1, these stipulate that ownership of source code and documentation transfers to the service procurer (the Confederation). If the software was procured jointly by several organisations or other institutions, it must be checked who has the rights to the code. For example, ownership may lie with an association founded for this purpose. + +The mere use of standard software is not covered by Art. 9 EMOTA, and release would generally not be possible anyway, as the rights to standard software often remain with the vendor (GTC Confederation for Standard Software Procurement). However, custom extensions to standard software are certainly suitable for publication. Normally, these are owned by the Confederation. Mere configuration adjustments are less suitable for publication. The topic is dealt with in link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software] and the documents ++[++KKB-MB++]++ and ++[++BBL-WL++]++. In principle, extensions are always subject to Art. 9 EMOTA. + +==== Software in relation to EMOTA + +The current ISO/IEC Standard 24765 contains three definitions for software: + +. a program or set of programs used to operate computers +. programs and their associated documentation +. programs and, where applicable, associated documentation and other data necessary for computer operation. + +Based on this definition, smaller scripts, macros or Infrastructure as Code (IaC) are also classified as software. EMOTA refers to source code in Article 9 paragraph 1. Under this interpretation, publication according to definition 1 would suffice. However, publishing without associated documentation is of little value, as the software cannot be used according to definition 2. + +To achieve synergies with third parties, definition 3 must be taken as a basis. Regarding data, this specifically means master data and basic configurations (for example, enumeration values and basic data that should also be made available as open source). + +Smaller projects, scripts or code examples may also be published together in one repository if deemed appropriate by the federal authority. In this case, these instructions and the corresponding checklists can be completed once. + +Proportionality and effort should be considered when deciding what to publish and how. + +==== Type of software + +As shown in Figure 1, a distinction is made between in-house development, joint development and third-party projects. Each constellation has different implications. Regardless of how the software is developed, it falls under Art. 9 EMOTA. + +With in-house development, the Confederation creates the software itself or commissions it accordingly. It chooses the governance and retains the rights to the source code. + +In joint development, the Confederation creates the software with other organisations. The governance and rights to the software must be regulated through the chosen form of organisation. + +If the Confederation contributes directly to third-party software, this source code also falls under Art. 9 EMOTA. It must be ensured that this is done in accordance with federal authorities' interests, that participation meets the project requirements, and that the Federal Administration adheres to the governance. + +This is done using link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. + +==== Legacy code + +For old software (*legacy software*), the retrospective effort for publication is higher than if release was planned from the beginning. For legacy software, it only makes sense to make this effort if a potential user wants to use the software. Regardless, link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed to document relevant decisions. + +Applications which federal authorities began to develop on or after 1 January 2024 or which are being developed on behalf of the Confederation based on a contract concluded after 1 January 2024 are not considered legacy and in, any case, fall under the publication requirement according to Art. 9 para. 1 EMOTA. + +The publication requirement under EMOTA is not dependent on the benefit to third parties. + +==== Libraries, plug-ins and add-ons + +In some cases, the software may not be a standalone application but only parts thereof. EMOTA and the ordinance do not further define source code. The instructions also apply to decoupled libraries, plugins and add-ons, and these fall under EMOTA. + +*Tasks:* + +* Gather information from link:em002-5.adoc[Em002-5 OSS Tools information sheet]. This describes both general information about open source software and specific information about applying EMOTA. +* Check whether the requirements under EMOTA are met. +* Complete link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist]. As a rule, it makes sense to directly involve the contact persons from the software supplier/developer. +* If needed, complete link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. + +*Decision:* Does the software have to be published and how should this be done? + +=== Exception: Third-party rights + +Publication must be avoided if doing so would violate third-party rights. If the software was developed by federal employees, the rights belong to the employer.footnote:[Art. 332 CO in conjunction with. Art. 6 para. 2 FPA] In contracts for staff leasing and IT services, the rights are usually transferred to the Confederation and should be claimed. + +If the software was or is being developed on the basis of the General Terms and Conditions of the Swiss Confederation (as of 2024),footnote:[General Terms and Conditions of the Swiss Confederation, in particular Section 25.1 - https://www.bkb.admin.ch/bkb/de/home/themen/agb.html#accordion_21321111141713247349255] the intellectual property rights belong to the client, unless contractually agreed otherwise. + +An application typically consists of numerous individual components and parts. With some types, it becomes problematic if they themselves are not open source or cannot be published under an open source licence as part of the application. + +*Libraries* + +Depending on the programming language, libraries are either directly compiled with the application, linked, or delivered as packages. They form an integral part of the application. + +If the application contains proprietary or licence-requiring libraries, then open sourcing becomes more difficult. In principle, the source code of the rest of the application can be published, but potential users or developers would need to purchase the relevant library before the application becomes usable or extensible. + +If ownership of the problematic library lies with the application supplier, it is worth seeking legal clarification as to whether the Confederation has transferable rights to these libraries. + +Where possible, proprietary and licence-requiring libraries should be avoided with in-house developments or replaced if possible before release. Considering the objective of Article 9 EMOTA, as much functionality as possible used by public administrations should be published. Therefore, individual libraries that prevent code publication represent a technical debt that should be documented and, where appropriate, eliminated when the opportunity arises. + +*Databases and other data storage* + +If the application uses proprietary, licence-requiring data storage such as Microsoft SQL Server, this is not an obstacle to open source publication. + +However, it should be examined whether additional open databases such as PostgreSQL can be supported. This can save operating costs and lower the entry barriers for potential users. + +*Application servers and operating systems* + +If the application requires licensed operating systems or application servers (e.g. Microsoft Windows Server or RedHat JBoss), this is not an obstacle to open source publication. + +We recommend asking the software vendor whether licensed third-party libraries are used as components of the application and, if so, which ones. + +If the software creation was jointly procured by multiple organisations or other institutions, ownership usually lies with an association or other legal entity established for this purpose. + +*Other intellectual property* + +Third-party rights include not only copyrights but also other intellectual property (trademarks, patents). Patents do not fundamentally prevent software from being published as open source, but they may prevent it from being used or enhanced. While patents are rather uncommon in Switzerland, it is usually worth making a brief enquiry to the software vendor about whether an examination has already taken place. + +*Acquisition of necessary rights* + +To fulfil the legal requirements of EMOTA, the federal authority has the option as the contracting authority to secure the rights to the work results. This prerequisite for publication can be defined as a criterion during procurement. Acquiring necessary rights to the software afterwards can become more complex. + +If the federal authority does not want to publish the software itself, it can delegate this task to the contractor, for example, or transfer the publication rights accordingly. In this case, it will transfer the necessary rights (and obligations) to the supplier and/or third parties and commission them with publication. This means that the right is effectively transferred to a third party under the condition of release/support of the corresponding software. + +Here too, ++[++KKB-MB++]++ contains important information. + +*Procedure* + +image::./assets/em002-2/media/image3.png[Process for handling third-party rights exceptions] + +Figure 2 - Exception: Third-party rights (always also take into account ++[++KKB-MB++]++ and link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]) + +*Tasks:* + +* Check whether the organisation owns the relevant protective rights to the software. +* Check whether the rights can be acquired. +* If necessary, obtain written permission from the rights holders. +* Verify that the application contains no proprietary or protected parts. +* Check that there are no obstacles due to patent protection (as far as possible and reasonable). +* Check whether the release is to be carried out by a third party. +* Check whether development should be based on open source software development (using the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. + +*Decision:* Can the software be published without violating third-party rights? + +=== Exception: Security-relevant reasons + +Software that cannot be published on security-relevant grounds is exempt from publication. + +The actual data of software is not affected by source code publication.This data is usually sensitive and is not published. However, it may be that besides the content data, certain algorithms and procedures visible in the source code should not become public (e.g. offensive cyber capabilities, details of fraud detection). Security can relate to confidentiality, integrity, availability or traceability. + +*Recommendation:* + +Software should be deliberately developed so that no additional risk arises even when the source code is published. The assumption that non-publication protects against successful attacks is deceptive ('security through obscurity'). + +*Procedure:* + +image::./assets/em002-2/media/image4.png[Process for handling security-relevant reasons exceptions] + +Figure 3 - Exception: Security-relevant reasons + +The following grounds can be considered security-relevant for each project: + +* Publication of the software would substantially increase an information security risk.footnote:[Information Security Act, ISA. Art 6 Information security. https://www.fedlex.admin.ch/eli/cc/2022/232/de#art_6] +* For fraud prevention algorithms and similar algorithms, publication may be waived where appropriate. +* Particularly sensitive cybersecurity technologies. +* Core software for operating critical infrastructure. +* When publication would violate other legal foundations. + +The following temporary grounds may still prevent publication. However, publication will be enabled later through appropriate measures. + +* Legacy code could not yet be cleaned up and may contain security-relevant issues. +* Security audits of the code have not yet been conducted. +* The development process is not mature enough to enable secure publication. If the development process is not sufficiently established, it is possible that parts intended not for third parties might be published. For example, code commenting guidelines and test data generation must be adapted to the new publication scenario and function reliably. + +Through the following measures, software can be published despite security-relevant grounds: + +* Separate configurations (e.g. type of encryption used) from the software. +* Outsource technically sensitive information (e.g. processes, calculations) that is not public into configurations or settings. +* Plan, implement and regularly practise suitable organisational, personnel and technical measures. +* Plan and carry out appropriate quality activities during publication. See the following section 'Analysis and preparation'. + +*Tasks:* + +* Check the software for security-relevant grounds that would prevent publication. +* Estimate effort required to resolve temporary grounds. +* Plan measures to separate security-relevant information from the software's source code. +* Ensure that the application contains no procedures that must not become public. + +*Decision:* + +Are there compelling security-relevant grounds that make publication impossible? + +=== Clarification of publication + +This step clarifies who will publish the software. If the software was created by an external vendor, the publication can also be commissioned to that vendor. In this step, it is important to determine where the source code will be published and to establish appropriate governance accordingly. + +If the software was developed internally at the Confederation and the Confederation cannot or does not wish to publish it itself, a publication order can be placed with a supplier or the rights can be assigned (transfer of obligations to a third party). + +*Minimum release and support* + +EMOTA does not specify any requirements regarding publication. A minimum release of the source code fulfils the legal requirement. No further activities are required. The question of whether and to what extent support is offered and how actively the project is maintained can be answered using link:em002-4.adoc[Em002-4 OSS Community Guidelines.] + +*Open source software development (OSSD)* + +With open source software development (OSSD), in addition to publishing the source code, the entire development process is conducted publicly. Everything from requirements (issues) to source code is transparent. OSSD is supported by public communication tools (mailing lists, forums, etc.), a version control system (git), bug and feature lists, roadmap and developer tools. Through this transparent working method, the entire community benefits and enables collaboration across organisational boundaries. With this approach, no further publication activity is necessary upon project completion, as this was already considered at the project's start. + +*Tasks* + +* Create a rough effort estimation for the analysis phase. Depending on the size and complexity of the application, the effort ranges between three days and two weeks. +* Release resources for further steps, particularly for analysis. +* Agree in principle to publish the application as open source. + +*Decision:* + +Basic agreement and feasibility for publishing the application as open source is given. + +=== Minimising effort + +The checklists and instructions are structured to minimise the effort required for releases. Consistent advance planning of the release at project start and development designed for release minimises effort. Some administrative effort and costs will inevitably arise ++[++Le2023++]++. These can potentially be recovered through communities with shared development costs (see link:em002-4.adoc[Em002-4 OSS Community Guidelines]). + +=== Choice of publication language + +The choice of language must consider both the potential target audience and the team's working methods. Fortunately, translations are much easier with the aid of new tools. The official languages of the Confederationfootnote:[https://www.fedlex.admin.ch/eli/cc/1999/404/en#art_70] and English are possible options. + +If the project is internationally relevant, English should be the target language. For subsequent publication, it naturally makes little sense to change the language. + +At minimum, the README.md should be available in multiple languages so that interested parties can immediately see if the project is relevant to them. + +Public communication should primarily consider the target audience. It should also be considered that this is public communication from the Confederation. + +*Note*: With publication, the Federal Administration enters a new channel of public communication. If this is not done carefully and professionally, the public image of the Confederation can quickly suffer. + +== Analysis and preparation + +*Objective:* The work required for open source publication is completed. Decisions regarding licence and type of community have been made. This is done using link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist]. + +=== Source code analysis + +The source code to be published and other related documents are analysed prior to publication. This analysis ensures that no confidential information is published. + +If extensive source code is planned for publication, it is recommended to use appropriate automated tools for the following activities. + +The details are defined in Section E. + +*Tasks* + +* Check how existing code quality and guidelines have been implemented (e.g. ISO/IEC 25010:2023footnote:[ISO/IEC 25010:2023 - Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.iso.org/standard/78176.html]). +* Ensure that no sensitive (test) data is included, e.g. data based on real people or cases. +* Update software documentation (see annex). +* Delete unnecessary files or outdated documents and data. +* Check source code for secrets/credentials.footnote:[https://www.ncsc.admin.ch/ncsc/en/home/aktuell/im-fokus/2022/git.html] +* Conduct targeted security tests and subsequently establish a (public) bug bounty programme.footnote:[https://www.ncsc.admin.ch/ncsc/en/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Check all used libraries regarding licences and that the corresponding lists (attributions) are created. If a library is available under several licences, this should be indicated accordingly in the lists. +* Describe deployment (CI/CD pipeline) and possibly set up a demo instance. + +These activities are independent of publication but are prerequisites for good software quality and ensuring compliance. Observing these measures simplifies collaboration, increases the quality of external contributions, and enhances the image of the software or the authority. + +=== Licence selection + +*Refer to link:em002-3.adoc[Em002-3 OSS Licensing Guidelines].* + +Internationally established licence texts should be used where possible and appropriate. Liability claims by licensees should be excluded to the extent legally possible. + +*Tasks* + +* Check any dependencies on existing licences. +* For third-party code, check terms of use for compatibility with intended licence and replace code if necessary.footnote:[See Em002-3 regarding selection of third-party code/libraries for a technology stack and regarding compatibility of the licence.] +* Select appropriate licence. + +Licence compatibility can be checked using tools such as ORT Toolkit,footnote:[https://oss-review-toolkit.org/] Black Duck,footnote:[https://www.blackducksoftware.com] FOSSAfootnote:[https://www.fossa.com] or FOSSology.footnote:[https://www.fossology.org] The ToDO Group footnote:[https://landscape.todogroup.org/] provides an up-to-date overview of tools. + +*Decision:* + +* Determine and document under which the licence the software will be published. + +=== Open source documentation + +A minimum set of documentation is expected with publication. Several documents have become established in the open-source ecosystem. This gives visitors a quick insight into the software including licensing. + +The following documents are expected: + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Document* |*Description / Content:* +|README(.md) |Serves as an entry document and provides a quick overview of the project's purpose,scope, status, licence and target groups. +|LICENSE |Description of the chosen licence in the project +|CONTRIBUTING(.md) |Describes the process of how to contribute to the project. +|CODE++_++OF++_++CONDUCT(.md) |The Code of Conduct establishes expected social norms within the project. +|CHANGELOG(.md) |Maintains a list of changes in software versions. +|THIRD-PARTY-LICENSES(.md) |Description of third-party licences or used components. +|Getting started |Brief guide on how to install and use the software. +|Create Gitignore |Describes documents that will not be published, e.g. configurations, test data or generated content. Protected and sensitive information should be managed outside the project in appropriate designated tools and storage. +|publiccode.yml |Structured metadata for describing the software, based on the standard https://yml.publiccode.tools/. The defined format makes the publication easier to find and reuse. Further information in Annex F. +|=== + +Table 1 – Open source documents + +Further technical details of these documents are described in the annex. + +*Tasks* + +* Create standard documentation. +* Include copyright, licence notices, and disclaimer in all files. +* Depending on the publication platform, additional descriptions can be made. + +*Decision:* + +* Final decision to publish the application as open source. + +== Publication and announcement + +*Objective:* The application is published as open source and easily findable by third parties. All components are ready for publication and the community is built or established. This is done using link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. To a certain extent, it involves recapitulating decisions already made. + +=== Choice of platform + +There are several ways to publish source code. The following table provides an overview of possible source code management (SCM) systems and platforms. + +The suitable platform must be selected prior to actual publication. Some federal authorities are already represented on GitHub.footnote:[The website https://ossbenchmark.com gives an overview of organisations and authorities that are active on GitHub.] In this case, it makes sense to use platforms already established. + +*Recommendation:* + +We currently recommend setting up an organisation on GitHub per federal authority for publishing source code. Within this organisation, corresponding projects (repositories) can be created and users with appropriate permissions managed. In the future, a central federal platform should be established. To maintain optimal user management and preserve the reputation of the Swiss Confederation, it is important to use fewer, but better-managed repositories. + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Platform* |*Properties* +|GitHubfootnote:[https://github.com/about/] |Microsoft’s online platform with wide distribution. A large amount of open source software is hosted on GitHub. Offers many additional tools besides SCM.Available in both Free and Enterprise versions (subscription). +|GitLabfootnote:[https://about.gitlab.com/] |Online platform from the company of the same name GitLab, which is itself published under an open source licence. Offers many additional tools besides SCM. Can also be operated locally, thus providing a degree of sovereignty. Available in both Free and Enterprise versions (subscription). +|Bitbucketfootnote:[https://bitbucket.org/product/en] |Atlassian’s online platform, specifically integrated into its ecosystem. Available in both Free and Enterprise versions (subscription). +|Internal SCM system |If own SCM platform is provided, it can also publish and make certain repo/projects available. Operation must be ensured. +|Federal platform |There is currently no central federal platform for publishing software. A measure to this effect is proposed in link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. +|Website, public FTP server, etc. |EMOTA does not define how software should be published. A minimum releasefootnote:[A minimum publication only includes the publication of the source code and other minimal artefacts. This type of publication fulfils EMOTA requirements. However, no added value is achieved through the publication.] can also be done on a website or other publicly accessible resources. However, this is not suitable for sustainable collaboration in the sense of open source. +|=== + +Table 2 – Platforms for publishing open source software + +If the software is published jointly with an external partner or organisation, care must be taken to ensure that appropriate permissions and access to the source code are available. + +*Tasks* + +* Evaluate suitable platform, including corresponding organisation/project. +* If not yet clarified, determine project/repository naming. +* Define and check permissions on the repo. +* Ensure appropriate governance and any replication of source code. + +*Decision:* + +* Platform for publication has been appropriately chosen. + +=== Software publication + +When the prerequisites are clarified, the software can be published. + +*Tasks* + +* Check prerequisites against the link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. +* Access to platform is available and governance clarified. +* Publication of source code and documentation by the developer. + +=== Communications + +After actual publication, further communication activities can be initiated by and within the federal authority concerned. These help with distribution and bring the desired added value from publication. + +*Tasks* + +* Description in repo hosting, security settings, etc. +* Internal and, if applicable, external communication +* Write a message to the community. +* Make the application known within the organisation and in specialist committees, promote its use and contributions. +* Create a publiccode.ymlfootnote:[The metadata standard https://yml.publiccode.tools/ describes the software. The defined format makes the publication easier to find and reuse. Further information in Annex F.] file in the repository for the Federal Administration’s OSS Catalogue.footnote:[OSS Catalogue: https://www.opensource.admin.ch] + +=== Community building and maintenance + +When publishing software, a community can develop that can contribute to the software through contributions (pull requests), questions, documentation suggestions, etc. To have an active community, considerable effort is required for both building and continuous maintenance. A well-functioning community minimises unwanted forks of the software. The goal here is to activate the added value of the community through targeted activities. Even with minimum publication, handling feedback and questions about the software should be defined. + +*Tasks* + +* Clarify who potential users or interested parties are. +* Determine the appropriate form for the specific application using the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +* Build the community. +* Community building activities. + +== Annex + +=== Changes from previous version + +* Sections 4.3 and 5.3: Publication supplemented with publicode.yml +* Annex F 'Public Code' was added +* Various minor editorial changes and improvements + +=== References + +See _Em002 Strategic Guidelines for Open Source Software in the Federal Administration_. + +=== Abbreviations + +See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. + +=== Accompanying documentation link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] – Documentation + +=== Source code documentation + +The documentation should be part of the project's source code to ensure that changes to the documentation are stored in a revision-secure manner and the documentation is versioned alongside the project. This automatically ensures that the documentation, if properly maintained, does not diverge from the project's development status, and documentation for older versions of the project can be retrieved at any time. + +Furthermore, this gives third parties the opportunity to easily contribute changes to the documentation. + +Markdown should be used as the markup language for the text formatting as it is easy to write, widely used, and machine-readable. Additionally, markdown documents are displayed in a well-readable target format by all common platforms. Markdown documents can be rendered into any target format independent of the platform used, using static site generators such as Jekyll, MkDocs, Gatsby, or Sphinx, for example, with the corporate identity specifications of an administration. + +=== Documentation recipients and structure + +The project documentation should address both end users and technical professionals, thus not focusing solely on technology. For language selection, see Section 3.6. This supports the software's distribution. + +A README.md file serves as the entry document. Files with this name are recognised and displayed as the entry point to the documentation by all common platforms.footnote:[For more information on creating a readme file: https://www.makeareadme.com/] + +README.md should provide a quick overview of the project's purpose, scope, status, licence and target groups. Specifically, README.md should include the following points: + +* Software name +* Brief description of the software's purpose and function. Scope and possible limitations +* Installation guidelines +* How to use the software +* Reference to any demo instance +* Support and contact details +* How to contribute to open source software (Contributing) +* Licence used (Licence) +* Project status / development status + +=== Emphasising open source and licence storage + +Directly after the mission statement, it should be clearly and unambiguously stated that the project is open source software. The licence used by the project should be specified with the corresponding SPDX identifierfootnote:[SPDX identifier - https://spdx.org/about] and linked to the specific licence text in the LICENSE file. Licence templates typically include a variable part (e.g. project name, copyright year, author's name) that must be adapted in the LICENSE file. + +Most platforms recognise licences in a LICENSE file and offer clear information about the licence, e.g. a brief summary of the licence terms. + +It is recommended to add a minimum licence and copyright header to each source file that is created. Existing headers in existing files should not be changed. If contributing to a project that has clear standards for headers, these should be followed. + +For more details see: Producing Open Source Software: State That the roject is Free.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Current development status + +To quickly show the project's state, the current development status should be documented in README.md. It is important for readers to know whether the project is in a mature state or at the beginning of development, whether it is actively maintained, and how frequently new versions are published. + +This section can describe what type of third-party support is currently most important for the project. This could be, for example, a developer with specific technological knowledge or someone to revise the project's documentation. + +For further details, see Producing Open Source Software: Development Status.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Demo instance + +For applications, it is recommended to provide a demo instance so that the application can be tried without installation effort. Depending on the type of application, the demo instance can be the productive installation or a test stage. It is important that readers can access the corresponding instance as independently and directly as possible. + +As an alternative, many open source projects provide tools for easily starting the application. This can be done using containers, portable applications or install scripts, for example. + +=== Subject matter expert and project owner + +The README.md file should name the primary subject matter expert so that other interested administrations and organisations can make contact as directly as possible. + +Personal email addresses should not be used. + +The README.md file should also briefly describe which organisation is the project owner, especially if an association has been formed for the project. + +== Installation documentation + +For applications, README.md should reference installation documentation that describes hardware and software requirements, which infrastructure components (for example, databases) are used, and how the application can be installed and operated. + +=== Developer Guidelines + +The entry point for the Developer Guidelines should be stored in a markdown file CONTRIBUTING.md, which is linked in README.md. The Developer Guidelines are part of the extended documentation for developers who want to contribute to the project and primarily focus on collaboration and communication within the project rather than on technology. + +The Developer Guidelines should include the following points and reference the corresponding documents where appropriate: + +* A reference to the project's Code of Conduct. The Code of Conduct establishes expected social norms within the project. +* It is recommended to choose or build upon the Contributor Covenant Code of Conduct licensed under CC-BY-4.0footnote:[https://creativecommons.org/licenses/by/4.0/] as the Code of Conduct.footnote:[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html] +* A note that the project conducts code reviews in the form of GitHub pull requests, with a reference to the GitHub pull request documentation. + +Finally, reference should be made to the Developer Documentation. + +=== Developer Documentation + +While the Developer Guidelines describe the collaboration and social norms of the project, the Developer Documentation focuses on the technical aspects of participating in the development of the project. It should describe at least the following points: + +* What technical dependencies the project has and which tools are necessary for project development. +* What formal rules apply to the project's source code, for example regarding source code formatting. +* How the project's source code is organised and how functions can be technically tested. +* An architecture sketch with a rough description of the architecture, preferably including context demarcation and rough component view.footnote:[Architecture framework MMB (Bund Modelling Method) or arc42. http://arc42.org/] +* For applications: How the application can be started for development or debugging purposes and what infrastructure components are necessary for this. + +== Accompanying documentation for link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] – Source code + +=== Source code history + +A project's source code is usually stored in a source code management (SCM) system such as GitHub. These systems store not only the current state of the source code but also changes that have been made to the source code over time. In particular, this includes deletions from the source code, including deleted files. + +In addition, the SCM contains meta-information about changes to the source code, such as the author's name and email, or PGP signatures for signed commits and tags. + +=== Sensitive, proprietary or confidential data + +The source code and source code history of the project may contain publicly available data, such as a postcode directory, randomly generated data or synthetic data. + +The source code and source code history must not contain any sensitive or confidential (personal) data or information as defined by the Federal Act on Data Protection (FADP) and the Information Security Act (ISA). This includes, in particular: + +* User names and passwords or other secrets such as private keys, access tokens or certificates. +* Internal DNS names, URLs, host names, IP addresses, network structures or drive names. +* Names, addresses, pictures or similar personal data without the consent of the person concerned +* Anonymised or pseudonymised data (because it is possible to undo anonymisation or pseudonymisation) + +Even if the current state of the source code is free of sensitive, proprietary or confidential data or information, such data or information may still be retrieved from the SCM system history if it was ever part of the source code or SCM meta-information in the past. Cleaning up the current source code state will not completely remove this information.footnote:[One possibility to clean up a repo is offered by the tool https://rtyley.github.io/bfg-repo-cleaner/[BFG Repo-Cleaner]] + +Therefore, if in doubt, it is recommended to completely remove the source history after cleaning up the source code, before publishing the source code. + +The names and email addresses of the authors of the source code are usually available directly in the source code or in the SCM metadata, for example in GitHub commits or annotated GitHub tags. From a legal point of view, this is not a problem, as the developer company is responsible for regulating the publication of such information. However, it is recommended that the developer company or internal federal employees are made aware that the names and email addresses of the source code authors may be disclosed when the software is published. + +=== Removing author information + +The history of the software can be changed to hide author information. Toolsfootnote:[https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/] can automate this step to a large extent. + +Removing author information removes attribution, traceability, and contact information. The effort involved should not be underestimated, depending on the volume of source code. For these reasons, author removal is not recommended. Names may be published if a) consent has been obtained from the persons concerned and b) there are no security-relevant reasons for not doing so. + +=== Consideration of library licences + +Virtually every project uses third-party libraries (software libraries, dependencies) to access commonly used functions without having to code them. These libraries usually depend on other libraries, resulting in multi-level dependencies (transitive dependencies). Depending on the programming language, even small projects can have hundreds of dependencies. + +The results of this clarification must be considered when choosing a licence in accordance with link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and in link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. + +For each of these dependencies, ensure that its licence is compatible with the project licence. Dependencies that are not under an open source licence or which have not declared a licence or use a viral licence that does not match the project licence are particularly problematic. Some libraries are licensed under more than one licence and allow the user to choose one. + +* In all major programming languages, the dependencies of the project (including transitive dependencies) and the licences of the dependencies can be automatically listed. These include: +* The Project Info Reports plugin for the Apache Maven package manager for Java projects, which uses the dependency report to generate an HTML output of all used libraries, including the declared licence.footnote:[Plugin info https://maven.apache.org/plugins/maven-project-info-reports-plugin/plugin-info.html] +* The NPM Licence Checker for the NPM Package Manager for JavaScript projects, which can output all libraries used, including the declared licence, in various formats, e.g. CSV.footnote:[NPM Licence Checker https://github.com/davglass/license-checker] +* Pivotal's Licence Finder, which supports various package managers and programming languages, including Ruby Gems, Python Eggs and Godeps.footnote:[Licence Finder from Pivotal https://github.com/pivotal/LicenseFinder] + +== Use of libraries with proprietary licences + +Libraries under a proprietary licence are generally problematic in open source projects and usually cannot be used, especially if the source code has been published under a viral licence such as the AGPL. + +Please contact the vendor and the legal department of the relevant office to check whether and under what conditions the proprietary library can be used in your project. + +=== Using package managers + +Virtually all popular programming languages provide package managers for managing their dependencies, such as Apache Maven for Java projects, NPM for JavaScript projects or NuGet for .NET projects. + +When using a package manager, the dependencies used by the project are no longer directly part of the project's source code, for example by copying the dependency's source code into the project or by copying the dependencies into the project in binary form. Instead, the project obtains all its dependencies via the package manager's declarations. + +This allows all dependencies to be listed and referenced correctly. It also prevents unintentional modification of dependency code. If changes are necessary, they must be made directly at the source of the dependency. + +=== Project licence declaration in the package manager descriptor + +The project should declare its licence in the appropriate package manager descriptor, using the SPDX identifierfootnote:[SPDX identifier - https://spdx.org/] so that the project licence can be issued by the package manager. This is particularly important for libraries so that users of the library can automatically query their licence via the package manager. + +=== Attribution and copyright notices + +Many libraries are subject to a licence that requires the library user to give an original copyright notice or attribution. + +These include the following licences (excerpt): + +Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons 'Attribution' (CC BY), MIT, ISC + +For others, see the list of OSI-accredited licences.footnote:[Open source licences are licences that comply with the Open Source Definition – in brief, they allow software to be freely used, modified, and shared. https://opensource.org/licenses] + +In practice, this concerns almost all libraries used. As the number of libraries used in small projects is already very high, a legally correct copyright notice or the necessary attribution is only possible with a great deal of effort. + +It is therefore recommended to proceed as follows: + +* Make a list of the libraries used, using the Package Manager's mechanisms or tools such as the NPM Licence Checker or Pivotal's Licence Finder. +* Prepare the list manually so that it contains the following information: official name of the library project, website of the library project, licence used for the library as SPDX identifier with a link to the licence text. +* Place the list in the project's source code, e.g. in a file THIRD-PARTY-LICENSES.md. +* For applications: Include a link pointing to THIRD-PARTY-LICENSES.md in an 'About' or 'About this application' dialogue. +* The 'About' dialogue is widely used for this purpose, for example in Google Chrome (in the 'About Chrome' dialogue). +* For Libraries: Refer to README.md under THIRD-PARTY-LICENSES.md. +* As part of the code review process, ensure that changes to the libraries are added to THIRD-PARTY-LICENSES.md. + +== Example Codeblock THIRD-PARTY-LICENSES.md + +This project uses open source software: + +* Spring Boot, http://projects.spring.io/spring-boot/[projects.spring.io/spring-boot] licensed under http://www.apache.org/licenses/LICENSE-2.0[Apache-2.0] +* caniuse-db, https://github.com/Fyrd/caniuse[GitHub] licensed under https://creativecommons.org/licenses/by/4.0/[CC-BY-4.0] + +=== Accompanying documentation for Em002-2.3 OSS Release and Publication Checklist + +==== Publication with publiccode.yml + +Publiccode.yml is a metadata standard for software repositories that contain software developed or acquired by public administrations. The aim is to make this software easier to find and reuse. The metadata standard is internationally established and publicly described at https://yml.publiccode.tools/. A publiccode.yml file typically contains information such as title and description (possible in several languages), development status, contact details, licence information, etc. Country-specific extensions are planned for Switzerland. + +A yml file must be created in the main directory of the repository for each software. If the solution consists of several (auxiliary) repo, one file is sufficient, as this describes the use case of the solution. + +Using the structured data in publiccode.yml files, an https://www.opensource.admin.ch/[OSS Catalogue] (https://www.opensource.admin.ch[opensource.admin.ch]) is generated for the entire Federal Administration. The Catalogue provides an overview of published software and makes it easier to find and reuse existing solutions. + +If a new repository or organisation is created, it should be reported for inclusion in the OSS Catalogue by email to opensource@bk.admin.ch. + +In addition to the OSS Catalogue, a graphical editor and validator for publiccode.yml files is also available. + +OSS Catalogue and Editor: https://www.opensource.admin.ch/ + +=== Further sources and licence + +The checklist, the accompanying documentation and related templates are based in part on the following sources: + +* Google Open Source Docs by Google LLC, licensed under CC-BY-4.0footnote:[Google Open Source Docs – https://opensource.google.com/docs/] +* Producing Open Source Software, How to Run a Successful Free Software Project by http://www.red-bean.com/kfogel C-BY-SA-4.0footnote:[Producing Open Source Software, How to run a Successful Free Software Project - https://producingoss.com/] +* GitHub Healthy Contributionsfootnote:[https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions[GitHub Healthy Contributions]] +* Standard for Public Codefootnote:[Standard for Public Code – https://standard.publiccode.net/] diff --git a/docs/en/em002-2.md b/docs/en/em002-2.md deleted file mode 100644 index 2ee3a78..0000000 --- a/docs/en/em002-2.md +++ /dev/null @@ -1,827 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# Management summary - -These instructions describe the procedure for disclosing source code of software that federal authorities develop or commission for the fulfilment of their duties in accordance with Art. 9 EMOTA.[^5] Exceptions are made if third-party rights or security-relevant grounds preclude or restrict such disclosure. Publication means that anyone may use, further develop and distribute the software. No licence fees are charged. - -These instructions are intended for individuals responsible for and implementing the publication of source code. - -![](./assets/em002-2/media/image1.png) - -The subject matter is divided into three main parts: - -- The first part (Section 3) covers **preliminary assessments** and exceptions according to EMOTA. - -- The second part (Section 4), **Analysis and preparation**, examines source code and prepares it as needed. - Furthermore, the choice of licence is made. - -- The third part (Section 5), **Publication and announcement**, describes the actual publication and further measures such as communication and building a suitable community. - -**Three checklists** accompany and document the process. - -Technical additions are listed in the annex. - -# Introduction - -When releasing open source software, a distinction must be made between **contributing source code and documentation to existing open source software** and **publishing it as an independent open source project**. - -The former typically involves bug fixes and feature enhancements. Depending on the licence type and software deployment, the source code must or can be released under the existing licence of the open source project. A release agreement may have to be followed. - -In the second case, starting a new open source project, governance and licence can generally be freely chosen. The only consideration is the licence under which any software elements integrated into the new project are published. Further details on licence selection can be found in the document [Em002-3 OSS Licensing Guidelines](em002-3.md). If value can be generated for the Federal Administration from a community or if the Federal Administration wants to create an ecosystem, [Em002-4.1 OSS Community Checklist](Em002-4.1%20Checklist%20OSS%20Community.odt) should also be completed according to [Em002-4 OSS Community Guidelines](em002-4). - -The release of open source software is more than just a technical measure. It also means establishing an appropriately open culture and getting people on board. A successful open source culture is a mixture of openness, technical excellence, strong social interaction and a shared commitment. - -The following diagram describes the instructions and different characteristics. - -![](./assets/em002-2/media/image2.png) - -Figure 1 -- Decision tree for software release - -# Preliminary assessment process - -**Objective:** Understand the advantages and possible consequences of publishing the software. -Decide whether the software can be published and if so, whether building an active community is worthwhile. NB: [Em002-2.1 OSS Preliminary Assessment Checklist](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) should be completed as early as possible in the project, as this can influence the way the software is developed. - -## Release under EMOTA - -According to Art. 9 of the Federal Act of 17 March 2023 [EMOTA2023] on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), the Federal Administration (specifically Art. 2 para. 1) must disclose the source code of software that it develops or commissions for the fulfilment of its duties. Exceptions apply when third-party rights or security-relevant grounds preclude or restrict this. - -For custom software created on behalf of the Confederation, the General Terms and Conditions of the Confederation [BBL-AGB] generally apply. Under clause 25.1, these stipulate that ownership of source code and documentation transfers to the service procurer (the Confederation). If the software was procured jointly by several organisations or other institutions, it must be checked who has the rights to the code. For example, ownership may lie with an association founded for this purpose. - -The mere use of standard software is not covered by Art. 9 EMOTA, and release would generally not be possible anyway, as the rights to standard software often remain with the vendor (GTC Confederation for Standard Software Procurement). However, custom extensions to standard software are certainly suitable for publication. Normally, these are owned by the Confederation. Mere configuration adjustments are less suitable for publication. The topic is dealt with in [Em002-7 Strategic Aspects of Procurement and Open Source Software](em002-7.md) and the documents [KKB-MB] and [BBL-WL]. In principle, extensions are always subject to Art. 9 EMOTA. - -### Software in relation to EMOTA - -The current ISO/IEC Standard 24765 contains three definitions for software: - -1. a program or set of programs used to operate computers - -2. programs and their associated documentation - -3. programs and, where applicable, associated documentation and other data necessary for computer operation. - -Based on this definition, smaller scripts, macros or Infrastructure as Code (IaC) are also classified as software. EMOTA refers to source code in Article 9 paragraph 1. Under this interpretation, publication according to definition 1 would suffice. However, publishing without associated documentation is of little value, as the software cannot be used according to definition 2. - -To achieve synergies with third parties, definition 3 must be taken as a basis. Regarding data, this specifically means master data and basic configurations (for example, enumeration values and basic data that should also be made available as open source). - -Smaller projects, scripts or code examples may also be published together in one repository if deemed appropriate by the federal authority. In this case, these instructions and the corresponding checklists can be completed once. - -Proportionality and effort should be considered when deciding what to publish and how. - -### Type of software - -As shown in Figure 1, a distinction is made between in-house development, joint development and third-party projects. Each constellation has different implications. Regardless of how the software is developed, it falls under Art. 9 EMOTA. - -With in-house development, the Confederation creates the software itself or commissions it accordingly. It chooses the governance and retains the rights to the source code. - -In joint development, the Confederation creates the software with other organisations. The governance and rights to the software must be regulated through the chosen form of organisation. - -If the Confederation contributes directly to third-party software, this source code also falls under Art. 9 EMOTA. It must be ensured that this is done in accordance with federal authorities\' interests, that participation meets the project requirements, and that the Federal Administration adheres to the governance. - -This is done using [Em002-2.1 OSS Preliminary Assessment Checklist](em002-2.1.md) and [Em002-4.1 OSS Community Checklist](./Em002-4.1%20Checklist%20OSS%20Community.odt). - -### Legacy code - -For old software (**legacy software**), the retrospective effort for publication is higher than if release was planned from the beginning. -For legacy software, it only makes sense to make this effort if a potential user wants to use the software. Regardless, [Em002-2.1 OSS Preliminary Assessment Checklist](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) should be completed to document relevant decisions. - -Applications which federal authorities began to develop on or after 1 January 2024 or which are being developed on behalf of the Confederation based on a contract concluded after 1 January 2024 are not considered legacy and in, any case, fall under the publication requirement according to Art. 9 para. 1 EMOTA. - -The publication requirement under EMOTA is not dependent on the benefit to third parties. - -### Libraries, plug-ins and add-ons - -In some cases, the software may not be a standalone application but only parts thereof. EMOTA and the ordinance do not further define source code. The instructions also apply to decoupled libraries, plugins and add-ons, and these fall under EMOTA. - -**Tasks:** - -- Gather information from [Em002-5 OSS Tools information sheet](em002-5.md). This describes both general information about open source software and specific information about applying EMOTA. - -- Check whether the requirements under EMOTA are met. - -- Complete [Em002-2.1 OSS Preliminary Assessment Checklist](./Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt). As a rule, it makes sense to directly involve the contact persons from the software supplier/developer. - -- If needed, complete [Em002-4.1 OSS Community Checklist](./Em002-4.1%20Checklist%20OSS%20Community.odt). - -**Decision:** Does the software have to be published and how should this be done? - -## Exception: Third-party rights - -Publication must be avoided if doing so would violate third-party rights. If the software was developed by federal employees, the rights belong to the employer.[^6] In contracts for staff leasing and IT services, the rights are usually transferred to the Confederation and should be claimed. - -If the software was or is being developed on the basis of the General Terms and Conditions of the Swiss Confederation (as of 2024),[^7] the intellectual property rights belong to the client, unless contractually agreed otherwise. - -An application typically consists of numerous individual components and parts. With some types, it becomes problematic if they themselves are not open source or cannot be published under an open source licence as part of the application. - -**Libraries** - -Depending on the programming language, libraries are either directly compiled with the application, linked, or delivered as packages. They form an integral part of the application. - -If the application contains proprietary or licence-requiring libraries, then open sourcing becomes more difficult. In principle, the source code of the rest of the application can be published, but potential users or developers would need to purchase the relevant library before the application becomes usable or extensible. - -If ownership of the problematic library lies with the application supplier, it is worth seeking legal clarification as to whether the Confederation has transferable rights to these libraries. - -Where possible, proprietary and licence-requiring libraries should be avoided with in-house developments or replaced if possible before release. Considering the objective of Article 9 EMOTA, as much functionality as possible used by public administrations should be published. Therefore, individual libraries that prevent code publication represent a technical debt that should be documented and, where appropriate, eliminated when the opportunity arises. - -**Databases and other data storage** - -If the application uses proprietary, licence-requiring data storage such as Microsoft SQL Server, this is not an obstacle to open source -publication. - -However, it should be examined whether additional open databases such as PostgreSQL can be supported. This can save operating costs and lower the -entry barriers for potential users. - -**Application servers and operating systems** - -If the application requires licensed operating systems or application servers (e.g. Microsoft Windows Server or RedHat JBoss), this is not an obstacle to open source publication. - -We recommend asking the software vendor whether licensed third-party libraries are used as components of the application and, if so, which ones. - -If the software creation was jointly procured by multiple organisations or other institutions, ownership usually lies with an association or other legal entity established for this purpose. - -**Other intellectual property** - -Third-party rights include not only copyrights but also other intellectual property (trademarks, patents). Patents do not fundamentally prevent software from being published as open source, but they may prevent it from being used or enhanced. While patents are rather uncommon in Switzerland, it is usually worth making a brief enquiry to the software vendor about whether an examination has already taken place. - -**Acquisition of necessary rights** - -To fulfil the legal requirements of EMOTA, the federal authority has the option as the contracting authority to secure the rights to the work results. This prerequisite for publication can be defined as a criterion during procurement. Acquiring necessary rights to the software afterwards can become more complex. - -If the federal authority does not want to publish the software itself, it can delegate this task to the contractor, for example, or transfer the publication rights accordingly. In this case, it will transfer the necessary rights (and obligations) to the supplier and/or third parties and commission them with publication. This means that the right is effectively transferred to a third party under the condition of release/support of the corresponding software. - -Here too, \[KKB-MB\] contains important information. - -**Procedure** - -![](./assets/em002-2/media/image3.png) - -Figure 2 - Exception: Third-party rights (always also take into account \[KKB-MB\] and [Em002-7 Strategic Aspects of Procurement and Open Source Software](./em002-7.md)) - -**Tasks:** - -- Check whether the organisation owns the relevant protective rights to the software. - -- Check whether the rights can be acquired. - -- If necessary, obtain written permission from the rights holders. - -- Verify that the application contains no proprietary or protected parts. - -- Check that there are no obstacles due to patent protection (as far as possible and reasonable). - -- Check whether the release is to be carried out by a third party. - -- Check whether development should be based on open source software development (using the [Em002-4 OSS Community Guidelines](./em002-4.md). - -**Decision:** Can the software be published without violating third-party rights? - -## Exception: Security-relevant reasons - -Software that cannot be published on security-relevant grounds is exempt from publication. - -The actual data of software is not affected by source code publication.This data is usually sensitive and is not published. However, it may be that besides the content data, certain algorithms and procedures visible in the source code should not become public (e.g. offensive cyber capabilities, details of fraud detection). Security can relate to confidentiality, integrity, availability or traceability. - -**Recommendation:** - -Software should be deliberately developed so that no additional risk arises even when the source code is published. The assumption that non-publication protects against successful attacks is deceptive (\'security through obscurity\'). - -**Procedure:** - -![](./assets/em002-2/media/image4.png) - -Figure 3 - Exception: Security-relevant reasons - -The following grounds can be considered security-relevant for each project: - -- Publication of the software would substantially increase an information security risk.[^8] - -- For fraud prevention algorithms and similar algorithms, publication may be waived where appropriate. - -- Particularly sensitive cybersecurity technologies. - -- Core software for operating critical infrastructure. - -- When publication would violate other legal foundations. - -The following temporary grounds may still prevent publication. However, publication will be enabled later through appropriate measures. - -- Legacy code could not yet be cleaned up and may contain security-relevant issues. - -- Security audits of the code have not yet been conducted. - -- The development process is not mature enough to enable secure publication. If the development process is not sufficiently established, it is possible that parts intended not for third parties might be published. For example, code commenting guidelines and test data generation must be adapted to the new publication scenario and function reliably. - -Through the following measures, software can be published despite security-relevant grounds: - -- Separate configurations (e.g. type of encryption used) from the software. - -- Outsource technically sensitive information (e.g. processes, calculations) that is not public into configurations or settings. - -- Plan, implement and regularly practise suitable organisational, personnel and technical measures. - -- Plan and carry out appropriate quality activities during publication. See the following section \'Analysis and preparation\'. - -**Tasks:** - -- Check the software for security-relevant grounds that would prevent publication. - -- Estimate effort required to resolve temporary grounds. - -- Plan measures to separate security-relevant information from the software\'s source code. - -- Ensure that the application contains no procedures that must not become public. - -**Decision:** - -Are there compelling security-relevant grounds that make publication impossible? - -## Clarification of publication - -This step clarifies who will publish the software. If the software was created by an external vendor, the publication can also be commissioned to that vendor. In this step, it is important to determine where the source code will be published and to establish appropriate governance accordingly. - -If the software was developed internally at the Confederation and the Confederation cannot or does not wish to publish it itself, a publication order can be placed with a supplier or the rights can be assigned (transfer of obligations to a third party). - -**Minimum release and support** - -EMOTA does not specify any requirements regarding publication. A minimum release of the source code fulfils the legal requirement. No further activities are required. The question of whether and to what extent support is offered and how actively the project is maintained can be answered using [Em002-4 OSS Community Guidelines.](./em002-4.md) - -**Open source software development (OSSD)** - -With open source software development (OSSD), in addition to publishing the source code, the entire development process is conducted publicly. Everything from requirements (issues) to source code is transparent. OSSD is supported by public communication tools (mailing lists, forums, etc.), a version control system (git), bug and feature lists, roadmap and developer tools. Through this transparent working method, the entire community benefits and enables collaboration across organisational boundaries. With this approach, no further publication activity is necessary upon project completion, as this was already considered at the project\'s start. - -**Tasks** - -- Create a rough effort estimation for the analysis phase. Depending on the size and complexity of the application, the effort ranges between three days and two weeks. - -- Release resources for further steps, particularly for analysis. - -- Agree in principle to publish the application as open source. - -**Decision:** - -Basic agreement and feasibility for publishing the application as open source is given. - -## Minimising effort - -The checklists and instructions are structured to minimise the effort required for releases. Consistent advance planning of the release at project start and development designed for release minimises effort. -Some administrative effort and costs will inevitably arise \[Le2023\]. These can potentially be recovered through communities with shared development costs (see [Em002-4 OSS Community Guidelines](./em002-4.md)). - -## Choice of publication language - -The choice of language must consider both the potential target audience and the team\'s working methods. Fortunately, translations are much easier with the aid of new tools. The official languages of the Confederation[^9] and English are possible options. - -If the project is internationally relevant, English should be the target language. For subsequent publication, it naturally makes little sense to change the language. - -At minimum, the README.md should be available in multiple languages so that interested parties can immediately see if the project is relevant to them. - -Public communication should primarily consider the target audience. It should also be considered that this is public communication from the Confederation. - -**Note**: With publication, the Federal Administration enters a new channel of public communication. If this is not done carefully and professionally, the public image of the Confederation can quickly -suffer. - -# Analysis and preparation - -**Objective:** The work required for open source publication is completed. -Decisions regarding licence and type of community have been made. This is done using [Em002-2.2 Analysis and Preparation Checklist](./Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt). - -## Source code analysis - -The source code to be published and other related documents are analysed prior to publication. This analysis ensures that no confidential information is published. - -If extensive source code is planned for publication, it is recommended to use appropriate automated tools for the following activities. - -The details are defined in Section E. - -**Tasks** - -- Check how existing code quality and guidelines have been implemented - (e.g. ISO/IEC 25010:2023[^10]). - -- Ensure that no sensitive (test) data is included, e.g. data based on real people or cases. - -- Update software documentation (see annex). - -- Delete unnecessary files or outdated documents and data. - -- Check source code for secrets/credentials.[^11] - -- Conduct targeted security tests and subsequently establish a (public) bug bounty programme.[^12] - -- Check all used libraries regarding licences and that the corresponding lists (attributions) are created. If a library is available under several licences, this should be indicated accordingly in the lists. - -- Describe deployment (CI/CD pipeline) and possibly set up a demo instance. - -These activities are independent of publication but are prerequisites for good software quality and ensuring compliance. Observing these measures simplifies collaboration, increases the quality of external contributions, and enhances the image of the software or the authority. - -## Licence selection - -**Refer to [Em002-3 OSS Licensing Guidelines](em002-3.md).** - -Internationally established licence texts should be used where possible and appropriate. Liability claims by licensees should be excluded to the extent legally possible. - -**Tasks** - -- Check any dependencies on existing licences. - -- For third-party code, check terms of use for compatibility with intended licence and replace code if necessary.[^13] - -- Select appropriate licence. - -Licence compatibility can be checked using tools such as ORT Toolkit,[^14] Black Duck,[^15] FOSSA[^16] or FOSSology.[^17] -The ToDO Group[18] provides an up-to-date overview of tools. - -**Decision:** - -- Determine and document under which the licence the software will be published. - -## Open source documentation - -A minimum set of documentation is expected with publication. Several documents have become established in the open-source ecosystem. This gives visitors a quick insight into the software including licensing. - -The following documents are expected: - - -|**Document**|**Description / Content:**| -|:--|:--| -|README(.md) |Serves as an entry document and provides a quick overview of the project\'s purpose,scope, status, licence and target groups.| -|LICENSE | Description of the chosen licence in the project| -|CONTRIBUTING(.md) | Describes the process of how to contribute to the project.| -|CODE_OF_CONDUCT(.md) | The Code of Conduct establishes expected social norms within the project. | -|CHANGELOG(.md) | Maintains a list of changes in software versions.| -|THIRD-PARTY-LICENSES(.md) | Description of third-party licences or used components.| -|Getting started | Brief guide on how to install and use the software.| -|Create Gitignore | Describes documents that will not be published, e.g. configurations, test data or generated content. Protected and sensitive information should be managed outside the project in appropriate designated tools and storage.| -|publiccode.yml| Structured metadata for describing the software, based on the standard https://yml.publiccode.tools/. The defined format makes the publication easier to find and reuse. Further information in Annex F.| - - -Table 1 -- Open source documents - -Further technical details of these documents are described in the annex. - -**Tasks** - -- Create standard documentation. - -- Include copyright, licence notices, and disclaimer in all files. - -- Depending on the publication platform, additional descriptions can be made. - -**Decision:** - -- Final decision to publish the application as open source. - -# Publication and announcement - -**Objective:** The application is published as open source and easily findable by third parties. All components are ready for publication and the community is built or established. This is done using [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt). To a certain extent, it involves recapitulating decisions already made. - -## Choice of platform - -There are several ways to publish source code. The following table provides an overview of possible source code management (SCM) systems and platforms. - -The suitable platform must be selected prior to actual publication. Some federal authorities are already represented on GitHub.[^19] In this case, it makes sense to use platforms already established. - -**Recommendation:** - -We currently recommend setting up an organisation on GitHub per federal authority for publishing source code. Within this organisation, corresponding projects (repositories) can be created and users with appropriate permissions managed. In the future, a central federal platform should be established. To maintain optimal user management and preserve the reputation of the Swiss Confederation, it is important to use fewer, but better-managed repositories. - -| **Platform** | **Properties** | -|:--|:--| -| GitHub[^20] | Microsoft's online platform with wide distribution. A large amount of open source software is hosted on GitHub. Offers many additional tools besides SCM.Available in both Free and Enterprise versions (subscription).| -| GitLab[^21] |Online platform from the company of the same name GitLab, which is itself published under an open source licence. Offers many additional tools besides SCM. Can also be operated locally, thus providing a degree of sovereignty. Available in both Free and Enterprise versions (subscription). | -| Bitbucket[^22] | Atlassian's online platform, specifically integrated into its ecosystem. Available in both Free and Enterprise versions (subscription). | -| Internal SCM system | If own SCM platform is provided, it can also publish and make certain repo/projects available. Operation must be ensured. | -| Federal platform | There is currently no central federal platform for publishing software. A measure to this effect is proposed in [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](./em002.md). | -|Website, public FTP server, etc. | EMOTA does not define how software should be published. A minimum release[^23] can also be done on a website or other publicly accessible resources. However, this is not suitable for sustainable collaboration in the sense of open source.| - -Table 2 -- Platforms for publishing open source software - -If the software is published jointly with an external partner or organisation, care must be taken to ensure that appropriate permissions and access to the source code are available. - -**Tasks** - -- Evaluate suitable platform, including corresponding organisation/project. - -- If not yet clarified, determine project/repository naming. - -- Define and check permissions on the repo. - -- Ensure appropriate governance and any replication of source code. - -**Decision:** - -- Platform for publication has been appropriately chosen. - -## Software publication - -When the prerequisites are clarified, the software can be published. - -**Tasks** - -- Check prerequisites against the [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt). - -- Access to platform is available and governance clarified. - -- Publication of source code and documentation by the developer. - -## Communications - -After actual publication, further communication activities can be initiated by and within the federal authority concerned. These help with distribution and bring the desired added value from publication. - -**Tasks** - -- Description in repo hosting, security settings, etc. - -- Internal and, if applicable, external communication - -- Write a message to the community. - -- Make the application known within the organisation and in specialist committees, promote its use and contributions. - -- Create a publiccode.yml[^24] file in the repository for the Federal Administration's OSS Catalogue.[^25] - -## Community building and maintenance - -When publishing software, a community can develop that can contribute to the software through contributions (pull requests), questions, documentation suggestions, etc. To have an active community, considerable effort is required for both building and continuous maintenance. A well-functioning community minimises unwanted forks of the software. The goal here is to activate the added value of the community through targeted activities. Even with minimum publication, handling feedback and questions about the software should be defined. - -**Tasks** - -- Clarify who potential users or interested parties are. - -- Determine the appropriate form for the specific application using the [Em002-4 OSS Community Guidelines](./em002-4.md). - -- Build the community. - -- Community building activities. - -# Annex - -## Changes from previous version - -- Sections 4.3 and 5.3: Publication supplemented with publicode.yml - -- Annex F \'Public Code\' was added - -- Various minor editorial changes and improvements - -## References - -See *Em002 Strategic Guidelines for Open Source Software in the Federal Administration*. - -## Abbreviations - -See [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](./em002.md) and [Em002-6 FAQ about OSS](./em002-6.md). - -## Accompanying documentation [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- Documentation - -## Source code documentation - -The documentation should be part of the project\'s source code to ensure that changes to the documentation are stored in a revision-secure manner and the documentation is versioned alongside the project. This automatically ensures that the documentation, if properly maintained, -does not diverge from the project\'s development status, and documentation for older versions of the project can be retrieved at any time. - -Furthermore, this gives third parties the opportunity to easily contribute changes to the documentation. - -Markdown should be used as the markup language for the text formatting as it is easy to write, widely used, and machine-readable. Additionally, markdown documents are displayed in a well-readable target format by all common platforms. Markdown documents can be rendered into any target format independent of the platform used, using static site generators such as Jekyll, MkDocs, Gatsby, or Sphinx, for example, with the corporate identity specifications of an administration. - -## Documentation recipients and structure - -The project documentation should address both end users and technical professionals, thus not focusing solely on technology. For language selection, see Section 3.6. This supports the software\'s distribution. - -A README.md file serves as the entry document. Files with this name are recognised and displayed as the entry point to the documentation by all common platforms.[^26] - -README.md should provide a quick overview of the project\'s purpose, scope, status, licence and target groups. Specifically, README.md should include the following points: - -- Software name - -- Brief description of the software\'s purpose and function. Scope and possible limitations - -- Installation guidelines - -- How to use the software - -- Reference to any demo instance - -- Support and contact details - -- How to contribute to open source software (Contributing) - -- Licence used (Licence) - -- Project status / development status - -## Emphasising open source and licence storage - -Directly after the mission statement, it should be clearly and unambiguously stated that the project is open source software. The licence used by the project should be specified with the corresponding SPDX identifier[^27] and linked to the specific licence text in the LICENSE file. Licence templates typically include a variable part (e.g. project name, copyright year, author\'s name) that must be adapted in the LICENSE file. - -Most platforms recognise licences in a LICENSE file and offer clear information about the licence, e.g. a brief summary of the licence terms. - -It is recommended to add a minimum licence and copyright header to each source file that is created. Existing headers in existing files should not be changed. If contributing to a project that has clear standards for headers, these should be followed. - -For more details see: Producing Open Source Software: State That the roject is Free.[^28] - -## Current development status - -To quickly show the project\'s state, the current development status should be documented in README.md. It is important for readers to know whether the project is in a mature state or at the beginning of development, whether it is actively maintained, and how frequently new versions are published. - -This section can describe what type of third-party support is currently most important for the project. This could be, for example, a developer with specific technological knowledge or someone to revise the project\'s documentation. - -For further details, see Producing Open Source Software: Development Status.[^29] - -## Demo instance - -For applications, it is recommended to provide a demo instance so that the application can be tried without installation effort. Depending on the type of application, the demo instance can be the productive installation or a test stage. It is important that readers can access the corresponding instance as independently and directly as possible. - -As an alternative, many open source projects provide tools for easily starting the application. This can be done using containers, portable applications or install scripts, for example. - -## Subject matter expert and project owner - -The README.md file should name the primary subject matter expert so that other interested administrations and organisations can make contact as directly as possible. - -Personal email addresses should not be used. - -The README.md file should also briefly describe which organisation is the project owner, especially if an association has been formed for the project. - -# Installation documentation - -For applications, README.md should reference installation documentation that describes hardware and software requirements, which infrastructure components (for example, databases) are used, and how the application can be installed and operated. - -## Developer Guidelines - -The entry point for the Developer Guidelines should be stored in a markdown file CONTRIBUTING.md, which is linked in README.md. The Developer Guidelines are part of the extended documentation for developers who want to contribute to the project and primarily focus on collaboration and communication within the project rather than on technology. - -The Developer Guidelines should include the following points and reference the corresponding documents where appropriate: - -- A reference to the project\'s Code of Conduct. The Code of Conduct establishes expected social norms within the project. - -- It is recommended to choose or build upon the Contributor Covenant Code of Conduct licensed under CC-BY-4.0[^30] as the Code of Conduct.[^31] - -- A note that the project conducts code reviews in the form of GitHub pull requests, with a reference to the GitHub pull request documentation. - -Finally, reference should be made to the Developer Documentation. - -## Developer Documentation - -While the Developer Guidelines describe the collaboration and social norms of the project, the Developer Documentation focuses on the technical aspects of participating in the development of the project. It should describe at least the following points: - -- What technical dependencies the project has and which tools are necessary for project development. - -- What formal rules apply to the project\'s source code, for example regarding source code formatting. - -- How the project\'s source code is organised and how functions can be technically tested. - -- An architecture sketch with a rough description of the architecture, preferably including context demarcation and rough component view.[^32] - -- For applications: How the application can be started for development or debugging purposes and what infrastructure components are necessary for this. - -# Accompanying documentation for [Em002-2.2 OSS Analysis and Preparation Checklist](em002-2.2.md) -- Source code - -## Source code history - -A project\'s source code is usually stored in a source code management (SCM) system such as GitHub. These systems store not only the current state of the source code but also changes that have been made to the source code over time. In particular, this includes deletions from the source code, including deleted files. - -In addition, the SCM contains meta-information about changes to the source code, such as the author\'s name and email, or PGP signatures for signed commits and tags. - -## Sensitive, proprietary or confidential data - -The source code and source code history of the project may contain publicly available data, such as a postcode directory, randomly generated data or synthetic data. - -The source code and source code history must not contain any sensitive or confidential (personal) data or information as defined by the Federal Act on Data Protection (FADP) and the Information Security Act (ISA). This includes, in particular: - -- User names and passwords or other secrets such as private keys, access tokens or certificates. - -- Internal DNS names, URLs, host names, IP addresses, network structures or drive names. - -- Names, addresses, pictures or similar personal data without the consent of the person concerned - -- Anonymised or pseudonymised data (because it is possible to undo anonymisation or pseudonymisation) - -Even if the current state of the source code is free of sensitive, proprietary or confidential data or information, such data or information may still be retrieved from the SCM system history if it was ever part of the source code or SCM meta-information in the past. Cleaning up the current source code state will not completely remove this information.[^33] - -Therefore, if in doubt, it is recommended to completely remove the source history after cleaning up the source code, before publishing the source code. - -The names and email addresses of the authors of the source code are usually available directly in the source code or in the SCM metadata, for example in GitHub commits or annotated GitHub tags. From a legal point of view, this is not a problem, as the developer company is responsible for regulating the publication of such information. However, it is recommended that the developer company or internal federal employees are made aware that the names and email addresses of the source code authors may be disclosed when the software is published. - -## Removing author information - -The history of the software can be changed to hide author information. Tools[^34] can automate this step to a large extent. - -Removing author information removes attribution, traceability, and contact information. The effort involved should not be underestimated, depending on the volume of source code. For these reasons, author removal is not recommended. Names may be published if a) consent has been obtained from the persons concerned and b) there are no security-relevant reasons for not doing so. - -## Consideration of library licences - -Virtually every project uses third-party libraries (software libraries, dependencies) to access commonly used functions without having to code them. These libraries usually depend on other libraries, resulting in multi-level dependencies (transitive dependencies). Depending on the programming language, even small projects can have hundreds of dependencies. - -The results of this clarification must be considered when choosing a licence in accordance with [Em002-3 OSS Licensing Guidelines](em002-3.md) and in [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt). - -For each of these dependencies, ensure that its licence is compatible with the project licence. Dependencies that are not under an open source licence or which have not declared a licence or use a viral licence that does not match the project licence are particularly problematic. Some libraries are licensed under more than one licence and allow the user to choose one. - -- In all major programming languages, the dependencies of the project (including transitive dependencies) and the licences of the dependencies can be automatically listed. These include: - -- The Project Info Reports plugin for the Apache Maven package manager for Java projects, which uses the dependency report to generate an HTML output of all used libraries, including the declared licence.[^35] - -- The NPM Licence Checker for the NPM Package Manager for JavaScript projects, which can output all libraries used, including the declared licence, in various formats, e.g. CSV.[^36] - -- Pivotal\'s Licence Finder, which supports various package managers and programming languages, including Ruby Gems, Python Eggs and Godeps.[^37] - -# Use of libraries with proprietary licences - -Libraries under a proprietary licence are generally problematic in open source projects and usually cannot be used, especially if the source code has been published under a viral licence such as the AGPL. - -Please contact the vendor and the legal department of the relevant office to check whether and under what conditions the proprietary library can be used in your project. - -## Using package managers - -Virtually all popular programming languages provide package managers for managing their dependencies, such as Apache Maven for Java projects, NPM for JavaScript projects or NuGet for .NET projects. - -When using a package manager, the dependencies used by the project are no longer directly part of the project\'s source code, for example by copying the dependency\'s source code into the project or by copying the dependencies into the project in binary form. Instead, the project obtains all its dependencies via the package manager\'s declarations. - -This allows all dependencies to be listed and referenced correctly. It also prevents unintentional modification of dependency code. If changes are necessary, they must be made directly at the source of the dependency. - -## Project licence declaration in the package manager descriptor - -The project should declare its licence in the appropriate package manager descriptor, using the SPDX identifier[^38] so that the project licence can be issued by the package manager. This is particularly important for libraries so that users of the library can automatically query their licence via the package manager. - -## Attribution and copyright notices - -Many libraries are subject to a licence that requires the library user to give an original copyright notice or attribution. - -These include the following licences (excerpt): - -Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons \'Attribution\' (CC BY), MIT, ISC - -For others, see the list of OSI-accredited licences.[^39] - -In practice, this concerns almost all libraries used. As the number of libraries used in small projects is already very high, a legally correct copyright notice or the necessary attribution is only possible with a great deal of effort. - -It is therefore recommended to proceed as follows: - -- Make a list of the libraries used, using the Package Manager\'s mechanisms or tools such as the NPM Licence Checker or Pivotal\'s Licence Finder. - -- Prepare the list manually so that it contains the following information: official name of the library project, website of the library project, licence used for the library as SPDX identifier with a link to the licence text. - -- Place the list in the project\'s source code, e.g. in a file THIRD-PARTY-LICENSES.md. - -- For applications: Include a link pointing to THIRD-PARTY-LICENSES.md in an \'About\' or \'About this application\' dialogue. - -- The \'About\' dialogue is widely used for this purpose, for example in Google Chrome (in the \'About Chrome\' dialogue). - -- For Libraries: Refer to README.md under THIRD-PARTY-LICENSES.md. - -- As part of the code review process, ensure that changes to the libraries are added to THIRD-PARTY-LICENSES.md. - -# Example Codeblock THIRD-PARTY-LICENSES.md - - - - - -
- This project uses open source software: -
    - * Spring Boot, http://projects.spring.io/spring-boot/ licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0) -
-
    - * caniuse-db, https://github.com/Fyrd/caniuse licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) -
-
- -## Accompanying documentation for Em002-2.3 OSS Release and Publication Checklist - -### Publication with publiccode.yml - -Publiccode.yml is a metadata standard for software repositories that contain software developed or acquired by public administrations. The aim is to make this software easier to find and reuse. The metadata standard is internationally established and publicly described at . A publiccode.yml file typically contains information such as title and description (possible in several languages), development status, contact details, licence information, etc. Country-specific extensions are planned for Switzerland. - -A yml file must be created in the main directory of the repository for each software. If the solution consists of several (auxiliary) repo, one file is sufficient, as this describes the use case of the solution. - -Using the structured data in publiccode.yml files, an [OSS Catalogue](https://www.opensource.admin.ch/) -([opensource.admin.ch](https://www.opensource.admin.ch)) is generated for the entire Federal Administration. The Catalogue provides an overview of published software and makes it easier to find and reuse existing solutions. - -If a new repository or organisation is created, it should be reported for inclusion in the OSS Catalogue by email to opensource@bk.admin.ch. - -In addition to the OSS Catalogue, a graphical editor and validator for publiccode.yml files is also available. - -OSS Catalogue and Editor: https://www.opensource.admin.ch/ - -## Further sources and licence - -The checklist, the accompanying documentation and related templates are based in part on the following sources: - -- Google Open Source Docs by Google LLC, licensed under CC-BY-4.0[^40] - -- Producing Open Source Software, How to Run a Successful Free Software Project by C-BY-SA-4.0[^41] - -- GitHub Healthy Contributions[^42] - -- Standard for Public Code[^43] - -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: Federal Act *\[EMOTA2023\]* - -[^6]: Art. 332 CO in conjunction with. Art. 6 para. 2 FPA - -[^7]: General Terms and Conditions of the Swiss Confederation, in - particular Section 25.1 - - - -[^8]: Information Security Act, ISA. Art 6 Information security. - - -[^9]: - -[^10]: ISO/IEC 25010:2023 - Systems and software Quality Requirements - and Evaluation (SQuaRE) - -[^11]: - -[^12]: - -[^13]: See Em002-3 regarding selection of third-party code/libraries for - a technology stack and regarding compatibility of the licence. - -[^14]: - -[^15]: - -[^16]: - -[^17]: - -[^18]: - -[^19]: The website gives an overview of - organisations and authorities that are active on GitHub. - -[^20]: https://github.com/about/ - -[^21]: https://about.gitlab.com/ - -[^22]: https://bitbucket.org/product/en - -[^23]: A minimum publication only includes the publication of the source - code and other minimal artefacts. This type of publication fulfils - EMOTA requirements. However, no added value is achieved through the - publication. - -[^24]: The metadata standard describes - the software. The defined format makes the publication easier to - find and reuse. Further information in Annex F. - -[^25]: OSS Catalogue: https://www.opensource.admin.ch - -[^26]: For more information on creating a readme file: - - -[^27]: SPDX identifier - https://spdx.org/about - -[^28]: https://producingoss.com/en/getting-started.html#state-freedom - -[^29]: https://producingoss.com/en/getting-started.html#state-freedom - -[^30]: https://creativecommons.org/licenses/by/4.0/ - -[^31]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html - -[^32]: Architecture framework MMB (Bund Modelling Method) or arc42. - http://arc42.org/ - -[^33]: One possibility to clean up a repo is offered by the tool [BFG - Repo-Cleaner:](BFG%20Repo-Cleaner:) - https://rtyley.github.io/bfg-repo-cleaner/ - -[^34]: https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/ - -[^35]: Plugin info - - -[^36]: NPM Licence Checker https://github.com/davglass/license-checker - -[^37]: Licence Finder from Pivotal - - -[^38]: SPDX identifier - https://spdx.org/ - -[^39]: Open source licences are licences that comply with the Open - Source Definition -- in brief, they allow software to be freely - used, modified, and shared. https://opensource.org/licenses - -[^40]: Google Open Source Docs -- - -[^41]: Producing Open Source Software, How to run a Successful Free - Software Project - - -[^42]: [GitHub Healthy - Contributions](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions) - -[^43]: Standard for Public Code -- diff --git a/docs/en/em002-3.adoc b/docs/en/em002-3.adoc new file mode 100644 index 0000000..53cd480 --- /dev/null +++ b/docs/en/em002-3.adoc @@ -0,0 +1,697 @@ += Em002-3 OSS Licensing Guidelines +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +*Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +''''' + +== Management summary + +It is recommended that one of the following two licences be strategically defined in the Federal Administration when a new project is started: + +* *AGPL licence*: Copyleft effect desired. Changed code should in any case flow back into the general public and can then also be reintegrated by the Federal Administration. It is recommended to use the latest version of the licence. This is the best way to fulfil the principle of 'public money – public code'. The rights of third parties, especially in the case of further developments, can weaken this to LGPL. +* *MIT licence*: It should be possible for third parties to develop proprietary applications based on the Federal Administration's code. If a non-endorsement is specifically required, BSD-3-Clause is to be preferred. + +The following decision aid can be used to select the licence: + +image::./assets/em002-3/media/image1.png[Simplified licence selection guide] + +Figure 1: Simplified licence selection guide + +To a certain extent, these two licences form the two extremes in the spectrum of OSS licences. It can be very useful to select a more suitable licence for a specific project. This guide is intended to provide concrete assistance. + +If the analysis of the software libraries reveals that a different licence must be used, the developers will draw the project management's attention to this. The analysis is set out in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. + +When working on existing projects, all OSI-compatible licences are generally acceptable. + +== Introduction + +Article 9 of the Federal Act of 17 March 2023footnote:[SR 172.019] on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) stipulates that the federal authorities must publish and license software that they develop or commission as open source software. + +This document has the following objectives: + +* Introduction to the topics of software copyright and OSS licences. +* A presentation of which OSS licences are unproblematic for use in the Federal Administration. Licences not mentioned in this document and software under such licences may not be used without an additional review of the contractual provisions by the responsible legal service. +* Assistance in selecting a licence for the development or procurement of a project under Art. 9 EMOTA. + +== Copyright and licences: Fundamentals + +Copyright law establishes both moral rights and economic rights (exploitation rights). The moral rights include, for example, the right to recognise authorship or the right to determine whether and when the work is published. Exploitation rights include, for example, the right to make or distribute copies of the work. + +The Federal Act of 9 October 1992footnote:[SR 231.1] on Copyright and Neighbouring Rights (CopA) provides for a number of other moral rights and exploitation rights (see Art. 8 ff. CopA). These rights accrue directly to the author at the same time as the work is created. + +Art. 2 CopA sets out the conditions under which copyright protection is granted. A protected work within the meaning of the law only exists if these requirements are met. + +The prerequisites are: + +* The work must have been created; simply finding the work is not sufficient. Research data, for example, i.e. the results of experiments, cannot be classified as works. +* The creation must be 'intellectual', i.e. originate from a human being. +* The work must have been realised in a perceptible manner. The mere idea behind a work is not protected, only its external form, e.g. a printout of a text on paper or a performance of a piece of music. +* Individuality: Finally, the work must have a certain minimum degree of individuality. A work that everyone would design in the same way is not protected. + +A wide variety of works can be protected, such as literary or scientific texts, musical works, photographic, cinematographic and other visual or audiovisual works. + +According to Art. 2 para. 3 CopA, computer programs are also works if the aforementioned requirements are met. + +The author alone is entitled to the copyrights upon their creation. Only the author can prohibit someone else from carrying out the corresponding actions. However, the author can exercise their rights not only themselves: + +* They may transfer their rights to third parties (e.g. by selling them). The new rights holder can then assert these rights in the same way as if they were the author. +* Alternatively, the author may also license their rights to third parties. Simply put, a licence is a contract under which the rights holder allows a third party to use the work. The author retains the rights, but waives their enforcement vis-à-vis the licensee. + +If a computer program is created in an employment relationship, the employer receives an exclusive licence for its use (Art. 17 CopA). Employees are thus essentially left with only the moral rights to the software (or, depending on the legal opinion, only a core part thereof). This is the same legal situation as under the Federal Personnel Act. + +== OSS licences + +=== Fundamentals + +OSS is essentially characterised by the following features (based on a definition of the Open Source Initiative _[OSI]_footnote:[https://opensource.org/]): + +* Unlimited and free redistribution of the software is permitted; +* The software is available in source code form; +* Modifications to the software and their redistribution under the same licence are generally permitted; +* No individuals or groups of people may be excluded from using the software, and no areas of application may be excluded (especially not commercial use); and +* The distribution of the software together with other software (such as closed source software) must not be restricted. + +The most common motives for using OSS are initially the cost savings through the use of the already substantial pool of freely usable software. Companies that frequently use OSS are often able to save considerable portions of their IT budget through the use of OSS. + +Freely available code can also be easily adapted to one's own needs. Moreover, choosing OSS avoids vendor lock-in.footnote:[https://en.wikipedia.org/wiki/Vendor_lock-in] + +=== Open source licences + +Open source licences are, first and foremost, normal licence agreements for computer programs. + +In contrast to normal licence agreements, however, OSS licence agreements come into effect without further ado when only one of the free forms of use described in the licence is exercised (for example, by copying, redistributing or modifying software). + +=== Copyleft versus permissive + +==== General + +An open source licence according to the OSI may contain a 'copyleft' provision. Changes to software licensed accordingly must be offered again under the same conditions as those that existed for the original software. Anyone who makes such changes must, when distributing the open source software in the form of machine-readable object code, also offer the source code to recipients. + +Expressed as defined by the Free Software Foundation, the copyleft effect protects developers' freedom and thus ensures that once free software always remains free. + +With copyleft licences, a kind of exchange takes place between the community and the companies using it. The users, who are obliged to put their own developments back under the respective licence in return for the benefits from the existing software pool, thus contribute to the further development of the software pool. As a result, both sides stand to benefit. + +The copyleft provision has a certain 'contagion effect': if copyleft-licensed software is integrated into previously proprietary software, the originally proprietary software must be disclosed under a compatible open source licence. + +Accordingly, when using copyleft-licensed source code, care must be taken to integrate it only where the resulting software can and should be published under an open source licence. + +If an open source licence does not contain a copyleft provision (permissive open source licence), the licence for revised versions of the code can be freely chosen. In particular, it is also possible to put modifications back under a proprietary software licence and integrate the corresponding source code into proprietary software. + +Essentially, open source licences can be divided into *the following categories*: + +. open source licences with *strong copyleft*; +. open source licences with *weak copyleft*; and +. *permissive* or *non-copyleft* open source licences. + +==== Open source licences with strong copyleft + +When using an open source licence with strong copyleft, new versions derived from the original software, if passed on to third parties, must be placed under the conditions of the original licence and made available to these third parties as source code. + +The following two licences are considered the relevant open source licences with strong copyleft in the market: + +* GNU General Public Licence (GPL); a large proportion of OSS is licensed under this today +* GNU Affero General Public Licence (AGPL) + +The main difference between GPL and AGPL relates to the type of use that triggers copyleft. With GPL software, the modified source code only needs to be offered if the new software version is offered to third parties as an executable program (e.g. as a mobile app). If the software is only made available via the internet (from one's own cloud from one's own servers), for example in the form of Software as a Service' (SaaS) or an application programming interface (API), this does not trigger copyleft. + +If the software is under the AGPL, the modified source code must also be supplied when the functionality of the software is offered via a website or programming interface. The AGPL is thus even stricter than the GPL. + +With strong copyleft licences, copyleft affects not only the respective software module (library) but the entire software program into which a copyleft-licensed software module may be embedded. The aforementioned 'contagion effect' thus takes hold. + +==== Open source licences with weak copyleft + +Licences with weak copyleft also require that changes to their source code be released to third-party recipients under the original open source licence. + +In contrast to licences with strong copyleft, however, they do not have the effect of 'infecting' other delimitable software components (other libraries or the main program itself) with their licence. This allows the integration of open source software with weak copyleft into proprietary software or into software with other OSS licences without having to be released under the original licence. + +These are the most commonly used open source licences with weak copyleft: + +* GNU Lesser General Public Licence (LGPL) +* Mozilla Public Licence 2.0 (MPL) +* Common Development and Distribution Licence (CDDL) +* Eclipse Public Licence (EPL)footnote:[In addition to the Eclipse Publice Licence (EPL-1.0), there is also the Eclipse Distribution Licence (EDL-1.0). + +While EDL corresponds to the BSD 3 clause, EPL is a weak copyleft licence.] +* Microsoft Reciprocal Licence (Ms-RL) +* European Union Public Licence (EUPL)footnote:[The EUPL itself has a strong copyleft, but due to the opening clause, a transfer to licences with a weak copyleft is possible, so that the protection is limited.] + +==== Permissive open source licences + +Licences without copyleft effect are characterised by the fact that they do not impose any requirements on the licensee regarding the licensing of their derived software, and therefore neither their new source code nor changes to the open source software need to be disclosed to third-party recipients. This enables the development of proprietary software products through the integration of software under permissive open source licences. + +Examples of permissive licences are: + +* MIT Licence +* Apache Licence 2.0 +* Berkeley Software Distribution (BSD) Licence (BSD 2-Clause and BSD 3-Clause) +* Microsoft Public Licence (Ms-PL) + +=== Compatibility of open source licences + +Programs usually consist of a variety of software components and modules that can be connected to each other in different ways. In software development, existing open source components are often integrated into proprietary, internal applications and solutions. As soon as these become accessible from outside via a website, APIs, software distribution or by another means, attention must be paid to the compatibility of the respective open source licences, because then copyleft can take effect. + +If derivative works that are under a certain licence may only be distributed under the same licence conditions, this has the consequence that other open source licences with other or contradictory licence obligations for derivative works cannot be used. + +Some open source licences contain so-called opening clauses, which allow the use of code licensed under them in projects that are under other licences. For example, the LGPL, Version 2.1, also allows the use of the code under the GPL. The GPLv3 contains, among other things, a compatibility clause for the AGPL and the Apache License 2.0. The EUPL is designed very openly and contains a long list of compatible licences in the annex, especially those with weak copyleft, such as the LGPL. This has the consequence that the strong copyleft protection actually specified in the licence is indirectly weakened. + +The following diagram depicts the dependencies of the most important open source licences (Goldstein 2018). The representation is based on the visualisation by David A. Wheeler, who analysed the compatibilities of the various licences and their version numbers (Wheeler 2007) and has been further developed together with information from https://www.gnu.org/licenses/license-list.en.html[https://www.gnu.org/licenses/license-list.en.html]footnote:[Another, extended representation has been used by GEANT in their confluence: "Software Licence Selection and Management in GÉANT - GEANT Software Development Support - GÉANT federated confluence", https://wiki.geant.org/pages/viewpage.action?pageId=1032978710. You will find a few additional licences there.]. + +The diagram should be read as follows: code according to a licence listed earlier in the chain can be incorporated into software that is published under a licence listed later in the chain. For example, code licensed under the modified BSD can be placed under an LGPL or GPL licence variant, but not vice versa. Public domain means that the work is not subject to any copyright restrictions. + +image::./assets/em002-3/media/image2.png[Compatibility of open source licences] + +Figure 2: Compatibility of open source licences (based on diagram by David A. Wheeler, 2007 and https://www.gnu.org/licenses/license-list.en.html) + +Important: As licence compatibilities are always relevant, the development teams/service providers should check the development stacks with libraries for possible compatibility problems in advance. This means that before the use of a library is waved through, it should be checked whether the library's licence is compatible with the relevant licences preferred by the Federal Administration, in addition to considering security and homogeneity in the development stack. + +[[licences-for-pure-usage]] +== Licences for pure usage + +This section deals with the situation where software under an OSS licence is to be used, but this software should not be modified, or modifications are only to be used internally. + +The following licences are generally unproblematic when software is used by federal authorities. However, the corresponding conditions, notably copyleft where applicable, must be adhered to. + +Under certain circumstances, the licence of a pre-existing software module determines the possible licences for the overall product (see Section 4.4). + +Some licences are incompatible in combination (see Figure 2). + +[cols="1,1,3",options="header"] +|=== +|Licence |Copyleft |Special features + +|*MIT* +|No +|Preferred licence of the Federal Administration if further distribution is sought and third parties are to be allowed to develop proprietary software from it again. + +|*Apache 2.0* +|No +|Apache is a very widely used licence known for the projects that are under the Apache Foundation. Use of licensors' trademarks excluded, except for describing the work. + +|*GPL v3* +|Yes +a|This is THE classic copyleft licence. + +Copyleft also applies when GPL-licensed parts are incorporated into an entire program. Prohibition of digital rights management. Special compatibility rules. + +|*LGPLv3* +|Weak +a|Reduced copyleft licence developed specifically for software libraries. + +In contrast to GPL, LGPL allows closed (i.e. proprietary) code to be combined with LGPL code under certain conditions. + +Examples include standard libraries such as glibc. LGPL allows the program, as part of which the library is distributed, to be placed under the GPL. + +|*Affero GPLv3 (AGPL)* +|Yes +a|SaaS use also triggers copyleft. Otherwise analogous to GPLv3. + +This licence closes the loophole in the GPL, which meant that no release was required when used for SaaS offerings. + +With this licence, the Federal Administration can guarantee that enhancements to the code also benefit the general public in the case of SaaS, and best supports the principle of *public money – public code'.* + +|*BSD-3* +|No +a|General, liberal licence. + +Names of authors may not be used to promote derivative works (advertising clause) + +|*European Union Public Licence (EUPL)* +|Weak +a|Special licence used for the EU. + +Particularly useful as a basis for European projects. + +Licence considering European law.Release under certain compatible licences explicitly allowed. +|=== + +Table 1: Licences unproblematic for the federal authorities (according to _[Sc2024]_) + +Other licences may be used. In these cases, it may be necessary to consult the legal department of the respective office. + +== Licence for own projects or creation and for contributions + +This section concerns the following cases: + +* Further development / contribution +** where federal authorities further develop existing software; or +** develop new software, but rely on existing OSS software libraries; and +** make the corresponding software available to third parties. Third parties also include organisations of the decentralised Federal Administration, provided they have their own legal personality. If the further developments are only used internally and not made available to third parties, only <> applies. +* Own projects / creation / publication This section concerns cases in which the federal authorities develop new software. This is likely to be rare, as most developments rely on existing open source software libraries. ++ +For completely new developments, a licence type should be chosen that enables a broad and sustainable basis for further developments. For this, it is important that the licence in question should be widely accepted in the relevant developer community. + +The compatibility check is carried out according to link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], Section 7.4. The compatibility of the licences is shown in Figure 2. + +The following dimensions should be considered: + +* Use case +* Desired checking link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] +* Ease of building a community link:em002-4.adoc[Em002-4 OSS Community Guidelines] +* Ease of application +* Legal certainty +* Distribution + +Licences according to Section <> are preferred. + +The following *copyleft licences* should be used as a priority by federal authorities, especially if sustainable open development is sought and the copyleft effect of inheritance should apply. This ensures that software paid for by the public and all derivatives thereof remain open. This best fulfils the principle of '*public money – public code*' and is *the preferred recommendation for the Federal Administration.* + +Recommended licences in descending order: + +* *AGPL v3* +* GPL v3 +* LGPL 3.0 +* European Union Public Licence (EUPL) + +The following licences should be used by federal authorities when *no copyleft is desired* or required (in descending order): + +* *MIT* +* Apache Licence 2.0 +* BSD v3 + +When collaborating on existing projects, the following licences can also be used without problems: + +* Mozilla Public Licence +* Microsoft Public Licence + +If another licence is to be used, it is recommended to briefly justify this in link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. + +*According to Art. 9 para. 4 EMOTA, internationally established licences should be used in all cases.* + +Additional tools for checking licence compatibilities include: + +* ORT Toolkit (https://oss-review-toolkit.org/) +* Black Duck (www.blackducksoftware.com), +* FOSSA (http://www.fossa.com[www.fossa.com]), +* the Open Source Licence Comparison Grid (https://www.cmu.edu/cttec/forms/opensourcelicensegridv1.pdf) +* FOSSology (https://www.fossology.org). +* OpenCode process: https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen[https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses] + +== Use cases and suitable licences + +The following table and diagram show how appropriate licences can be selected for open source software based on different use cases. + +[cols="2,2,3",options="header"] +|=== +|*Use case* |*Licence(s)* |*Justification* + +|Use and contribute to existing project +|*Licence as specified by the project* +|Necessary for legal reasons. + +|Licence is forced by the use of existing parts (licences with copyleft) +|*Use licence compatible with the parts.* +a|Necessary for legal reasons. + +NB: A number of libraries are available under several licences. + +Only one of the licences has to correspond One of the purposes of multiple licensing is to ensure that libraries can be used both with and without copyleft. + +|Existing ecosystem with preferred licence (e.g. it is a plugin for software released under MIT licence. Then using an MIT licence would be most purposeful, as all other users expect this and the software integrates into the ecosystem) +|*Use licence if it is on the list, otherwise use the same licence as much as possible* +|Acceptance in the community is central. + +|The goal is the widest possible distribution, e.g. for a reference implementationfootnote:[For example, to make a law easier to implement, a reference implementation can be commissioned by the federal authorities. See e.g. https://ech.ch/de/ech/ech-0238/1.0] (e.g. for software also to be used in commercial solutions). +a|*MIT* + +BSD v3 + +Apache Licence 2.0 + +LGPL v3 +|In this case, no copyleft should be used. + +|Modifications to the code should flow back to the federal authorities +a|*AGPL v.3* + +GNU GPL v.3 + +EUPL +|AGPL also enforces release by third parties when used in the cloud, GPL and EUPL do not. + +|SaaS solutions should not be exempt from the backflow of code changes +|*AGPL v.3* +|AGPL also enforces release by third parties when used in the cloud. + +|Easy collaboration with the community is important. +a|*AGPL v.3* + +GNU GPL v3 + +Apache Licence 2.0 +a|GPL preferred to keep the software free. + +Apache contains rules for community governance, additional rules for contributions (you may not specify a licence other than Apache; the contribution as such is not regulated in more detail, so if a CLA exists, that should take precedence), a patent licence, rules for patent licensing. Especially also that anyone who asserts patents against another contributor loses their patent licence under the Apache licence. + +The rules that the Apache Foundation sets for contributions are decisive. Apache therefore makes sense if the project governance is to be built primarily according to Apache. + +|Small, universally usable component (library) or small piece of software where sustainability or maintenance by a community is not important +a|*MIT* + +Apache Licence 2.0 + +BSD v3 + +LGPL v3 +a|LGPL stipulates a copyleft only for the component itself, but not for the entire project into which the component is inserted. + +The other licences are permissive. + +|It must be simply and permissive; control is not important +a|*MIT* + +Apache Licence 2.0 + +BSD v3 +|Maximally permissive + +|It is important for the federal authorities what happens to the code and they want to receive as many improvements as possible. +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|It should be prevented that the software becomes proprietary and is positioned as a competitive product on the market +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|It should be prevented that the federal authorities become dependent on individual suppliers ('vendor lock-in') +a|*AGPL v.3* + +GNU GPLv3 +|The copyleft prevents a supplier from gaining a unique position over time by using the Confederation's software in a proprietary product, which could again lead to a dependency for the Confederation on this supplier. +|=== + +Table 2: Licence to be used depending on the use case for the release of new software in accordance with Art. 9 EMOTA *(bold = recommended where no grounds exist to the contrary)* + +image::./assets/em002-3/media/image3.png[Extended decision tree for licence selection in the Federal Administration] + +Figure 3: Extended decision tree for licence selection in the Federal Administration (if not AGPL or MIT) + +The bill of materials in Figure 3 is the software bill of materials (SBOM) of all pre-existing software libraries and sub-programs that have been incorporated into the overall solution. Each library has its own licence. Depending on how this is compatible with others (see Section 4.4), the possible selection of licences for the publication is limited. + +One last point can also influence the decision: *changing from a more restrictive licence to a less restrictive one is easier afterwards*. In the opposite case, a forkfootnote:[For definition see link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration].] is almost unavoidable. + +== Special legal topics + +=== International aspects + +The essential legal issues of OSS in practice are mainly of a licence contract nature. + +Regarding licence law issues, the law chosen by the parties applies first (for example, the Mozilla Public License MPL contains a choice of law for the defendant's law in Section 8). + +If there is no choice of law, which is the case with all other licences presented here, the law of the licensor's state generally applies. So when federal authorities license software from foreign licensors, the law of the respective country applies. If multiple contributors are involved, this can lead to complex situations. Conversely, Swiss law applies in the event of any disputes between foreign licence holders and the federal authorities as licensor. + +The question of which aspects are contractual in nature and which are copyright in nature cannot be answered generally and may be quite complex in individual cases. The transferability of copyright or parts of copyright, or the scope of permissible rights granted, for example, belongs to copyright law. Here, the law of the respective country of protection must be applied. A deviating choice of law is not possible (for the entirety, see Jaeger/Metzger, 449 ff.). + +=== Exclusion of liability and warranty + +Open source licences regularly exclude any warranty and liability to the extent legally permissible. In practice, there are rarely any liability or warranty issues; the risks involved are therefore low. + +It can be assumed that with correct licensing, the liability exclusion clauses present in all licences discussed here will take effect, so that only liability for gross negligence and intent, possibly personal injury, remains. + +Rules of general terms and conditions may be reserved, e.g. as in Germany; however, insofar as the federal authorities are the subject of liability as a licensor, Swiss law applies (see 8.1 above), which permits the aforementioned exclusions of liability and warranty in B2B transactions. + +Conversely, however, this also means that in the event of program errors, claiming against the authors of included OSS code is usually difficult. + +The usual procedure when using OSS is therefore regularly to protect against errors through the usual IT security measures and to ensure the correction of errors through maintenance contracts. There is no recourse to OSS contributors. + +=== Copyleft and licensing between Federal Administration bodies + +Copyleft applies when passing between different legal entities (for example, within a group or between agencies of the decentralised Federal Administration with their own legal personality). + +Copyleft does not apply when passing between agencies of the same legal entity (for example, within the central Federal Administration). + +=== Licensing of patents + +Software patents are only possible within narrow limits according to European legal opinion. The decisive factor is that the software makes a technical contribution, i.e. solves a concrete technical problem outside the computer on which it runs. Examples would be engine control in cars or the control of a robot. Software as such that only runs on a computer but has no such external effect is generally not patentable in Europe. Thus most software programs do not fall within the scope of patent law. + +In other parts of the world, particularly the USA, software patents are granted somewhat more liberally. However, even in the USA, an abstract idea or business model does not become a patentable invention simply by being implemented in computer software. + +With some licences, any patents of the licensor are not co-licensed. These are the GPL2, the BSD licences, and the MIT licence. + +For projects that could also be used outside Europe, or which exhibit the aforementioned form of external impact, it is advisable to clarify the patent law aspects on a case-by-case basis. + +=== Dual licensing + +The author can license software under different licences simultaneously. This is called dual licensing. + +An interesting form of dual licensing is where the copyright holder licenses the software as OSS with a strong copyleft (which prevents it from being integrated into proprietary software) and also offers interested licensees a _paid_ licence that allows them to integrate the software into their proprietary software. + +Because interested licensees can thus avoid releasing their proprietary software as OSS, they are willing to pay for the licence. See also the annex to link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. + +For the federal authorities themselves, dual licensing is likely to be uninteresting in most cases. As long as the copyrights lie with the federal authorities (which is regulated, for example, according to the Federal Administration's general terms and conditions), the federal authorities alone can decide on any dual licensing. + +If maintenance and (further) development are outsourced to third parties, this may be different. If the rights exceptionally lie with them, and if the federal authorities have only reserved the right to grant an OSS licence with copyleft, the third party might be tempted to perform dual licensing. If this is to be prevented, it should be contractually excluded. + +=== Subsequent change of licences + +First, it should be noted that OSS licences are generally unchangeable and irrevocable. Licensees who concluded the licence agreement _before_ any change can continue to use, modify, and pass on the code to third parties based on the old licence. + +In practice, changing licences often leads to a fork of a new version of the software under the old licence, which is further developed independently by the previous licensees. + +The introduction of a new licence for software is only possible if all copyright holders of the software agree. Changes have occurred in practice, for example, when switching from a permissive to a copyleft licence. + +=== Naming of contributors (employees and third parties) + +If a computer program is created in an employment relationship, the employer receives an exclusive licence for its use (Art. 17 CopA). Employees are thus essentially left with only the moral rights to the software (or, depending on the legal opinion, only a core part thereof). The same applies to third parties who develop software for the federal authorities, provided that the corresponding GTCfootnote:[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] of the Confederation apply, which transfer the resulting rights to the federal authorities. + +Nevertheless, the question arises as to whether contributors (employees, third parties) should have the right or obligation to identify themselves as authors of contributions in open source repositories. + +One argument for the federal authorities to use OSS is to offer attractive employment: OSS offers contributors the opportunity to publicly demonstrate their knowledge and thus build a reputation. Their abilities become verifiable, are attested by peers, and those who have gained influence in an OSS project can use this as leverage in job searching. + +Another argument could be the moral rights, the core of which cannot be taken away from the original author either by contract or by law. However, this core area is small for computer programs; demanding that the developer of a computer program should also have a right to be named would probably be going too far. + +In addition, an exchange between experts in the community presupposes that they can be approached individually by others. + +Depending on the project, it may therefore make sense to give contributors the opportunity to identify themselves as contributors in the community. + +From a data protection point of view, compulsion to do so should be avoided, although exchange in the community does not presuppose disclosure of names – pseudonyms are the rule rather than the exception. If contributors do not wish to disclose their names, they should therefore be given the opportunity to appear under a pseudonym. + +*It is recommended that the names of the developers be mentioned in the commits if the project does not object to this.* + +*In any case, the federal authorities should act as rights holders.* + +=== Copyright, licences for generative AI for code creation + +Here, we are referring only to code that has been created using generative AI. Further information on this topic can be found in link:em002-6.adoc[Em002-6 FAQ about OSS++*++ in Section 2.2]. Code created by an LLM is not itself protected by copyright. However, the training data used by the LLM may be protected by copyright. If the code corresponds 1:1, then the licence should also be adopted. If the code was created piecemeal and then modified by the developers, there is little risk that this will be considered derived software. It should be noted that certain LLMs require the code to be labelled accordingly; any contractual agreements in this regard must be observed. + +=== Contributor Licence Agreements (CLA) and Developer Certificate of Origin (DCO) + +When multiple authors work on the code of an open source project, they receive joint rights to the resulting code. + +The licensing of the code to third parties is done via the OSS licence, whereby a separate licence agreement is created between each user and each author (bundle of licences). This constellation can lead to a confusing legal situation, for example in international relations (see 8.1 above). When companies decide to put their software under an OSS licence and accept contributions from third parties, they sometimes have the need to retain some control over the code. + +For example, it may be interesting to keep open the possibility of putting the project under a new licence, or one might want to subject code licensed under copyleft to dual licensing and for this purpose needs more rights than one would get from one's contributors via a simple OSS licence (see 8.5 above). Contributor Licence Agreements (sometimes also Copyright Transfer Agreements) are intended to solve such problems. + +A *Contributor Licence Agreement (CLA)* is a *legally binding agreement* that defines the *conditions for project contributions*. + +Contributors are obliged to agree to this agreement before content can be contributed to the project. Essentially, the contributors grant the project and its users the right to *use, modify and redistribute* the contributions made. Furthermore, it is confirmed that the contributions *were written independently or legitimised by third parties*. + +The *Developer Certificate of Origin (DCO)* is a *verification system introduced* by the Linux Foundation in 2004, which is similar in purpose to the Contributor Licence Agreement (CLA) and represents a suitable alternative instrument. The contributors confirm for each project contribution that *(a) they are authorised to make the contribution, (b) the contribution is covered by a licence compatible with the project and (c) they agree to the distribution and use of the contribution as open source*. + +The main instrument of CLAs is either the assignment of copyrights from the contributors to the main developer or the supporting organisation (in the case of Copyright Transfer Agreements), or the granting of the most extensive, usually irrevocable licence possible by the contributors to the main developer (e.g. Apache has defined a CLA). Contributions to closed projects are also often subject to a CLA. + +CLAs are controversial in the OSS communityfootnote:[For example: https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/] because, among other reasons, they can open gaps in copyleft. Therefore, there are now also CLAs that restrict the main developer in terms of granting a new licence for the project's code. + +image::./assets/em002-3/media/image4.png[Transfer source code and rights in different constellations] + +Figure 4: Transfer source code and rights in different constellations + +There are no problems for *own developments* (creation): According to Art. 17 CopA, the federal authority is the holder of the usage rights to software created by its own employees. For *third-party developers*, the federal authorities should secure the rights (for example, by using the corresponding GTCs of the Confederation). This means that no CLA or DCO is necessary here. + +Where federal authorities are the main developers and accept contributions and collaborations, the use of a CLA should be avoided. Digital Certificates of Origin (explained with an example in link:em002-4.adoc[Em002-4 OSS Community Guidelines], Section 3.3) may be used instead. In principle, contributions to federal authority projects should build on the OSS licence so as not to raise the barrier to contribution any further. + +Should a need for a CLA nonetheless be identified in a specific case following appropriate review, the federal authority should use the Apache CLA.footnote:[https://www.apache.org/licenses/contributor-agreements.html] In that event, this decision and the CLA should be noted in the concluding remarks of both link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. + +Where federal authorities contribute to third-party software that requires a CLA, the legal service must examine on a case-by-case basis whether the federal authority can accept the existing CLA.footnote:[For any given recipient, the federal administration would only need to review the signing of a CLA once. In other organisations, this is therefore treated as a high-level matter, with signed CLAs kept on file in the contracts repository. CLAs must not undermine the federal authority's obligations under Art. 9 EMOTA.] The following points must be determined: + +* Has another federal authority already signed the CLA? +* Who reviews the CLA? +* Who signs it? (The signatory must be authorised to sign on behalf of the Confederation vis-à-vis third parties) +* Where is it filed? +* How is the CLA or DCO documented in the project? +* How is it ensured that the code that has been released remains published? (This remains the responsibility of the federal authority under Art. 9 EMOTA, see [KKB-MB].) + +Possible criteria for the review are: + +* Compatibility with Art. 9 EMOTA: does the code remain open? +* Does the federal authority see any risks for itself? +* Does the federal authority see a benefit for itself (e.g. the code does not have to be maintained or developed further alone) or for others (within Switzerland's federal system or across Europe, broader impact can be achieved without additional effort)? +* Are the rights assigned reasonable? +* Are no (unnecessary) obligations imposed on the federal authority? +* Is the CLA substantially equivalent to the Apache CLA? + +=== Problems with (L) GPL-3.0 and IoT 7.4.4 + +_[BITKOM2023]_ points out a problem with the use of (L)GPL-3.0 licences in connection with device-related software: such devices would have to allow the installation of own/new software versions. This may not be desirable for security reasons. + +=== Legal status of documentation + +According to Art. 5 CopA, "decisions, minutes and reports issued by authorities and public administrations" are not protected by copyright. + +This goes further than CC-0 because the rights holder cannot dedicate the work to the public domain by waiving all copyright and neighbouring rights worldwide. It is already in the public domain by law. The dispatch on Art. 5 CopA says: "The provision still allows copyright protection for a whole number of works that have arisen from official activity or in connection with it. + +Documents from internal administrative study committees and working groups, expert reports or journals of federal offices, for example, do not fall under the norm. There is no overriding interest in their free distribution because they do not influence the legal position of the citizen." + +It can thus be argued that for many of the relevant documents and the documentation published by federal authorities in connection with open source software, no copyright protection exists. The criterion is whether or not the document affects the legal status of the citizen and is thus exempt from copyright protection. If not, then a suitable licence (CC-0footnote:[https://www.creativecommons.ch/], CC-BY, CC-BY-SA or possibly LGPL) should be used for documentation. + +Nevertheless, especially with international use of the documentation, many users would be unclear about the situation. + +We therefore consider it expedient if, as with this document here, a corresponding release is also listed for safety's sake. + +== Further information on legal issues + +Further information on open source software, specific licence characteristics and in-depth legal aspects can be found in numerous publications, which are presented below (see also the references at the end of the document). + +* The text _'Open Source Software im EMOTA, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben'_ by Rika Koch and Simon Schlauri, in the proceedings of the IT Procurement Conference 2023 in Bern, offers additional guidance on the implementation of Art. 9 EMOTA. +* The German BITKOM's _Open Source Software 2.0 Guidelines_ addresses legal issues related to open source in detail _[BITKOM2023]_. However, it is based on the legal situation in Germany. +* Wolfgang Straub, in his book _Softwareschutz: Copyright Law, Patent Law, Open Source_, examines the legal details of copyleft in relation to Swiss copyright law and explores the compatibility of open source licences [St2011]. The section on open source software (as well as German translations of various open source licences considering Swiss legal terminology) are freely available at _www.it-recht.ch._ +* Till Jaeger and Axel Metzger provide in-depth answers to numerous legal questions related to open source software in their comprehensive book _Open Source Software - Rechtliche Rahmenbedingungen der Freien Software [JaAx2016]_. However, they base their analysis on the legal situation in Germany. +* Kropp Jonathan/Bauer Alexander, Open Source Compliance and Litigation, CB 2019 pp. 285 ff., 285. +* Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de 'logiciels libres' (open source), SZW 2022 p. 69 ff. + +In addition, various online portals provide detailed information on the characteristics and issues of specific open source licences. + +* On the GitHub platform https://choosealicense.com, the desired goals for an open source project can be selected and the appropriate open source licence is suggested. +* At https://opensource.guide/legal/ GitHub provides an online guide that addresses specific legal issues. +* At https://www.gnu.org/licenses/license-list.en.html you will find brief comments on various licences with information on compatibility, in particular the GPL. +* At https://opensource.org/faq the Open Source Initiative addresses numerous questions and answers on the legal aspects of open source licences. +* At https://copyleft.org/guide you will find a detailed guide explaining the details of copyleft. +* At https://tldrlegal.com the most important open source licences are summarised according to what the respective licence permits ('can'), what it prohibits ('cannot') and what it prescribes ('must'). +* At https://opensource.com/tags/licensing articles on current licence issues are published on an ongoing basis. +* At https://www.ifross.org/faq-haeufig-gestellte-fragen the private Institute for Legal Issues of Free and Open Source Software' in Berlin (ifrOSS) has published numerous answers to frequently asked legal questions. + +Today, compliance with open source licences is primarily implemented using software tools (for further information on open source compliance, see also Fröhlich-Bleuler _[Fr2012]_ and Kuhn, Williamson and Sandler _[KuWiSa2008]_). For example, various open source tools from the Linux Foundation are documented and published under the term 'fossology' at https://www.fossology.org. Also, commercial supplier such as Black Duckfootnote:[https://www.blackducksoftware.com] or FOSSAfootnote:[https://fossa.com] offer various proprietary solutions that can be used to check the compatibility of the open source licences used. + +== Annex + +=== Changes from previous version + +* Management Summary added. +* AGPL and MIT licences are now recommended as preferable. +* New in Section 8.8: Copyright for code generated with AI. +* Section 8.9 CLA and CDO greatly expanded. +* Various editorial improvements and clarifications. +* More examples given. + +=== References + +See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. + +=== Abbreviations + +See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. + +=== Examples of releases and their licence + +In future, this list will be replaced by a collection of metadata via publiccode.yml. + +=== D.1 Loom + +[cols="1,4"] +|=== +|URL |https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom +|Federal authority |Cyber Command +|Description |Loom is a powerful, easy-to-use document search engine. It automates the indexing of configured data sources, performs OCR, extracts content and metadata, enables tagging and offers powerful search and operating options. +|Year |2025 +|Licence |MIT +|Justification |- +|=== + +=== D.2 trustbroker.swiss + +[cols="1,4"] +|=== +|URL |https://github.com/trustbroker-swiss/trustbroker.swiss +|Federal authority |FCh, FOITT +|Description +a|Trust Broker Swiss provides federation services between relying parties (applications, service providers, other IAM systems or policy enforcement points) and identity providers (IdP, also called claims providers) using trusted attribute stores to enrich authenticated users. + +It enables Identity/Claims Providers and Relying Parties to exchange information via a third party that hides the IdP specifics and provides a unified or at least additionally verified identity. +|Year |2024 +|Licence |AGPL +|Justification +a|Code changes should always remain open and be returned. + +A very detailed examination of the licence issue was carried out for the Trust Broker. For very large projects, it can be carried out at this level of detail. All compatible licences that are compatible with the Software Bill of Materials were listed in a licence pool. +|=== + +=== D.3 Geocat.ch + +[cols="1,4"] +|=== +|URL |https://github.com/geonetwork/core-geonetwork +|Federal authority |Swisstopo +|Description |GeoNetwork is a catalogue application for managing spatially referenced resources. It offers powerful metadata editing and search functions as well as an interactive web map viewer. It is currently being used in numerous spatial data infrastructure initiatives around the world. +|Year |2012 +|Licence |GPL 2.0 +|Justification |- +|=== + +=== D.4 GWEN / ampycloud / c4dl-multi / dvas /… + +[cols="1,4"] +|=== +|URL |https://meteoswiss.github.io/ampycloud/ +|Federal authority |MeteoSwiss +|Description |Python package for determining the proportion of sky coverage and the base height of cloud layers using ceilometer data. +|Year |2023 +|Licence |Various licences, FSS +|Justification |- +|=== + +=== D.5 EMSG application (asset management in settlement areas) + +[cols="1,4"] +|=== +|URL |https://github.com/astra-emsg/ASTRA.EMSG +|Federal authority |MeteoSwiss +|Description |EMSG is a C# GIS web application developed by the Swiss government to manage the asset management of urban road systems. +|Year |2017 +|Licence |BSD +|Justification |- +|=== + +=== D.6 Covid certificate application + +[cols="1,4"] +|=== +|URL |https://github.com/admin-ch/CovidCertificate-Documents +|Federal authority |FOITT +|Description |Swiss application for COVID certificates +|Year |2020 +|Licence |MIT +|Justification |As permissive as possible so that anyone can use the code. +|=== + +=== D.7 GovCert website + +[cols="1,4"] +|=== +|URL |https://github.com/govcert-ch/website +|Federal authority |NCSC +|Description |Source code of the website for the Computer Emergency Response Team (GovCERT) of the Swiss government +|Year |2023 +|Licence |MIT +|Justification |- +|=== + +=== D.8 Various libraries on open data (e.g. linked data) + +[cols="1,4"] +|=== +|URL |https://github.com/SwissFederalArchives +|Federal authority |SFA +|Description |The Swiss Federal Archives repository on GitHub provides access to the source codes of our applications. It allows you to create your own forks and report errors or suggest extended functionalities at the 'Issues' interface. +|Year |2023 +|Licence |AGPL, Apache, MIT +|Justification |Opendata and open source software are heading in the same direction. AGPL allows maximum openness. +|=== + +=== D.9 Apache FOP customised for archivable PDF + +[cols="1,4"] +|=== +|URL |https://xmlgraphics.apache.org/fop/ +|Federal authority |IPI +|Description |The IPI wanted a version of Apache FOP that could generate archivable PDFs. To this end, an extension was commissioned by one of the core developers (Jeremias Märki). The adjustments were incorporated directly into the project. +|Year |2007 +|Licence |Apache +|Justification |Extensions were made to an existing open source project. +|=== + +=== D.10 Legally compliant electronic input with eKomm + +[cols="1,4"] +|=== +|URL |https://launchpad.net/ekomm +|Federal authority |IPI +|Description |The IPI wanted software for electronic input. +|Year |2009 +|Licence |Apache +|Justification |The IPI wanted to have the vendor (Glue) perform the release and authorise this as permissive (integration in its own applications). +|=== diff --git a/docs/en/em002-3.md b/docs/en/em002-3.md deleted file mode 100644 index ef23761..0000000 --- a/docs/en/em002-3.md +++ /dev/null @@ -1,1134 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- -# Management summary - -It is recommended that one of the following two licences be strategically defined in the Federal Administration when a new project is started: - -- **AGPL licence**: Copyleft effect desired. Changed code should in any case flow back into the general public and can then also be reintegrated by the Federal Administration. It is recommended to use the latest version of the licence. - This is the best way to fulfil the principle of \'public money -- public code\'. The rights of third parties, especially in the case of further developments, can weaken this to LGPL. - -- **MIT licence**: It should be possible for third parties to develop proprietary applications based on the Federal Administration\'s code. If a non-endorsement is specifically required, BSD-3-Clause is to be preferred. - -The following decision aid can be used to select the licence: - -![](./assets/em002-3/media/image1.png) - -Figure 1: Simplified licence selection guide - -To a certain extent, these two licences form the two extremes in the spectrum of OSS licences. It can be very useful to select a more suitable licence for a specific project. This guide is intended to -provide concrete assistance. - -If the analysis of the software libraries reveals that a different licence must be used, the developers will draw the project management\'s attention to this. The analysis is set out in [Em002-2 Instructions for Publishing Open Source Software.](./em002-2.md) - -When working on existing projects, all OSI-compatible licences are generally acceptable. - -# Introduction - -Article 9 of the Federal Act of 17 March 2023[^5] on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) stipulates that the federal authorities must publish and license software that they develop or commission as open source software. - -This document has the following objectives: - -- Introduction to the topics of software copyright and OSS licences. - -- A presentation of which OSS licences are unproblematic for use in the Federal Administration. - Licences not mentioned in this document and software under such licences may not be used without an additional review of the contractual provisions by the responsible legal service. - -- Assistance in selecting a licence for the development or procurement of a project under Art. 9 EMOTA. - -# Copyright and licences: Fundamentals - -Copyright law establishes both moral rights and economic rights (exploitation rights). The moral rights include, for example, the right to recognise authorship or the right to determine whether and when the work is published. Exploitation rights include, for example, the right to make or distribute copies of the work. - -The Federal Act of 9 October 1992[^6] on Copyright and Neighbouring Rights (CopA) provides for a number of other moral rights and exploitation rights (see Art. 8 ff. CopA). These rights accrue directly to the author at the same time as the work is created. - -Art. 2 CopA sets out the conditions under which copyright protection is granted. A protected work within the meaning of the law only exists if these requirements are met. - -The prerequisites are: - -- The work must have been created; simply finding the work is not sufficient. Research data, for example, i.e. the results of experiments, cannot be classified as works. - -- The creation must be \'intellectual\', i.e. originate from a human being. - -- The work must have been realised in a perceptible manner. The mere idea behind a work is not protected, only its external form, e.g. a printout of a text on paper or a performance of a piece of music. - -- Individuality: Finally, the work must have a certain minimum degree of individuality. A work that everyone would design in the same way is not protected. - -A wide variety of works can be protected, such as literary or scientific texts, musical works, photographic, cinematographic and other visual or audiovisual works. - -According to Art. 2 para. 3 CopA, computer programs are also works if the aforementioned requirements are met. - -The author alone is entitled to the copyrights upon their creation. Only the author can prohibit someone else from carrying out the corresponding actions. However, the author can exercise their rights not only themselves: - -- They may transfer their rights to third parties (e.g. by selling them). The new rights holder can then assert these rights in the same way as if they were the author. - -- Alternatively, the author may also license their rights to third parties. Simply put, a licence is a contract under which the rights holder allows a third party to use the work. The author retains the rights, but waives their enforcement vis-à-vis the licensee. - -If a computer program is created in an employment relationship, the employer receives an exclusive licence for its use (Art. 17 CopA). Employees are thus essentially left with only the moral rights to the software (or, depending on the legal opinion, only a core part thereof). -This is the same legal situation as under the Federal Personnel Act. - -# OSS licences - -## Fundamentals - -OSS is essentially characterised by the following features (based on a definition of the Open Source Initiative *\[OSI\]*[^7]): - -- Unlimited and free redistribution of the software is permitted; - -- The software is available in source code form; - -- Modifications to the software and their redistribution under the same licence are generally permitted; - -- No individuals or groups of people may be excluded from using the software, and no areas of application may be excluded (especially not commercial use); and - -- The distribution of the software together with other software (such as closed source software) must not be restricted. - -The most common motives for using OSS are initially the cost savings through the use of the already substantial pool of freely usable software. Companies that frequently use OSS are often able to save considerable portions of their IT budget through the use of OSS. - -Freely available code can also be easily adapted to one\'s own needs. Moreover, choosing OSS avoids vendor lock-in.[^8] - -## Open source licences - -Open source licences are, first and foremost, normal licence agreements for computer programs. - -In contrast to normal licence agreements, however, OSS licence agreements come into effect without further ado when only one of the free forms of use described in the licence is exercised (for example, by copying, redistributing or modifying software). - -## Copyleft versus permissive - -### General - -An open source licence according to the OSI may contain a \'copyleft\' provision. Changes to software licensed accordingly must be offered again under the same conditions as those that existed for the original software. Anyone who makes such changes must, when distributing the open source software in the form of machine-readable object code, also offer the source code to recipients. - -Expressed as defined by the Free Software Foundation, the copyleft effect protects developers\' freedom and thus ensures that once free software always remains free. - -With copyleft licences, a kind of exchange takes place between the community and the companies using it. The users, who are obliged to put their own developments back under the respective licence in return for the benefits from the existing software pool, thus contribute to the further development of the software pool. As a result, both sides stand to benefit. - -The copyleft provision has a certain \'contagion effect\': if copyleft-licensed software is integrated into previously proprietary software, the originally proprietary software must be disclosed under a -compatible open source licence. - -Accordingly, when using copyleft-licensed source code, care must be taken to integrate it only where the resulting software can and should be published under an open source licence. - -If an open source licence does not contain a copyleft provision (permissive open source licence), the licence for revised versions of the code can be freely chosen. In particular, it is also possible to put modifications back under a proprietary software licence and integrate the corresponding source code into proprietary software. - -Essentially, open source licences can be divided into **the following categories**: - -1. open source licences with **strong copyleft**; -2. open source licences with **weak copyleft**; and -3. **permissive** or **non-copyleft** open source licences. - -### Open source licences with strong copyleft - -When using an open source licence with strong copyleft, new versions derived from the original software, if passed on to third parties, must be placed under the conditions of the original licence and made available to these third parties as source code. - -The following two licences are considered the relevant open source licences with strong copyleft in the market: - -• GNU General Public Licence (GPL); a large proportion of OSS is licensed under this today - -• GNU Affero General Public Licence (AGPL) - -The main difference between GPL and AGPL relates to the type of use that triggers copyleft. With GPL software, the modified source code only needs to be offered if the new software version is offered to third parties as an executable program (e.g. as a mobile app). If the software is only made available via the internet (from one\'s own cloud from one\'s own servers), for example in the form of Software as a Service\' (SaaS) or an application programming interface (API), this does not trigger copyleft. - -If the software is under the AGPL, the modified source code must also be supplied when the functionality of the software is offered via a website or programming interface. The AGPL is thus even stricter than the GPL. - -With strong copyleft licences, copyleft affects not only the respective software module (library) but the entire software program into which a copyleft-licensed software module may be embedded. The aforementioned \'contagion effect\' thus takes hold. - -### Open source licences with weak copyleft - -Licences with weak copyleft also require that changes to their source code be released to third-party recipients under the original open source licence. - -In contrast to licences with strong copyleft, however, they do not have the effect of \'infecting\' other delimitable software components (other libraries or the main program itself) with their licence. This allows the integration of open source software with weak copyleft into proprietary software or into software with other OSS licences without having to be released under the original licence. - -These are the most commonly used open source licences with weak copyleft: - -• GNU Lesser General Public Licence (LGPL) - -• Mozilla Public Licence 2.0 (MPL) - -• Common Development and Distribution Licence (CDDL) - -• Eclipse Public Licence (EPL)[^9] - -• Microsoft Reciprocal Licence (Ms-RL) - -• European Union Public Licence (EUPL)[^10] - -### Permissive open source licences - -Licences without copyleft effect are characterised by the fact that they do not impose any requirements on the licensee regarding the licensing of their derived software, and therefore neither their new source code nor changes to the open source software need to be disclosed to third-party recipients. -This enables the development of proprietary software products through the integration of software under permissive open source licences. - -Examples of permissive licences are: - -- MIT Licence - -- Apache Licence 2.0 - -- Berkeley Software Distribution (BSD) Licence (BSD 2-Clause and BSD 3-Clause) - -- Microsoft Public Licence (Ms-PL) - -## Compatibility of open source licences - -Programs usually consist of a variety of software components and modules that can be connected to each other in different ways. In software development, existing open source components are often integrated into proprietary, internal applications and solutions. As soon as these become accessible from outside via a website, APIs, software distribution or by another means, attention must be paid to the compatibility of the respective open source licences, because then copyleft can take effect. - -If derivative works that are under a certain licence may only be distributed under the same licence conditions, this has the consequence that other open source licences with other or contradictory licence obligations for derivative works cannot be used. - -Some open source licences contain so-called opening clauses, which allow the use of code licensed under them in projects that are under other licences. For example, the LGPL, Version 2.1, also allows the use of the code under the GPL. The GPLv3 contains, among other things, a compatibility clause for the AGPL and the Apache License 2.0. The EUPL is designed very openly and contains a long list of compatible licences in the annex, especially those with weak copyleft, such as the LGPL. This has the consequence that the strong copyleft protection actually specified in the licence is indirectly weakened. - -The following diagram depicts the dependencies of the most important open source licences (Goldstein 2018). The representation is based on the visualisation by David A. Wheeler, who analysed the compatibilities of the various licences and their version numbers (Wheeler 2007) and has been further developed together with information from [^11]. - -The diagram should be read as follows: code according to a licence listed earlier in the chain can be incorporated into software that is published under a licence listed later in the chain. For example, code licensed under the modified BSD can be placed under an LGPL or GPL licence variant, but not vice versa. Public domain means that the work is not subject to any copyright restrictions. - -![](./assets/em002-3/media/image2.png) -Figure 2: Compatibility of open source licences (based on diagram by David A. Wheeler, 2007 and https://www.gnu.org/licenses/license-list.en.html) - -Important: As licence compatibilities are always relevant, the development teams/service providers should check the development stacks with libraries for possible compatibility problems in advance. This means that before the use of a library is waved through, it should be checked whether the library\'s licence is compatible with the relevant licences preferred by the Federal Administration, in addition to considering security and homogeneity in the development stack. - -# Licences for pure usage - -This section deals with the situation where software under an OSS licence is to be used, but this software should not be modified, or modifications are only to be used internally. - -The following licences are generally unproblematic when software is used by federal authorities. However, the corresponding conditions, notably copyleft where applicable, must be adhered to. - -Under certain circumstances, the licence of a pre-existing software module determines the possible licences for the overall product (see Section 4.4). - - -Some licences are incompatible in combination (see Figure 2). - -| Licence| Copyleft | Special features| -|:--- | :--- | :--- | -|**MIT** | No| Preferred licence of the Federal Administration if further distribution is sought and third parties are to be allowed to develop proprietary software from it again. | -| **Apache 2.0**| No |Apache is a very widely used licence known for the projects that are under the Apache Foundation. Use of licensors' trademarks excluded, except for describing the work.| -| **GPL v3**|Yes |This is THE classic copyleft licence.
Copyleft also applies when GPL-licensed parts are incorporated into an entire program. Prohibition of digital rights management. Special compatibility rules.| -| **LGPLv3** | Weak| Reduced copyleft licence developed specifically for software libraries.
In contrast to GPL, LGPL allows closed (i.e. proprietary) code to be combined with LGPL code under certain conditions.
Examples include standard libraries such as glibc. LGPL allows the program, as part of which the library is distributed, to be placed under the GPL.| -| **Affero GPLv3 (AGPL)**| Yes | SaaS use also triggers copyleft. Otherwise analogous to GPLv3.
This licence closes the loophole in the GPL, which meant that no release was required when used for SaaS offerings.
With this licence, the Federal Administration can guarantee that enhancements to the code also benefit the general public in the case of SaaS, and best supports the principle of **public money – public code'.**| -|**BSD-3** |No |General, liberal licence.
Names of authors may not be used to promote derivative works (advertising clause) | -|**European Union Public Licence (EUPL)** |Weak |Special licence used for the EU.
Particularly useful as a basis for European projects.

Licence considering European law.Release under certain compatible licences explicitly allowed. | - -Table 1: Licences unproblematic for the federal authorities (according to *\[Sc2024*\]) - -Other licences may be used. In these cases, it may be necessary to consult the legal department of the respective office. - -# Licence for own projects or creation and for contributions - -This section concerns the following cases: - -- Further development / contribution - - - where federal authorities further develop existing software; or - - - develop new software, but rely on existing OSS software libraries; and - - - make the corresponding software available to third parties. Third parties also include organisations of the decentralised Federal Administration, provided they have their own legal personality. If the further developments are only used internally and not made available to third parties, only [Licences for pure usage](em002-3.md#licences-for-pure-usage) applies. - -- Own projects / creation / publication - This section concerns cases in which the federal authorities develop new software. This is likely to be rare, as most developments rely on existing open source software libraries. - - For completely new developments, a licence type should be chosen that enables a broad and sustainable basis for further developments. For this, it is important that the licence in question should be widely accepted in the relevant developer community. - -The compatibility check is carried out according to [Em002-2 Instructions for Publishing OSS](./em002-2.md), Section 7.4. The compatibility of the licences is shown in Figure 2. - -The following dimensions should be considered: - -- Use case - -- Desired checking [Em002-2.1 OSS Preliminary Assessment Checklist](./Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) - -- Ease of building a community [Em002-4 OSS Community Guidelines](./em002-4.md) - -- Ease of application - -- Legal certainty - -- Distribution - -Licences according to Section [Licences for pure usage](em002-3.md#licences-for-pure-usage) are preferred. - -The following **copyleft licences** should be used as a priority by federal authorities, especially if sustainable open development is sought and the copyleft effect of inheritance should apply. This ensures that software paid for by the public and all derivatives thereof remain open. This best fulfils the principle of \'**public money -- public code**\' and is **the preferred recommendation for the Federal Administration.** - -Recommended licences in descending order: - -- **AGPL v3** - -- GPL v3 - -- LGPL 3.0 - -- European Union Public Licence (EUPL) - -The following licences should be used by federal authorities when **no copyleft is desired** or required (in descending order): - -- **MIT** - -- Apache Licence 2.0 - -- BSD v3 - -When collaborating on existing projects, the following licences can also be used without problems: - -- Mozilla Public Licence - -- Microsoft Public Licence - -If another licence is to be used, it is recommended to briefly justify this in [Em002-2.3 OSS Release and Publication Checklist](./Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication%20.odt). - -**According to Art. 9 para. 4 EMOTA, internationally established licences should be used in all cases.** - -Additional tools for checking licence compatibilities include: - -- ORT Toolkit (https://oss-review-toolkit.org/) - -- Black Duck (www.blackducksoftware.com), - -- FOSSA ([www.fossa.com](http://www.fossa.com)), - -- the Open Source Licence Comparison Grid () - -- FOSSology (). - -- OpenCode process: [https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses](https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen) - -# Use cases and suitable licences - -The following table and diagram show how appropriate licences can be selected for open source software based on different use cases. - -| **Use case** | **Licence(s)**| **Justification** | -| :--- | :---|:--- | -| Use and contribute to existing project| **Licence as specified by the project** |Necessary for legal reasons.| -| Licence is forced by the use of existing parts (licences with copyleft)| **Use licence compatible with the parts.** |Necessary for legal reasons.

NB: A number of libraries are available under several licences.
Only one of the licences has to correspond One of the purposes of multiple licensing is to ensure that libraries can be used both with and without copyleft.| -| Existing ecosystem with preferred licence (e.g. it is a plugin for software released under MIT licence. Then using an MIT licence would be most purposeful, as all other users expect this and the software integrates into the ecosystem)|**Use licence if it is on the list, otherwise use the same licence as much as possible** |Acceptance in the community is central. | -|The goal is the widest possible distribution, e.g. for a reference implementation[^12] (e.g. for software also to be used in commercial solutions).| **MIT**
BSD v3
Apache Licence 2.0
LGPL v3| In this case, no copyleft should be used.| -|Modifications to the code should flow back to the federal authorities|**AGPL v.3**
GNU GPL v.3
EUPL |AGPL also enforces release by third parties when used in the cloud, GPL and EUPL do not. | -| SaaS solutions should not be exempt from the backflow of code changes| **AGPL v.3** | AGPL also enforces release by third parties when used in the cloud.| -| Easy collaboration with the community is important.|**AGPL v.3**
GNU GPL v3
Apache Licence 2.0 |GPL preferred to keep the software free.

Apache contains rules for community governance, additional rules for contributions (you may not specify a licence other than Apache; the contribution as such is not regulated in more detail, so if a CLA exists, that should take precedence), a patent licence, rules for patent licensing. Especially also that anyone who asserts patents against another contributor loses their patent licence under the Apache licence.
The rules that the Apache Foundation sets for contributions are decisive. Apache therefore makes sense if the project governance is to be built primarily according to Apache. | -| Small, universally usable component (library) or small piece of software where sustainability or maintenance by a community is not important | **MIT**
Apache Licence 2.0
BSD v3
LGPL v3 |LGPL stipulates a copyleft only for the component itself, but not for the entire project into which the component is inserted.

The other licences are permissive.| -| It must be simply and permissive; control is not important| **MIT**
Apache Licence 2.0
BSD v3|Maximally permissive | -| It is important for the federal authorities what happens to the code and they want to receive as many improvements as possible.|**AGPL v.3**
GNU GPLv3 |Copyleft | -| It should be prevented that the software becomes proprietary and is positioned as a competitive product on the market|**AGPL v.3**
GNU GPLv3 |Copyleft | -|It should be prevented that the federal authorities become dependent on individual suppliers ('vendor lock-in') |**AGPL v.3**
GNU GPLv3 |The copyleft prevents a supplier from gaining a unique position over time by using the Confederation's software in a proprietary product, which could again lead to a dependency for the Confederation on this supplier.| - -Table 2: Licence to be used depending on the use case for the release of new software in accordance with Art. 9 EMOTA **(bold = recommended where no grounds exist to the contrary**) - -![](./assets/em002-3/media/image3.png) - -Figure 3: Extended decision tree for licence selection in the Federal Administration (if not AGPL or MIT) - -The bill of materials in Figure 3 is the software bill of materials (SBOM) of all pre-existing software libraries and sub-programs that have been incorporated into the overall solution. Each library has its own licence. Depending on how this is compatible with others (see Section 4.4), the possible selection of licences for the publication is limited. - -One last point can also influence the decision: **changing from a more restrictive licence to a less restrictive one is easier afterwards**. In the opposite case, a fork[^13] is almost unavoidable. - -# Special legal topics - - -## International aspects - -The essential legal issues of OSS in practice are mainly of a licence contract nature. - -Regarding licence law issues, the law chosen by the parties applies first (for example, the Mozilla Public License MPL contains a choice of law for the defendant\'s law in Section 8). - -If there is no choice of law, which is the case with all other licences presented here, the law of the licensor\'s state generally applies. So when federal authorities license software from foreign licensors, the law of the respective country applies. If multiple contributors are involved, this can lead to complex situations. Conversely, Swiss law applies in the event of any disputes between foreign licence holders and the federal authorities as licensor. - -The question of which aspects are contractual in nature and which are copyright in nature cannot be answered generally and may be quite complex in individual cases. -The transferability of copyright or parts of copyright, or the scope of permissible rights granted, for example, belongs to copyright law. Here, the law of the respective country of protection must be applied. A deviating choice of law is not possible (for the entirety, see Jaeger/Metzger, 449 ff.). - -## Exclusion of liability and warranty - -Open source licences regularly exclude any warranty and liability to the extent legally permissible. In practice, there are rarely any liability or warranty issues; the risks involved are therefore low. - -It can be assumed that with correct licensing, the liability exclusion clauses present in all licences discussed here will take effect, so that only liability for gross negligence and intent, possibly personal injury, remains. - -Rules of general terms and conditions may be reserved, e.g. as in Germany; however, insofar as the federal authorities are the subject of liability as a licensor, Swiss law applies (see 8.1 above), which permits the aforementioned exclusions of liability and warranty in B2B transactions. - -Conversely, however, this also means that in the event of program errors, claiming against the authors of included OSS code is usually difficult. - -The usual procedure when using OSS is therefore regularly to protect against errors through the usual IT security measures and to ensure the correction of errors through maintenance contracts. There is no recourse to OSS contributors. - -## Copyleft and licensing between Federal Administration bodies - -Copyleft applies when passing between different legal entities (for example, within a group or between agencies of the decentralised Federal Administration with their own legal personality). - -Copyleft does not apply when passing between agencies of the same legal entity (for example, within the central Federal Administration). - -## Licensing of patents - -Software patents are only possible within narrow limits according to European legal opinion. The decisive factor is that the software makes a technical contribution, i.e. solves a concrete technical problem outside the computer on which it runs. Examples would be engine control in cars or the control of a robot. Software as such that only runs on a computer but has no such external effect is generally not patentable in Europe. Thus most software programs do not fall within the scope of patent law. - -In other parts of the world, particularly the USA, software patents are granted somewhat more liberally. However, even in the USA, an abstract idea or business model does not become a patentable invention simply by being implemented in computer software. - -With some licences, any patents of the licensor are not co-licensed. These are the GPL2, the BSD licences, and the MIT licence. - -For projects that could also be used outside Europe, or which exhibit the aforementioned form of external impact, it is advisable to clarify the patent law aspects on a case-by-case basis. - -## Dual licensing - -The author can license software under different licences simultaneously. This is called dual licensing. - -An interesting form of dual licensing is where the copyright holder licenses the software as OSS with a strong copyleft (which prevents it from being integrated into proprietary software) and also offers interested licensees a *paid* licence that allows them to integrate the software into their proprietary software. - -Because interested licensees can thus avoid releasing their proprietary software as OSS, they are willing to pay for the licence. See also the annex to [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration.](./em002-1.md) - -For the federal authorities themselves, dual licensing is likely to be uninteresting in most cases. As long as the copyrights lie with the federal authorities (which is regulated, for example, according to the Federal Administration\'s general terms and conditions), the federal authorities alone can decide on any dual licensing. - -If maintenance and (further) development are outsourced to third parties, this may be different. If the rights exceptionally lie with them, and if the federal authorities have only reserved the right to -grant an OSS licence with copyleft, the third party might be tempted to perform dual licensing. If this is to be prevented, it should be contractually excluded. - -## Subsequent change of licences - -First, it should be noted that OSS licences are generally unchangeable and irrevocable. Licensees who concluded the licence agreement *before* any change can continue to use, modify, and pass on the code to third parties based on the old licence. - -In practice, changing licences often leads to a fork of a new version of the software under the old licence, which is further developed independently by the previous licensees. - -The introduction of a new licence for software is only possible if all copyright holders of the software agree. Changes have occurred in practice, for example, when switching from a permissive to a copyleft licence. - -## Naming of contributors (employees and third parties) - -If a computer program is created in an employment relationship, the employer receives an exclusive licence for its use (Art. 17 CopA). Employees are thus essentially left with only the moral rights to the software (or, depending on the legal opinion, only a core part thereof). The same applies to third parties who develop software for the federal authorities, provided that the corresponding GTC[^14] of the Confederation apply, which transfer the resulting rights to the federal authorities. - -Nevertheless, the question arises as to whether contributors (employees, third parties) should have the right or obligation to identify themselves as authors of contributions in open source repositories. - -One argument for the federal authorities to use OSS is to offer attractive employment: OSS offers contributors the opportunity to publicly demonstrate their knowledge and thus build a reputation. Their abilities become verifiable, are attested by peers, and those who have gained influence in an OSS project can use this as leverage in job searching. - -Another argument could be the moral rights, the core of which cannot be taken away from the original author either by contract or by law. However, this core area is small for computer programs; demanding that the developer of a computer program should also have a right to be named would probably be going too far. - -In addition, an exchange between experts in the community presupposes that they can be approached individually by others. - -Depending on the project, it may therefore make sense to give contributors the opportunity to identify themselves as contributors in the community. - -From a data protection point of view, compulsion to do so should be avoided, although exchange in the community does not presuppose disclosure of names -- pseudonyms are the rule rather than the exception. If contributors do not wish to disclose their names, they should therefore be given the opportunity to appear under a pseudonym. - -**It is recommended that the names of the developers be mentioned in the commits if the project does not object to this.** - -**In any case, the federal authorities should act as rights holders.** - -## Copyright, licences for generative AI for code creation - -Here, we are referring only to code that has been created using generative AI. Further information on this topic can be found in [Em002-6 FAQ about OSS* in Section 2.2](./em002-6.md). Code created by an LLM is not itself protected by copyright. However, the training data used by the LLM may be protected by copyright. If the code corresponds 1:1, then the licence should also be adopted. If the code was created piecemeal and then modified by the developers, there is little risk that this will be considered derived software. It should be noted that certain LLMs require the code to be labelled accordingly; any contractual agreements in this regard must be observed. - -## Contributor Licence Agreements (CLA) and Developer Certificate of Origin (DCO) - -When multiple authors work on the code of an open source project, they receive joint rights to the resulting code. - -The licensing of the code to third parties is done via the OSS licence, whereby a separate licence agreement is created between each user and each author (bundle of licences). This constellation can lead to a confusing legal situation, for example in international relations (see 8.1 above). When companies decide to put their software under an OSS licence and accept contributions from third parties, they sometimes have the need to retain some control over the code. - -For example, it may be interesting to keep open the possibility of putting the project under a new licence , or one might want to subject code licensed under copyleft to dual licensing and for this purpose needs more rights than one would get from one\'s contributors via a simple OSS licence (see 8.5 above). Contributor Licence Agreements (sometimes also Copyright Transfer Agreements) are intended to solve such problems. - -A **Contributor Licence Agreement (CLA)** is a **legally binding agreement** that defines the **conditions for project contributions**. - -Contributors are obliged to agree to this agreement before content can be contributed to the project. Essentially, the contributors grant the project and its users the right to **use, modify and redistribute** the contributions made. Furthermore, it is confirmed that the contributions **were written independently or legitimised by third parties**. - -The **Developer Certificate of Origin (DCO)** is a **verification system introduced** by the Linux Foundation in 2004, which is similar in purpose to the Contributor Licence Agreement (CLA) and represents a suitable alternative instrument. The contributors confirm for each project contribution that **(a) they are authorised to make the contribution, (b) the contribution is covered by a licence compatible with the project and (c) they agree to the distribution and use of the contribution as open source**. - -The main instrument of CLAs is either the assignment of copyrights from the contributors to the main developer or the supporting organisation (in the case of Copyright Transfer Agreements), or the granting of the most extensive, usually irrevocable licence possible by the contributors to the main developer (e.g. Apache has defined a CLA). Contributions to closed projects are also often subject to a CLA. - -CLAs are controversial in the OSS community[^15] because, among other reasons, they can open gaps in copyleft. Therefore, there are now also CLAs that restrict the main developer in terms of granting a new licence for the project\'s code. - -![](./assets/em002-3/media/image4.png) -Figure 4: Transfer source code and rights in different constellations - -There are no problems for **own developments** (creation): According to Art. 17 CopA, the federal authority is the holder of the usage rights to software created by its own employees. For **third-party developers**, the federal authorities should secure the rights (for example, by using the corresponding GTCs of the Confederation). This means that no CLA or DCO is necessary here. - -Where federal authorities are the main developers and accept contributions and collaborations, the use of a CLA should be avoided.Digital Certificates of Origin (explained with an example in [Em002-4 OSS Community Guidelines](./em002-4.md), Section 3.3) may be used instead. In principle, contributions to federal authority projects should build on the OSS licence so as not to raise the barrier to contribution any further. - -Should a need for a CLA nonetheless be identified in a specific case following appropriate review, the federal authority should use the Apache CLA.[^16] In that event, this decision and the CLA should be noted in the concluding remarks of both [Em002-2.1 Preliminary Assessment Checklist](./Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) and [Em002-4.1 OSS Community Checklist](./Em002-4.1%20Checklist%20OSS%20Community.odt). - -Where federal authorities contribute to third-party software that requires a CLA, the legal service must examine on a case-by-case basis whether the federal authority can accept the existing CLA.[^17] The following points must be determined: - -- Has another federal authority already signed the CLA? - -- Who reviews the CLA? - -- Who signs it? (The signatory must be authorised to sign on behalf of the Confederation vis-à-vis third parties) - -- Where is it filed? - -- How is the CLA or DCO documented in the project? - -- How is it ensured that the code that has been released remains published? (This remains the responsibility of the federal authority under Art. 9 EMOTA, see \[KKB-MB\].) - -Possible criteria for the review are: - -- Compatibility with Art. 9 EMOTA: does the code remain open? - -- Does the federal authority see any risks for itself? - -- Does the federal authority see a benefit for itself (e.g. the code does not have to be maintained or developed further alone) or for others (within Switzerland\'s federal system or across Europe, broader impact can be achieved without additional effort)? - -- Are the rights assigned reasonable? - -- Are no (unnecessary) obligations imposed on the federal authority? - -- Is the CLA substantially equivalent to the Apache CLA? - -## Problems with (L) GPL-3.0 and IoT 7.4.4 - -*\[BITKOM2023\]* points out a problem with the use of (L)GPL-3.0 licences in connection with device-related software: such devices would have to allow the installation of own/new software versions. This may not be desirable for security reasons. - -## Legal status of documentation - -According to Art. 5 CopA, \"decisions, minutes and reports issued by authorities and public administrations\" are not protected by copyright. - -This goes further than CC-0 because the rights holder cannot dedicate the work to the public domain by waiving all copyright and neighbouring rights worldwide. It is already in the public domain by law. The dispatch on Art. 5 CopA says: \"The provision still allows copyright protection for a whole number of works that have arisen from official activity or in connection with it. - -Documents from internal administrative study committees and working groups, expert reports or journals of federal offices, for example, do not fall under the norm. There is no overriding interest in their free distribution because they do not influence the legal position of the citizen.\" - -It can thus be argued that for many of the relevant documents and the documentation published by federal authorities in connection with open source software, no copyright protection exists. The criterion is whether or not the document affects the legal status of the citizen and is thus exempt from copyright protection. If not, then a suitable licence (CC-0[^18], CC-BY, CC-BY-SA or possibly LGPL) should be used for documentation. - -Nevertheless, especially with international use of the documentation, many users would be unclear about the situation. - -We therefore consider it expedient if, as with this document here, a corresponding release is also listed for safety\'s sake. - -# Further information on legal issues - -Further information on open source software, specific licence characteristics and in-depth legal aspects can be found in numerous publications, which are presented below (see also the references at the end of the document). - -- The text *\'Open Source Software im EMOTA, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben\'* by Rika Koch and Simon Schlauri, in the proceedings of the IT Procurement Conference 2023 in Bern, offers additional guidance on the implementation of Art. 9 EMOTA. - -- The German BITKOM\'s *Open Source Software 2.0 Guidelines* addresses legal issues related to open source in detail *\[BITKOM2023\].* However, it is based on the legal situation in Germany. - -- Wolfgang Straub, in his book *Softwareschutz: Copyright Law, Patent Law, Open Source*, examines the legal details of copyleft in relation to Swiss copyright law and explores the compatibility of open source licences \[St2011\]. The section on open source software (as well as German translations of various open source licences considering Swiss legal terminology) are freely available at *www.it-recht.ch.* - -- Till Jaeger and Axel Metzger provide in-depth answers to numerous legal questions related to open source software in their comprehensive book *Open Source Software - Rechtliche Rahmenbedingungen der Freien Software \[JaAx2016\]*. However, they base their analysis on the legal situation in Germany. - -- Kropp Jonathan/Bauer Alexander, Open Source Compliance and Litigation, CB 2019 pp. 285 ff., 285. - -- Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de \'logiciels libres\' (open source), SZW 2022 p. 69 ff. - -In addition, various online portals provide detailed information on the characteristics and issues of specific open source licences. - -- On the GitHub platform , the desired goals for an open source project can be selected and the appropriate open source licence is suggested. - -- At GitHub provides an online guide that addresses specific legal issues. - -- At you will find brief comments on various licences with information on compatibility, in particular the GPL. - -- At the Open Source Initiative addresses numerous questions and answers on the legal aspects of open source licences. - -- At you will find a detailed guide explaining the details of copyleft. - -- At the most important open source licences are summarised according to what the respective licence permits (\'can\'), what it prohibits (\'cannot\') and what it prescribes (\'must\'). - -- At articles on current licence issues are published on an ongoing basis. - -- At the private Institute for Legal Issues of Free and Open Source Software\' in Berlin (ifrOSS) has published numerous answers to frequently asked legal questions. - -Today, compliance with open source licences is primarily implemented using software tools (for further information on open source compliance, see also Fröhlich-Bleuler *\[Fr2012\]* and Kuhn, Williamson and Sandler *\[KuWiSa2008\]* ). For example, various open source tools from the Linux Foundation are documented and published under the term \'fossology\' at . Also, commercial supplier such as Black Duck[^19] or FOSSA[^20] offer various proprietary solutions that can be used to check the compatibility of the open source licences used. - -# Annex - -## Changes from previous version - -- Management Summary added. - -- AGPL and MIT licences are now recommended as preferable. - -- New in Section 8.8: Copyright for code generated with AI. - -- Section 8.9 CLA and CDO greatly expanded. - -- Various editorial improvements and clarifications. - -- More examples given. - -## References - -See [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](./em002.md). - -## Abbreviations - -See [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](em002.md) and [Em002-6 FAQ about OSS.](./em002-6.md) - -## Examples of releases and their licence - -In future, this list will be replaced by a collection of metadata via publiccode.yml. - -## D.1 Loom - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom -
- Federal authority - - Cyber Command -
- Description - - Loom is a powerful, easy-to-use document search engine. It automates the indexing of configured data sources, performs OCR, extracts content and metadata, enables tagging and offers powerful search and operating options. -
- Year - - 2025 -
- Licence - - MIT -
- Justification - - - -
- - -## D.2 trustbroker.swiss - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/trustbroker-swiss/trustbroker.swiss -
- Federal authority - - FCh, FOITT -
- Description - - Trust Broker Swiss provides federation services between relying parties (applications, service providers, other IAM systems or policy enforcement points) and identity providers (IdP, also called claims providers) using trusted attribute stores to enrich authenticated users.
-It enables Identity/Claims Providers and Relying Parties to exchange information via a third party that hides the IdP specifics and provides a unified or at least additionally verified identity. -
- Year - - 2024 -
- Licence - - AGPL -
- Justification - - Code changes should always remain open and be returned.

-A very detailed examination of the licence issue was carried out for the Trust Broker. For very large projects, it can be carried out at this level of detail. All compatible licences that are compatible with the Software Bill of Materials were listed in a licence pool. -
- - -## D.3 Geocat.ch - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/geonetwork/core-geonetwork -
- Federal authority - - Swisstopo -
- Description - - GeoNetwork is a catalogue application for managing spatially referenced resources. It offers powerful metadata editing and search functions as well as an interactive web map viewer. It is currently being used in numerous spatial data infrastructure initiatives around the world. -
- Year - - 2012 -
- Licence - - GPL 2.0 -
- Justification - - - -
- -## D.4 GWEN / ampycloud / c4dl-multi / dvas /… - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://meteoswiss.github.io/ampycloud/ -
- Federal authority - - MeteoSwiss -
- Description - - Python package for determining the proportion of sky coverage and the base height of cloud layers using ceilometer data. -
- Year - - 2023 -
- Licence - - Various licences, FSS -
- Justification - - - -
- -## D.5 EMSG application (asset management in settlement areas) - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/astra-emsg/ASTRA.EMSG -
- Federal authority - - MeteoSwiss -
- Description - - EMSG is a C# GIS web application developed by the Swiss government to manage the asset management of urban road systems. -
- Year - - 2017 -
- Licence - - BSD -
- Justification - - - -
- -## D.6 Covid certificate application - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/admin-ch/CovidCertificate-Documents -
- Federal authority - - FOITT -
- Description - - Swiss application for COVID certificates -
- Year - - 2020 -
- Licence - - MIT -
- Justification - - As permissive as possible so that anyone can use the code. -
- -## D.7 GovCert website - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/govcert-ch/website -
- Federal authority - - NCSC -
- Description - - Source code of the website for the Computer Emergency Response Team (GovCERT) of the Swiss government -
- Year - - 2023 -
- Licence - - MIT -
- Justification - - - -
- -## D.8 Various libraries on open data (e.g. linked data) - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://github.com/SwissFederalArchives -
- Federal authority - - SFA -
- Description - - The Swiss Federal Archives repository on GitHub provides access to the source codes of our applications. It allows you to create your own forks and report errors or suggest extended functionalities at the 'Issues' interface. -
- Year - - 2023 -
- Licence - - AGPL, Apache, MIT -
- Justification - - Opendata and open source software are heading in the same direction. AGPL allows maximum openness. -
- -## D.9 Apache FOP customised for archivable PDF - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://xmlgraphics.apache.org/fop/ -
- Federal authority - - IPI -
- Description - - The IPI wanted a version of Apache FOP that could generate archivable PDFs. To this end, an extension was commissioned by one of the core developers (Jeremias Märki). The adjustments were incorporated directly into the project. -
- Year - - 2007 -
- Licence - - Apache -
- Justification - - Extensions were made to an existing open source project. -
- -## D.10 Legally compliant electronic input with eKomm - - - - - - - - - - - - - - - - - - - - - - - - - - -
- URL - - https://launchpad.net/ekomm -
- Federal authority - - IPI -
- Description - - The IPI wanted software for electronic input. -
- Year - - 2009 -
- Licence - - Apache -
- Justification - - The IPI wanted to have the vendor (Glue) perform the release and authorise this as permissive (integration in its own applications). -
- -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: SR 172.019 - -[^6]: SR 231.1 - -[^7]: - -[^8]: - -[^9]: In addition to the Eclipse Publice Licence (EPL-1.0), there is - also the Eclipse Distribution Licence (EDL-1.0).\ - While EDL corresponds to the BSD 3 clause, EPL is a weak copyleft - licence. - -[^10]: The EUPL itself has a strong copyleft, but due to the opening - clause, a transfer to licences with a weak copyleft is possible, so - that the protection is limited. - -[^11]: Another, extended representation has been used by GEANT in their - confluence: [Software Licence Selection and Management in GÉANT - - GEANT Software Development Support - GÉANT federated - confluence](https://wiki.geant.org/pages/viewpage.action?pageId=1032978710). - You will find a few additional licences there. - -[^12]: For example, to make a law easier to implement, a reference - implementation can be commissioned by the federal authorities. See - e.g. - -[^13]: For definition see [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration](./em002-1.md). - -[^14]: - -[^15]: For example: - - -[^16]: - -[^17]: For any given recipient, the federal administration would only - need to review the signing of a CLA once. In other organisations, - this is therefore treated as a high-level matter, with signed CLAs - kept on file in the contracts repository. CLAs must not undermine - the federal authority\'s obligations under Art. 9 EMOTA. - -[^18]: - -[^19]: - -[^20]: diff --git a/docs/en/em002-4-1-checklist-oss-community.adoc b/docs/en/em002-4-1-checklist-oss-community.adoc new file mode 100644 index 0000000..7c59f6d --- /dev/null +++ b/docs/en/em002-4-1-checklist-oss-community.adoc @@ -0,0 +1,211 @@ += Em002-4.1 OSS Community Checklist +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +This checklist goes together with _Em002-2 Instructions for Publishing Open Source Software_ and _Em002-4 OSS Community Guidelines_. + +It must be filled in at the start of a project or at the start of the clarifications for release and subsequently completed. + +For OSS support models, please refer to Section 8 of _Em002-1 Practical Guidelines for Open Source Software in the Federal Administration_. + +== Subject matter + +=== Name and brief description of the software + +Enter the name of the software. + +[cols="1"] +|=== +a| + +|=== + +=== Contact person and authorisation + +Name the contact person of the specialist department and the persons responsible who have authorised publication of the software. + +[cols="1"] +|=== +a| + +|=== + +== Checklist + +[cols="1,6"] +|=== +| +a| +Type of community + +The community may already exist, which greatly simplifies the task. + +☐ Exists (third party may have the lead) + +☐ The Confederation has the lead + +☐ Equal partners (Confederation and partners/suppliers) + +☐ Other + +| +a| +Library or entire software? + +There is usually no community concept for libraries. An add-on can only be used together with a commercial product. + +☐ Entire software + +☐ Library + +☐ Add-on + +☐ Other + +| +a| +What type of community is planned? + +The choice of community type should be justified in two to three sentences. + +☐ None, only publication (as-is) (minimum release) + +Note: email must be available, publicode.yaml must be filled in + +☐ Releases/issue tracker (minimum support, allow third-party support if necessary) + +☐ Community + +| +a| +Are there potential or actual co-users of the software? + +Are there potential customers for the software? Possible and known users can be listed in the text box (see _Em002-2 Instructions for Publishing Open Source Software,_ Section 3.1.1). + +☐ None conceivable + +☐ Potential users (are conceivable) + +☐ Known users (have already contacted us) + +|☐ +a| +Stakeholders (already defined/known members of the community) + +List of relevant jobs/companies. + +This gives an idea of how relevant the software is for third parties. + +| +a| +Who takes charge of product management? + +Product management is primarily responsible for further development of the product. Especially if this role is assumed by third parties, the companies/organisations should be named if possible. + +☐ Federal office + +☐ Service provider + +☐ Supplier(s) / third parties + +☐ Joint organisation + +☐ Open + +| +a| +Integration of suppliers + +How are the suppliers involved? + +☐ Contractor + +☐ Partner + +☐ Responsible body + +☐ Other + +| +| + +| +a| +Type of organisation + +What organisational form does the community take? This should be explained in detail, especially if 'Other' is selected. On account of the effort this entails, a new association should only be set up if there is a very good reason for doing so. + +☐ Public sector only + +☐ Simple partnership + +☐ New or existing association + +☐ Other (e.g. a foundation, existing or not) + +| +a| +Cost distribution + +This should be set out in the community concept. Section 5.5 of _Em002-4 OSS Community Guidelines_ provides information on this. + +What means and resources are required? The cost distribution considerations should be briefly stated. + +☐ The Confederation pays + +☐ Each party covers its own costs + +☐ Originator pays principle + +☐ The Confederation does not assume any costs from the community + +☐ Cost sharing (e.g. by way of an association) + +☐ Release, partially assumed by third parties (e.g. because software was created before 1 January 2024 and they absolutely want to use the software) + +|☐ +a| +If additional services are offered in accordance with Art. 9 paras 5 and 6 EMOTA, is this set out in the community concept? + +The community concept contains the relevant information. + +|☐ +a| +Has the community concept been created? + +The community concept has been created or an existing one is being adopted? + +(please insert link) + +a| +☐ + +☐ + +☐ +a| +Are the necessary contracts in place? + +Contributor Licence Agreement (CLA)footnote:[See also _Em002-3 OSS Licensing Guidelines_. Alternatively, Developer Certificates of Origin (DCO) can also be used.] created or adopted + +Association founded, if necessary. + +| +| +|=== + +== Concluding remarks + +Comments and references to other relevant documents + +[cols="1"] +|=== +a| + +|=== + +*Filing of form* + +Please file this form with the project documentation and submit it to the appropriate office in your organisational unit. + +*Licence of the checklist template: CC0 1.0 Universal* + +This document is published under the CC0 licence. It may be freely used, modified and distributed, including for commercial purposes and in any format. diff --git a/docs/en/em002-4.adoc b/docs/en/em002-4.adoc new file mode 100644 index 0000000..66cb3ef --- /dev/null +++ b/docs/en/em002-4.adoc @@ -0,0 +1,923 @@ += Em002-4 OSS Community Guidelines +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +== Main points at a glance + +The most important points of the document are listed below. + +* The establishment or maintenance of an OSS community is *not required* under Art. 9 EMOTA. +* A community is relevant if a user group makes sense and *synergies* with other users of the software are to be created. +* A community is not limited to the software itself, but can also include the processes in the environment and the standardisation of data. +* An *initial effort* must always be made to build a community. This usually continues. In many cases, it makes sense for the lead office to also bear the coordination costs. +* Communities should fulfil a *purpose*. There need to be interested parties and participants. +* A community can emerge and then be formalised. +* The goal of the community is to increase the *benefit for everyone*. General principle: 'You get back at least as much as you put in'. +* The community should be *structured as simply as possible*. +* In a first step, the community should be briefly reviewed using the checklist link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]. Only if it makes sense should it be further developed. +* Formalisation takes place via a *community concept*. As much as possible should be taken from existing sources. General principle: 'Don't reinvent the wheel'. +* If collaboration is the aim, this must be taken into account at the very beginning of the project, as potential partners should already be picked up during the requirements analysis. This also needs to be well planned from the outset in terms of legal and procurement law. +* The options for joining an existing collaboration in regard to legal and procurement law must be examined. +* No community needs to be set up for contributions. However, if required by the project, the corresponding *Contributor Licence Agreement (CLA)* must be signed or the developers must be uthorised by the project to submit the software under a Developer Certificate of Origin (DCO). + +== Introduction + +These guidelines are intended for ICT professionals who are responsible for an application and want to offer it as open source or contribute to such an application. + +This must be organised either formally or informally. + +This document provides important information for organising and building a communityfootnote:[The community of an open source project typically represents a pyramid. + +The foundation of this pyramid is the users of the software, especially the committed ones who actively participate in the community, for example in the form of bug reports and feature requests or through contributions to mailing lists. + +Directly above in the pyramid are contributors. These are parts of the community that propose their own code contributions. They typically do not have write access to the repository. Their contributions are reviewed by maintainers of the project and incorporated into the repository after reaching the project-typical quality. + +At the top of the pyramid are the maintainers or committers of a project. In this role, a developer has a higher responsibility. This is expressed, for example, in the ability to accept contributions. This right is often manifested through write access to the repository. At this level, control over the software, its quality, and range of functions takes place. In more complex projects, this level can be further subdivided. For example, the Linux kernel is known to have subsystem maintainers at multiple levels, and ultimately only a single developer, Linus Torvalds, incorporates the patches into the project repository. Another example is projects of the Eclipse Foundation, which typically have a project lead with additional rights in the context of the Eclipse Foundation development process, such as initiating the release process or formal election of committers or project leads _[BITKOM2023]_.] and also for open development directly as an open source project. + +As a second element, to promote standardisation, a directory of existing community concepts is maintained as part of this document. The idea is that new communities can be built with minimum effort based on successful solutions. + +This document does not include direct recommendations for organising communities for software libraries (parts of software that fulfil partial functions, e.g. PDF generation). Normally, no separate concept is developed for these; instead, they use the simple template defined in the repository's storage template. + +The document link:em002-1.adoc[Em002-01 Practical Guidelines for Open Source Software in the Federal Administration] contains in Section 4 fundamental forms of collaboration, in Section 8 the various support models, and in the Annex information on market behaviour of open source. + +== Type, aim and purpose of a community + +A community can pursue the following purposes: + +* Survey of additional requirements +* Dissemination of knowledge about the application +* Better feedback from users +* Promoting translations, documentation and training +* Spreading standardisation +* Generally improved interaction with users +* Expansion of cooperation to include other parties +* Promotion of further software based on the software + +The type of community best suited for an application depends heavily on the professional environment, potential users, and the strategy of the publishing institution. There are many different ways to build communities. Ideally, for a suitable project, it may be possible to join an existing community. Alternatively, a community can be built with one or more equal partners. + +It is important that a *governance structure* should be established and the relevant points documented in a *community concept* (see also _[BITKOM2023]_ Section 4.1 and _[IZqCab2023]_). + +It should be noted that communities for software can also be combined with those for data, standardisation and business topics. The community can then encompass processes, standardisation, software and data. Existing frameworks such as eOperations, DVS and eCH can also be used where appropriate. + +An important aspect of a functioning community is that participants receive more than they invest. + +The following constellations exist: + +* *Community around a federal OSS*: Governance and community concept must be created. In this context, it is also necessary to regulate how third parties can make contributions. +* *New collaboration to solve a problem*: In addition to governance and the community concept, the entire legal structure of the collaboration must be established. +* *Joining a collaboration*: The Federal Administration must examine whether and how it can do this. +* *Contribution to a third-party project*: The point to be checked is the project's policy for contribution (Contributor Licence Agreement, Developer Certificate of Origin, etc.). + +Procurement law issues are dealt with in link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]. + +=== Special case: New collaboration for the development, maintenance and support of open source software + +The collective costs of open source software decrease when it is developed and further maintained collaboratively. This can occur without formal cooperation arrangements, or with no more than joint planning. + +Where a more formal collaboration is sought, a market assessment should be carried out to ensure that collaboration is the most appropriate form of cooperation. Collaborations are more cost-effective than individual development by each party (see link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]). + +It should be noted that, for collaborations, it makes sense to initiate the collaboration at a very early stage in the HERMESfootnote:[https://www.hermes.admin.ch/en/project-management/method-overview.html] project methodology --- specifically during the situation analysis and requirements phases. + +Collaboration is generally permitted in Switzerland under Article 4 EMOTA. + +In addition to all other considerations, collaborations have both a legal and a procurement law dimension. At present, each case is assessed individually. Over time, standardised templates will become established. + +==== Legal dimension + +Association memberships are feasible, though these are generally assessed on a case-by-case basis: who is behind the association, and what obligations are being entered into. Delegation of memberships to eOperations or similar organisations would be possible. + +As long as no money changes hands and no formal obligations need to be entered into, a Memorandum of Understanding at the level of the federal office or the Federal Chancellery is possible. + +A situation requiring the conclusion of an international treaty should be avoided. + +There are also two special casesfootnote:[https://www.eda.admin.ch/deza/en/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] in which a collaboration would already be covered: + +* Contracts awarded under an international agreement concerning the joint implementation of a project by signatory states. +* Contracts awarded in accordance with the special procedures or conditions of an international organisation. + +==== Procurement law dimension + +In many cases, collaboration will take place between public sector organisations. In such cases, procurement is unproblematic where the arrangement is 'in-state' (see link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]). + +Contracts with foreign companies not domiciled in Switzerland are possible, provided procurement law requirements are met. + +The procurement of an organisation's own resources takes place within the framework of a standard procurement process, or has already been completed. + +=== Special case: Joining an existing collaboration + +This requires both a legal basis and compliance with procurement law. + +The simplest approach is to participate on a 'each party bears its own costs' basis. This can also cover overhead costs, provided that either internal resources or correctly tendered external resources are used. + +Direct participation in foreign collaborations is more difficult. A simple association via a Memorandum of Understanding is the easiest option to achieve. + +=== Special case: Contributing code to third-party OSS projects + +Where the Federal Administration makes modifications to the code of an existing OSS project, it makes sense to contribute these changes directly upstream to the original project. This means that ongoing maintenance no longer needs to be carried out by the Federal Administration. + +Under Article 9 EMOTA, such contributions are in fact encouraged. From a procurement law perspective, this is unproblematic. + +It is important that the rights holder makes the contribution. This means that the Federal Administration assumes responsibility for doing so on behalf of its staff and contractors. Specifically, any Contributor Licence Agreement for the project must be signed, or a Developer Certificate of Origin must be included with the pull request. + +A *Developer Certificate of Origin*footnote:[https://developercertificate.org/] *(DCO)* for the Federal Administration could read: + +[quote, Developer Certificate of Origin, Version 1.1] +____ +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. + +Everyone is permitted to copy and distribute verbatim copies of this licence document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, we certify that: + +(a) The rights to this contribution are owned by the Swiss Confederation and I am authorised to submit it under the open source licence indicated in the file; or + +(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source licence and I have the right under that licence to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different licence), as indicated in the file; or + +(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. + +(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source licence(s) involved. +____ + +The structure of a Contributor Licence Agreement is described in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], Section 8.9. + +The effective transfer of code takes place in accordance with the guidelines of the respective project. + +== Community concept + +A community's core is ultimately its structure and governance. These are recorded in a community concept. + +The community concept to be created by the project or application manager (or commissioned from third parties) should follow this section structure. Depending on the nature of specific community, not all sub-sections are necessary. Ideally, many sections will refer to already standardised documents or use standard processes of the corresponding repositories. The community concept can also be applied to existing projects led by others, especially if the effective governance is not yet documented in writing. + +By formalising the community, all participants are brought together and the onboarding of new participants is simplified. + +Structural draft of a community concept: + +[arabic] +. Overview table (name, repository, contact address, licence, depth of support, existing/new) +. Objectives +[loweralpha] +.. of the application +.. of the community +. Organisation +[loweralpha] +.. Owner of the code +.. Organisational form / committees +.. Voting rights +.. Project management +.. Procurement issues (if applicable) +.. Other governance aspects +. Roadmap and change process +. Development process +[loweralpha] +.. Open development +.. Committer rights +.. Review process +.. Task distribution and name citations +.. Backups +. Financing of the community +. Marketing +. Handling external contributions +[loweralpha] +.. Handling reported errors +.. Handling enquiries +.. Handling pull requests +.. Handling forks +.. CLA, DCO and assignment of rights/intellectual property +. Operation of the application + +In principle, each federal authority is responsible for creating the community concepts. DTI can publish existing patterns/examples and accepts corresponding examples for publication. It also makes sense for community managers to exchange information with each other. + +A possible source for parts is also the documentation of the Eclipse Foundation,footnote:[See https://www.eclipse.org/projects/handbook/#starting] although appropriate tailoring should be carried out here in the sense of 'only doing what is necessary'. + +== Fundamental decisions when building a community + +The principles of the community, or lack thereof, are determined using link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]. The relevant fundamental questions can be found in the morphological box in Figure 1. + +image::assets/em002-4/media/image1.png[Morphological box OSS community] + +Figure 1 Morphological box OSS community + +It is advisable to *focus primarily on the near future* when designing the community; for example, if there are not yet any concrete interested parties for the application, it usually makes little sense to define a community with a simple company, its own association and complex processes for developing the roadmap.footnote:[With an association (or foundation), a separate legal entity is created to look after the software and the product. This only pays off from a certain level of importance, complexity and the existence of several (equal) partners. A roadmap is used to show the wider public and potential additional users of the software what is planned.]footnote:[It may also be possible, especially for projects that involve several state actors from the outset, to approach existing foundations and see whether the projects and governance can be managed under their umbrella, analogous to https://finos.org or https://osr.finos.org or https://www.eclipse.org/collaborations/ or https://iot.eclipse.org or https://outreach.eclipse.foundation/open-regulatory-compliance.] + +=== Product management + +Depending on the type of application, its strategic importance and its status in the life cycle, there are different variants for mapping product management. For organisations within federal authorities, this always concerns the application managers. The definition of the technical and technological roadmap and the release processes are particularly relevant for the community concept. + +Possibilities: + +[loweralpha] +. *Organisations within the Confederation*: The Confederation wants to retain control; it alone defines the roadmap. +. *Joint organisation*: Together with other users or suppliers. +. *Open organisation*: Loose connections, no active roadmap. +. *Third parties*: Either the product already exists or the work is to be outsourced. + +==== Organisations within the Confederation: + +If the application is of high strategic importance or the Confederation depends on being able to implement its changes quickly, then it can make sense to retain control. + +The federal authority alone decides, through the requirements manager, what is incorporated in the software and when. + +For potential other users of the application, this means that they are practically forced to use their own version (fork) of the application. + +Otherwise, they have hardly any opportunity to implement adjustments and extensions that may be important to them. This does not argue against publishing as open source: the code management toolsfootnote:[e.g. GitHub] offer extensive support for such scenarios, and adjustments and error corrections can be selectively adopted in both directions. + +Sharing the costs is typically difficult with this model. + +==== Joint (Confederation has the lead or equal partners) + +Decisions regarding the roadmap and priorities should be coordinated and made jointly with the other members of the community. The Confederation participates as a member of the community but is not the lead organisation. + +For joint decision-making to work, structures and rules must be determined in advance. This also defines how the costs for implementing the jointly decided adjustments are divided among each other. + +With this model, a single version of the application is created, which is then used by all members. As a result, the total costs are significantly lower compared to the other variants. However, the flexibility of individual users is also lower, and they must coordinate their adjustment requests in advance with all others. Decision-making is slower and more time-consuming. + +This model is best suited for applications that are to be further developed jointly with clearly defined other organisations (e.g. cantons). + +==== Open organisation + +In this model, the processes and structures are only loosely defined. The Confederation formally retains control but is open to contributions and adjustments. + +No roadmap or only a very rough one is defined; consensus is reached informally and in discussions directly on the publication platform. The community itself tends to be dynamic; members can be very active for a while and then withdraw again. + +This model is also suitable for smaller applications that are already in productive use and are 'finished'. This is also usually the best form for technically orientated applications or components that potentially appeal to a broader target group which cannot be precisely defined in advance. + +==== Third party + +In this model, the processes and structures are defined by a third party and the federal authority is a member of the community but does not have the lead. This may have happened because, for example, the project was defined by another state or canton. Or it may be that the Confederation is not interested in continuing the program itself and transfer this task. + +=== Integration of suppliers + +There are basically the following possibilities for integrating suppliers: + +[loweralpha] +. *Supplier as contractor*: They are generally considered replaceable in the medium term. The supplier should develop the application cost-effectively and to a high quality based on orders from product management (or the community), but has at most advisory influence on the roadmap and prioritisation. +. *Long-term partners with co-determination*: They should be able to actively co-determine the development. This strengthens their role and they are potentially willing to invest in the application themselves. Typically, in this model, the suppliers then distribute the software and actively look for new customers. +. *Independent:* The suppliers define for themselves whether and how they want to work on the project. This can occur, for example, if several suppliers want to generate their own business based on the software. Liberal licences can potentially promote this. It can also occur if the Confederation's strategy differs from that of the supplier. In this scenario, it is likely that the supplier will create a fork. +. *Lead*: If the supplier takes over product management, then they have the lead. The development is then determined by them. On the other hand, this can also mean that the Federal Administration has to take very little responsibility. With a minimum release, it is possible for the supplier to take on this role on their own. + +If the supplier takes on a strong role, this brings advantages for the Federal Administration: by actively marketing the application, there is a chance that the community will grow faster and stronger, thus reducing the costs per member more quickly. + +If a model with strong supplier co-determination is chosen, care must be taken that this does not result in a deviation from procurement law regulations. It is usually advisable to involve at least two suppliers to avoid creating too strong a dependency on a single supplier. There should also be the possibility for other suppliers to join the community. + +=== Cost distribution + +The following options are available for splitting the costs of maintenance, further development and new functions: + +[loweralpha] +. *Organisations within the Confederation*: Especially when building ecosystems or if the federal authority will retain full control, the federal authority must also bear the costs. +. *Each their own*: Everyone pays for the changes they want themselves. If necessary, it is decided on a case-by-case basis to pay for certain extensions jointly. Recurring costs are billed according to a distribution key or on demand. +. *Originator pays principle*: Those who actually need the services or features pay for them. Standardised hourly rates may be applied. +. *Distribution key*: The costs are divided within the community according to a defined key. This only differs for specific expansions. These should be paid for directly by the users concerned. The cost divider can be, for example, the size of the canton concerned or the number of users. Regarding the distribution key, see also Section *Fehler! Verweisquelle konnte nicht gefunden werden.*. +. *Contribution*: If the federal authority only contributes personnel to an existing project. + +Basically, variant b (cost sharing) usually only makes sense if there is also joint product management as in variant b (joint). Only those who can have a say will be willing to bear the follow-up costs of the decisions. + +=== Support + +Within the cost distribution and effort, it is important to clarify who provides what support. According to Art. 9 EMOTA, a pure minimum release is possible. This variant may not deliver the desired effect and does not in itself build a community in which the federal authority has influence. + +[loweralpha] +. *Minimum release*: No support (i.e. release generally occurs without organised support and participation of the federal authority). +. *Support by the Confederation*: The federal authority (or its service provider) provides defined support. +. *Support by third parties*: The federal authority or the community defines a support organisation. + +The effect to be achieved, e.g. on the Swiss ecosystem or initial funding of a community, can lead to the Confederation providing support. The level of support must of course be defined. In principle, a fee may also be charged. Due to the mechanisms of the Confederation, service providers or suppliers are then more likely to be able to offer commercial support. + +Offices may offer paid support in accordance with EMOTA (possibly also via service providers and third parties). To do this, they must publish the corresponding fees on their website, as the necessary legal basis is in place. The connection to the payment system can be discussed with the FDF. + +Examples of support and fees can be found in Annex G. + +=== Development + +The basic methodology of development can also have an influence on the type of community. + +[loweralpha] +. *Internal*: The use of internal repositories means that third parties cannot work directly. The stricter the separation, the more integration effort the Confederation has to make if it wants to incorporate third-party extensions. The release process is also more complex. +. *Third parties*: Either a supplier works on their own or the product already started/led by a third party is developed according to defined rules. +. *Open*: Software development takes place directly in a public repository. The release according to EMOTA is therefore largely guaranteed. The expenses are to be paid during development. In this scenario, collaboration with third parties can also take place earlier (and more easily). + +== Detailed content for the community concept + +This section provides guidance on writing the community concept based on the fundamental decisions made (as per Section 5). + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|open +|Partner +|Federal government +a|Contents or suggestions, if the basic decisions are: + +Product management c) Open organisation + +Supplier involvement: b) Supplier as partner + +Cost distribution: b) Each their own + +_The text above can be copied into the template and adapted._ + +|Joint +|- +|Each their own +a|Contents or suggestions, if the basic decisions are: + +Product management b) Joint development + +Supplier involvement: a) or b) (not relevant) + +Cost distribution: c) Originator pays principle or d) Cost sharing + +|Joint +|- +|Originator +| +|=== + +The community concept should be a dynamic document that can be adapted in consultation with the community. The concept should reflect the current situation and propose future development options. If more members join the community later, the organisation and processes can be further elaborated, and more complex mechanisms can be introduced. The following sub-sections directly follow the proposed structure of the community concept (see Section 4). + +If product management lies with third parties, they will define the concepts for the community. + +=== Key information + +The following key information should be drawn up and published for each community so that potential interested parties can register for the software and the community: + +* Software name +* Repository +* Owner +* Responsible organisational unit/office +* Contact address +* Licence used +* Support level +* Existing project + +This information can all be displayed with publiccode.yml.footnote:[https://yml.publiccode.tools/] + +=== Objectives + +The objective should contain the actual purpose or 'vision' of the application. This vision should also be included in the *README.md* file in the repository (see link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist]). + +At the same time, it should also describe what the community is aiming for: + +* Who should join? +* Who are the potential interested parties? +* Should new members be actively sought? +* What are the main goals pursued by publishing as open source? + +=== Organisation and governance + +In principle, for new developments, the aim is for the Confederation to be the owner of the master rights to the source code. + +The type of project management depends on which organisation had the lead (SAFe, HERMES) in the case of the Confederation. The organisational form should always seek minimum overhead (existing rather than new; simple partnership rather than an association). + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|- +|Internal +a|As the Confederation retains direct control, no additional organisational structures are necessary. + +The publishing entity (e.g. a federal office) retains ownership and assumes all coordination tasks. In this case, the 'Organisation' section can be kept very brief. + +|Joint +|- +|Internal +a|For this scenario, organisation as a *simple partnership* is usually recommended. + +To enable joint development and coordination of the roadmap and requirements, it is advisable to create two groups, each with one participant per community member: + +* Management Board: Defines the strategy and prioritisation. +* Expert group: Develops requirements and specific content at the expert level. Depending on the scope, a separate expert group can also be established for each topic. + +The owner of the code is the office that published it. + +If the structures become more complex or more than five users or additional members are involved, it may be worth considering whether the community should be better organised as an association. Compare the explanations in the variant directly below. + +|Joint +|- +|Third party +a|Organisation as an *association* is recommended. + +Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association. + +The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers. + +|Joint +|Contractor +|Internal +a|Organisation as an *association* is recommended. Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association. + +The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers. + +Here, the suppliers are not members of the association, but only contractors. The manager should not be appointed by a supplier. + +|Joint +|Contractor +|Third party +a|Organisation as an *association* is recommended. Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association. + +The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers. + +The suppliers are members of the association; the manager can also be provided by a supplier. + +|open +|- +|Internal +a|There is no *need for a detailed description of an organisation*, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). It should also be determined whether and to what extent external persons can be involved: + +* No direct integration: External parties can only submit suggestions and contributions (as pull requests). +* Involvement as contributors: External parties who make frequent and good contributions are directly involved. +* Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. + +The publishing organisation retains ownership. This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information. + +|open +|Contractor +|Internal +a|There is no *need for a detailed description of an organisation*, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). It should also be determined whether and to what extent external persons can be involved: + +* No direct integration: External parties can only submit suggestions and contributions (as pull requests). +* Involvement as contributors: External parties who make frequent and good contributions are directly involved. +* Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. + +The publishing organisation retains ownership. + +This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information. + +The supplier should only take on purely technical coordination tasks (code review, assessment). + +|Third party +|Partner +|Internal +a|There is no *need for a detailed description of an organisation*, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). It should also be determined whether and to what extent external persons can be involved: + +* No direct integration: External parties can only submit suggestions and contributions (as pull requests). +* Involvement as contributors: External parties who make frequent and good contributions are directly involved. +* Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. + +The publishing organisation retains ownership. This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information. +|=== + +With regard to governance, _[BITKOM2023]_ Section 4.1, _[IzCab2023]_ or https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md#governance-models can also be consulted. + +Examples of articles of association can be found in Annex E. + +NB: As the release must be guaranteed in accordance with Art. 9 EMOTA, the Federal Administration must ensure that the publication cannot be suddenly withdrawn (see the 'Open Source in Procurement Guidelines -- Software purchasing under Art. 9 EMOTA' _[BBL-WL]_, paragraph V.2). + +=== Roadmap and change process + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|Contractor +|- +|The federal authority defines the roadmap and decides which changes will be implemented. The standard processes of the office XY are used for this. + +|Federal government +|Partner +|- +|The federal authority defines the roadmap in collaboration with company XY. It decides which changes will be implemented. The standard processes of the office XY are used for this. + +|Joint +|- +|Internal +a|The process for developing the roadmap and approving changes must be determined by the members of the company or association. Depending on the member structure (number, size ratio, etc.), other processes may be appropriate. + +However, the processes must include measures for conflict resolution and finding a majority. + +|Joint +|- +|Third party +a|The process for developing the roadmap and approving changes must be determined by the members of the company or association. Depending on the member structure (number, size ratio, etc.), other processes may be appropriate. + +However, the processes must include measures for conflict resolution and finding a majority. + +With the addition that a cost distribution key must also be established. Consideration should also be given as to how to handle cost sharing for adjustments not desired by the relevant members. Especially in associations with members of unequal size, situations may arise where a large member (e.g. the federal authority) bears a significant portion of the costs for an extension without deriving any benefit from it. + +|open +|- +|- +a|_Example, not suitable for all situations_ + +There is no need to create a roadmap; the application currently meets the needs. + +Changes are decided upon in an open discussion and a consensus is sought. The final decision lies with the owner of the code (Swiss Confederation). +|=== + +=== Development process + +If open development comes into play, it should be defined here. Task distribution and naming of central positions in the community concept are important. Also, how the security of the repository content is ensured. + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|- +|- +a|The committer rights (write access to the code) lie with the persons/entities/suppliers selected by the Confederation. After the contract expires, the respective rights are revoked. + +The service providers and suppliers are responsible for conducting the technical code review process for external contributions that have been technically accepted by the Confederation. They are responsible for the technical quality. The suppliers are compensated for this work by the Confederation. + +|Joint +|Contractor +|Internal +a|In principle, all entities commissioned by a community member receive write access to the code (committer rights). After the contract expires, the respective rights are revoked. + +Where changed code affects core areas of the application, all changes must be reviewed by an entity specially commissioned by the community for this purpose. This entity is responsible for the technical quality of the application. It is also responsible for reviewing changes that have been technically accepted by the community. + +|Joint +|Partner +|Third party +a|The committer rights (write access to the code) lie with the members of the community. These persons organise themselves and jointly bear responsibility for the quality of the code. + +If a community member commissions an external supplier for an adjustment or extension, the adjustment is reviewed by a member of the community. They are compensated for this by the client. + +Changes to the core of the application must be reviewed by a second member of the community. + +The suppliers who are community members are also responsible for reviewing external contributions and new technical code that has been technically accepted by the association. + +|open +|- +|- +a|Initially, the committer rights lie with the developers or their employers. Committer rights are granted to all developers who actively contribute to the project for several months and demonstrate appropriate social competence. + +The individual developers generally retain their committer rights, even if they change their employer or the Confederation chooses a different supplier. Committer rights only expire if they are voluntarily relinquished or if the majority of other committers decide to revoke them. + +The Confederation has the right to designate individual developers from the companies it commissions as committers. It does not have the right to revoke someone's committer rights without reason. + +Code reviews are carried out by at least one person who acts as a committer. Committers organise themselves. + +The Confederation undertakes to compensate the review work as far as it is financially feasible for them. +|=== + +=== Cost sharing and suppliers + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|Contractor +|Internal +|Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). + +|Federal government +|Partner +|- +a|*Important:* Check beforehand whether this is permissible under procurement law in the specific case. + +We will make additions to the documentation on this point. The Confederation chooses the supplier XXX as a strategic partner and aims for long-term cooperation. + +|Joint +|Contractor +|Internal +a|Each member of the community independently commissions one or more software suppliers to implement the adjustments and extensions they require. Cost sharing is agreed on a case-by-case basis for adjustments requested by several members. The member with the largest share of the costs is responsible for selecting and commissioning the supplier. (Regulations for software maintenance) + +|Joint +|Contractor +|Third party +|The association centrally selects the software suppliers periodically through WTO tenders or direct award procedures (depending on the scope of maintenance services). The costs are allocated to the members according to a key: (to be defined: by population, user, etc.) + +|Joint +|Partner +|Internal +a|Each member of the community independently commissions one or more software suppliers to implement the adjustments and extensions they require. Cost sharing is agreed on a case-by-case basis for adjustments requested by several members. The member with the largest share of the costs is responsible for selecting and commissioning the supplier. + +_(Regulations for software maintenance)_ If necessary, supplemented by a contribution from the participating suppliers. Example: _Each software development company that is a member of the community commits to investing at least XY working days per year at its own expense in the further development, technological updating, or marketing of the application._ + +|Joint +|Partner +|Third party +a|The association centrally selects the software suppliers periodically through WTO tenders or direct award procedures (depending on the scope of maintenance services). The costs are allocated to the members according to a key: (to be defined: by population, user, etc.) If necessary, supplemented by the addition: _Each software development company that is a member of the community commits to investing at least XY working days per year at its own expense in the further development, technological updating, or marketing of the application._ + +|Third party +|Contractor +|- +a|Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). With the addition: _The improvements contributed by potential suppliers and activities in the community are considered as a factor in the evaluation._ + +Changes requested by external parties are not financed by the Confederation, but must be commissioned and paid for by the parties themselves. + +|Third party +|Partner +|- +a|Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). With the addition: _The improvements contributed by potential suppliers and activities in the community are considered as a factor in the evaluation. Changes requested by external parties are not financed by the Confederation, but must be commissioned and paid for by the parties themselves._ +|=== + +=== Marketing + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|Contractor +|- +|The Confederation does not actively market the application but publishes it on open-source software platforms. The publication of the application is announced in professional committees. If interested parties come forward, we will consider whether to establish a joint community or continue working with their version of the software. + +|Joint +|Partner +|- +a|Additionally: + +Suppliers may market the application and seek further interested parties. The Confederation may be cited as a reference. We consciously accept that divergent versions of the software may emerge as a result. + +|Joint +|Contractor +|Internal +|The application is marketed by the members or the association. + +|Joint +|Partner +|Internal +|The application is marketed by suppliers. + +|Joint +|- +|Third party +|The application is marketed by the association, the simple partnership and its members. + +|open +|- +|- +a|The application may be marketed by suppliers, or explicit marketing may be foregone. + +Alternative without explicit marketing: The Confederation does not actively market the application but publishes it on open-source software platforms. In professional committees, we indicate that we have published the application and that collaboration is welcome. We demonstrate the software to interested parties and attempt to integrate them into our processes for shaping the roadmap. +|=== + +=== Handling external contributions + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Federal government +|Contractor +|- +a|External contributions and enquiries must also be processed even if the Confederation remains the sole decision-maker regarding the software (except in cases of minimum release, where a fork is inevitable). We propose the following approach: + +*Handling reported errors* + +We attempt to reproduce errors reported by external individuals, requesting clarification if necessary. If reproduction is successful, the Confederation commissions the correction of errors. If the error cannot be verified or if the effort to fix it is disproportionately high, we apologise to the person reporting the error and ask if they could submit a pull request to address it. + +*Handling enquiries* + +We respond to every incoming enquiry. If an enquiry cannot be resolved with reasonable effort and further time investment seems inefficient, we apologise, citing limited resources, and offer to connect the enquiring person with a supplier for further consultation. + +*Handling pull requests* + +We review each pull request carefully. To avoid unnecessary effort on the contributor's part, we immediately indicate if something contradicts our roadmap or if it is questionable whether we will accept the contribution. The Confederation decides independently and based on technical criteria which contributions to accept. Error corrections that have passed the review process are always accepted. + +*Handling forks* + +We support forks of our application. Those who implement the application should create their own fork. We review the resulting forks at least once a year and adopt good and suitable extensions. + +|Joint +|- +|- +a|External refers to contributions from outside the defined community (association members). Deviations from above: + +*Handling forks* + +We aim to prevent (long-lived) forks of the application. Instead, interested parties should join the community directly. Within the community, we try to ensure all members use the main version. + +|Open +|- +|- +a|Building a functioning community and an open culture is important to us. + +*Handling reported errors* + +We attempt to reproduce and correct reported errors. We require active cooperation from the reporting individuals. If possible, they should create a pull request with an error correction directly. + +*Handling enquiries* + +We address each enquiry within a maximum of one week. Enquiries from active contributors are treated with priority and in depth. We try to involve other members in handling enquiries. + +*Handling pull requests* + +We aim to receive as many high-quality pull requests as possible. We involve all active contributors in the reviews and technical and professional assessment of pull requests. For controversial contributions, we try to reach a decision through informal voting. + +*Handling forks* + +We try to make forks unnecessary through active and open community management. If forks do emerge, we actively review them and attempt to incorporate the extensions and improvements developed there. In such cases, we actively request pull requests. +|=== + +In general, it should be noted that contributions can range from supporting other users to taking responsibility for entire parts of a project (see _[BITKOM2023]_ Section 4.2). + +=== Operation of the application + +[cols="1,1,1,4",options="header"] +|=== +|Product management |Supplier as |Development |Proposal + +|Joint +|- +|- +|Central operation can optionally be offered additionally by the central association, in the sense of Software as a Service (SaaS). It should be examined whether this is desired. + +|- +|Partner +|- +|It should be specified whether the supplier should also operate the software. + +|- +|Lead +|- +|It should be stated that the supplier is responsible for operation. +|=== + +Support levels and support contacts should also be specified in this section. + +== Important information for community managers + +=== It takes time + +Building communities is something that should be planned for the long term. Perseverance and consistency are two important qualities needed for a successful community. + +=== Further suggestions for community building + +Further suggestions for good community management can be found at https://opensource.guide/code-of-conduct/ and https://opensource.guide/best-practices/. + +=== Communications + +Publishing software and documentation opens a new communication channel for the Federal Administration. If this is not done carefully and professionally, the public image of the Confederation can suffer. + +OSS communities in the Federal Administration are faced with conflicting demands regarding communication: on the one hand, the general *guidelines for communication* apply; on the other hand, the community should facilitate *simple formal and informal collaboration* across organisational boundaries, preferably without formal quality controls and releases. + +The use of public repositories and potentially public issue tracking and wikis means that individual project staff members' statements are visible to the public unfiltered. This requires project staff to maintain a professional demeanour and adhere to quality standards for publications in such settings. + +In OSS projects, this is normally regulated through the *Code of Conduct*. The Federal Administration's own Code of Conductfootnote:[https://www.epa.admin.ch/dam/epa/fr/dokumente/aktuell/medienservice/120_verhaltenskodex_e.pdf.download.pdf/120_verhaltenskodex_e.pdf] is very general, but the core principle is applicable here: "Staff carry out their duties with a sense of responsibility, integrity and loyalty. In their private lives they also take care not to tarnish the reputation, the credibility and the image of the Confederation" + +=== Open development + +If software development is planned in an open repository from the start, release happens automatically. The relevant checklists according to the instructions link:em002-2.adoc[Em002-2] must be completed at the beginning, and the development processes of the service provider/supplier must allow this. The advantage is that the community can be built from the very beginning. Multiple organisations can also collaborate on the development. + +Closed repositories are an intermediate form, but are used for other partners in a collaboration. + +=== User management + +The project (or the support organisation) determines whether developers and other project staff work on the project under their own name or anonymously. If people are not working anonymously and already have logins on the platforms, it is easiest to use these (whether business or private). + +The platform should generally allow the inclusion of third parties, as otherwise no developers from outside the Confederation will be able to collaborate. + +When leaving the project, the corresponding rights on the project must be deleted. Product management is responsible for this. + +=== Merging communities + +Where possible, the number of communities should be kept small. This means: + +* If a community already exists where a similar structure is envisaged for similar problems involving the same people, a single community should be used. +* Multiple projects that are related and address the same target audience can be consolidated into one community. +* No fundamentally different community structures should be created unnecessarily where existing ones are already in place. + +=== Handling third-party contributions + +The contribution of software to other projects is addressed in Section 3.3. The same principles apply in reverse. + +The following points are important: + +* A suitable Contributor Licence Agreement must be used to ensure that the source code subsequently belongs to the Confederation (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], section on Contributor Licence Agreements). This must be signed by the owner of the contribution. +* Confirmations must be filed. +* Contributions must be reviewed before being integrated into the codebase. +* Submissions should be responded to in a timely manner (issues, requests, pull requests) and handled as constructively as possible. +* All channels and governance arrangements should be listed in the community concept, on the website and in the repository. + +=== Security-relevant reports + +In addition to standard bug reports, provision must be made -- where the nature of the project requires it -- for security-related vulnerabilities to be reported confidentially, as is the case with a bug bounty programme, for example. + +The documents from trustbroker.swiss can serve as an example: + +* https://github.com/trustbroker-swiss/trustbroker.swiss/blob/main/Security-and-Vulnerability-Disclosure.md + +=== Avoiding forks + +While forks are natural in the open source world, reintegrating source code, features and so on from forks is far from straightforward. It may be worth reaching out to the individuals or organisations considering a fork and trying to keep them engaged with the main project. Striking a balance between competing interests is often necessary in such cases. + +=== Cost allocation + +It makes sense to agree on general distribution keys between the main partners. These can be adjusted every few years or when the situation fundamentally changes. For efficient work on the software, the large partners should tend to take on slightly larger shares than they actually have to (if necessary, also the overall coordination). The organisation should work and not argue about finances. If the collaboration covers several projects (for example, the industry solutions in the field of standard gauge railways), a standardised distribution key should be used for all projects. From the perspective of federal authorities, it is an improvement if the costs do not have to be borne alone. + +Possible criteria for distribution keys: + +* Estimation of benefit distribution (e.g. between federal authority and a supplier hoping for other customers) +* Number of inhabitants/users (e.g. between offices, communes, cities) +* Financial strength (e.g. cantons) +* Gross national product (e.g. between cantons) +* Who wants more control + +To avoid discussions, the distribution key should not simply be attached to the annual budget. A clause along the lines of the originator pays principle may allow faster adjustments for some partners if they are willing to pay extra. + +The distribution key should also apply to overheads, maintenance/support, and a minimum of further development. These parts should be solved in the long term if possible. + +It should be borne in mind that when third-party funding is involved, those parties will typically want a greater say. Community management needs to be equipped to handle this. + +=== Supplementary services according to Art. 9 paras 5 and 6 EMOTA + +The federal authorities can (themselves, through service providers or suppliers) provide supplementary services, particularly for integration, maintenance, ensuring information security, and support. + +The limitation is that they should serve the authorities' tasks and can be provided with proportionate effort. + +It follows that the federal authority cannot be the development company for third parties. It fixes bugs, can handle security-relevant aspects, can provide some support and integration assistance (all activities that help to build a community). New developments and additional features for third parties should primarily focus on the normal work purpose of the authority. Of course, it may be that providing the software is part of the task, in which case developments can be made at any time. It is also stated that software development is not the core task of the federal authority. + +This means that if features are substantially developed exclusively for third parties, they are to be integrated in partnership or through the supplier. + +To avoid procurement law problems, care should be taken in procuring software and services to ensure that features can be provided to third parties (possibly only governmental third parties) by suppliers. + +The setting of fees has already been touched upon in the 'Support' section. EMOTA is already the legal basis for such fees. These must be communicated on the website of the respective federal authority. Examples are listed in Annex G. + +Art. 9 para. 6 states that normally the private sector should not be competed with. This means that the fees should not be set too low and should at least cover costs. In case of doubt, it is better to set hourly rates too high rather than too low. + +Generally, it is recommended to work with one to three different standard hourly rates. + +If a federal department wishes to define exceptions to para. 6, this must not compete with the private sector. Under certain circumstances, it may be easiest to set the fees and increase them if there is opposition from private sector companies that can actually offer the service. + +=== Digital sovereignty + +As long as the Confederation does not have its own repository, to ensure digital sovereignty, it is recommended to regularly make copies from public repositories. + +It should be noted that not only the source code but also other information such as issue tracking, wiki, configurations, etc. is copied. + +Furthermore, user management needs to be resolved to ensure control over the published source code. The overarching goal is to ensure development independent of the respective platform and to enable the community to switch.footnote:[See also https://www.bfh.ch/de/aktuell/news/2024/neue-studie-digitale-souveraenitaet/] + +== Annex + +=== Changes from previous version + +* Section 1 'Main points at a glance' added +* Community purpose added to Section 3 +* Sections 3.1 to 3.3 on Collaboration added +* New Section 7.7 Handling third-party contributions +* Noted that suppliers should not publish entirely on their own (in accordance with _[BBL-WL]_, V.2) +* Publicode.yml mentioned +* Alignment with new link:em002-7.adoc[Em002-7] +* Further editorial changes and improvements + +=== References + +See _Em002 Strategic Guidelines for Open Source Software in the Federal Administration_. + +=== Abbreviations + +See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. + +=== Examples of existing community concepts + +In the spirit of collecting best practices, the following are community concepts and comparable documents that have already been developed. These are not necessarily just concepts from federal authorities, but also from other organisations. + +* GERES Community (http://geres-community.ch) + +Classification: + +* Product management a) Joint development +* Supplier rather a) Contractor +* Cost distribution: b) Cost sharing + +NB: The commune register GERES is not open source, but many aspects of the organisation can also be relevant for open source applications. Documents: Statutes (public) and Rules of Procedure (on request). + +* https://www.igovportal.ch[iGov Portal] + +#This section currently contains concepts from the Canton of Bern and will be supplemented as soon as federal examples are available.# + +=== Examples of collaborations + +The following examples illustrate how collaborations have been structured. + +=== Collaboration: ZenDiSfootnote:[https://www.zendis.de/en[ZenDiS home page: Co-creating Digital Sovereignty]] in Germany + +ZenDiS is an organisation whose aim is to reduce dependency in public administration (primarily in Germany) by promoting open source software. + +image::assets/em002-4/media/image2.png[Goals and approaches to strengthening digital sovereignty (ZenDiS)] + +Figure 2: Goals and approaches to strengthening digital sovereignty (ZenDiS) + +ZenDiS works with strategic partners to this end. + +Cooperation between the Federal Administration and ZenDiS is therefore unlikely to be unrestricted, and coordination would not be binding. This may change in due course. + +In concrete terms, the Federal Administration would need to establish its own organisation for Switzerland and coordinate informally with ZenDiS. This could potentially be done via eOperations, though eOperations only becomes active when a specific requirement is raised and a budget is made available. A justification for such a parallel organisation could be found in the context of eGovernment or EMOTA. + +NB: ZenDiS is subject to EU/German procurement law. There are significant differences compared to Switzerland. ZenDiS therefore cannot be replicated on a one-to-one basis in Switzerland, and cooperation with ZenDiS is not straightforward. + +=== Collaboration: Open Trip Planner (OTP) + +Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] is an open source travel planning application. It is organised as a project of the Software Freedom Conservancy in New York. Individual developers are employed by transport companies and suppliers. A notable feature is that a public sector actor -- specifically ENTURfootnote:[https://entur.no/] -- has taken on one of the leading roles. ENTUR develops primarily for its own needs but also has a collaborative focus, particularly for the Nordic countries. ENTUR is organised as a company owned by the Norwegian Ministry of Transport and Communications. As the largest actor, ENTUR also absorbs a significant share of the coordination costs. Anyone can submit feature requests; these are discussed in coordination meetings and developed if someone funds them. Funding is provided primarily on a per-feature basis by the interested party or parties. In essence, each party bears its own costs. Support services would also need to be put out to tender separately in Switzerland. + +=== New collaboration initiated by the Confederation: Swiss Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] + +The Trust Broker is a piece of Confederation software for eIAM, available as open source. Development is carried out by the Confederation. Several cantons have decided to deploy it either directly as SaaS or with their own instances. As it is available under the AGPL licence, any extensions made will benefit the Confederation in turn. Given its security-critical nature, development for the Federal Administration is carried out exclusively by the Confederation. Other organisations may submit requirements, which will be implemented if the project team considers them appropriate. + +=== New collaboration initiated by the cantons: inosca + +Through inosca,footnote:[https://inosca.ch/] a number of cantons have established a development community focused on electronic permits, originating with the eBau project.footnote:[https://github.com/inosca/ebau] eBau also includes Caluma,footnote:[https://github.com/projectcaluma] a framework for collaborative editing -- an example of a component extracted from a broader solution and developed into a standalone, widely applicable framework. This can also be used in other projects, even where some parts are subject to exception conditions, thereby allowing the maximum number of other bodies to benefit from the code. + +The community meets at least once a month (optionally twice) to exchange views on technical topics and plan the shared roadmap. All participants may raise topics. Where a topic is deemed relevant to the community, interested cantons come forward and organise themselves into a working group. Outcomes are feedback continuously to the community. inosca operates on a fundamental principle: those who design, fund. That is, all cantons participating in a working group share the cost of the new feature. The feature is put out to tender and costs are divided among the community according to a predefined cost-sharing formula. Once a feature is completed and deployed, it immediately becomes freely available to all other cantons. + +The community has additionally decided to set aside a modest fixed annual amount to cover the administrative costs of running the community. This budget is allocated each year to the parties taking on an organisational role. + +=== SNOWPACK by WSL -- direct contributions from developers + +SNOWPACKfootnote:[https://snow-models.gitlab-pages.wsl.ch/snowpack-web/] is an open source project developed by WSL for modelling snowpack formation. It is a highly specialised model, and the community has accordingly been integrated into the existing specialist community. Some issues have already been earmarked as potential contributions. The working model here is that each party bears its own costs and contributes features. Coding style and release process guidelines are also documented in this context. + +=== Inspiration for association statutes + +The statutes should be kept as simple as possible. + +The following statutes can serve as inspiration. + +* eCH: https://www.ech.ch/sites/default/files/page/STAT_d_DEF_2014-04-10_ech-Statuten.pdf +* Stop Piracy: https://www.stop-piracy.ch/wp-content/uploads/2022/01/Statuten_d_10_09_2021.pdf + +#Further examples of statutes will be added as soon as they are available.# + +=== Examples of support and fees + +* Fees for statistical services: https://www.fedlex.admin.ch/eli/cc/2003/326/en[https://www.fedlex.admin.ch/eli/cc/2003/326/de] +* FDPIC fees: https://www.edoeb.admin.ch/edoeb/en/home/datenschutz/grundlagen/dsfa.html +* Free services from IPI for courses in the field of intellectual property (not software, but as an example): https://www.ige.ch/en/services/ip-academy/general-information/prices + +Examples will be added as soon as they are available. diff --git a/docs/en/em002-4.md b/docs/en/em002-4.md deleted file mode 100644 index 781a2c0..0000000 --- a/docs/en/em002-4.md +++ /dev/null @@ -1,1585 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# Main points at a glance - -The most important points of the document are listed below. - -- The establishment or maintenance of an OSS community is **not required** under Art. 9 EMOTA. - -- A community is relevant if a user group makes sense and **synergies** with other users of the software are to be created. - -- A community is not limited to the software itself, but can also include the processes in the environment and the standardisation of data. - -- An **initial effort** must always be made to build a community. This usually continues. In many cases, it makes sense for the lead office to also bear the coordination costs. - -- Communities should fulfil a **purpose**. There need to be interested parties and participants. - -- A community can emerge and then be formalised. - -- The goal of the community is to increase the **benefit for everyone**. - General principle: \'You get back at least as much as you put in\'. - -- The community should be **structured as simply as possible**. - -- In a first step, the community should be briefly reviewed using the checklist [Em002-4.1](./Em002-4.1%20Checklist%20OSS%20Community.odt). Only if it makes sense should it be further developed. - -- Formalisation takes place via a **community concept**. As much as possible should be taken from existing sources. - General principle: \'Don\'t reinvent the wheel\'. - -- If collaboration is the aim, this must be taken into account at the very beginning of the project, as potential partners should already be picked up during the requirements analysis. This also needs to be well planned from the outset in terms of legal and procurement law. - -- The options for joining an existing collaboration in regard to legal and procurement law must be examined. - -- No community needs to be set up for contributions. However, if required by the project, the corresponding **Contributor Licence Agreement (CLA)** must be signed or the developers must be uthorised by the project to submit the software under a Developer Certificate of Origin (DCO). - -# Introduction - -These guidelines are intended for ICT professionals who are responsible for an application and want to offer it as open source or contribute to such an application. - -This must be organised either formally or informally. - -This document provides important information for organising and building a community[^5] and also for open development directly as an open source project. - -As a second element, to promote standardisation, a directory of existing community concepts is maintained as part of this document. The idea is that new communities can be built with minimum effort based on successful solutions. - -This document does not include direct recommendations for organising communities for software libraries (parts of software that fulfil partial functions, e.g. PDF generation). Normally, no separate concept is developed for these; instead, they use the simple template defined in the repository\'s storage template. - -The document [Em002-01 Practical Guidelines for Open Source Software in the Federal Administration](./em002-1.md) contains in Section 4 fundamental forms of collaboration, in Section 8 the various support models, and in the Annex information on market behaviour of open source. - -# Type, aim and purpose of a community - -A community can pursue the following purposes: - -- Survey of additional requirements - -- Dissemination of knowledge about the application - -- Better feedback from users - -- Promoting translations, documentation and training - -- Spreading standardisation - -- Generally improved interaction with users - -- Expansion of cooperation to include other parties - -- Promotion of further software based on the software - -The type of community best suited for an application depends heavily on the professional environment, potential users, and the strategy of the publishing institution. There are many different ways to build communities. Ideally, for a suitable project, it may be possible to join an existing community. Alternatively, a community can be built with one or more equal partners. - -It is important that a **governance structure** should be established and the relevant points documented in a **community concept** (see also *\[BITKOM2023\]* Section 4.1 and *\[IZqCab2023\]*. - -It should be noted that communities for software can also be combined with those for data, standardisation and business topics. The community can then encompass processes, standardisation, software and data. Existing frameworks such as eOperations, DVS and eCH can also be used where appropriate. - -An important aspect of a functioning community is that participants receive more than they invest. - -The following constellations exist: - -- **Community around a federal OSS**: Governance and community concept must be created. In this context, it is also necessary to regulate how third parties can make contributions. - -- **New collaboration to solve a problem**: In addition to governance and the community concept, the entire legal structure of the collaboration must be established. - -- **Joining a collaboration**: The Federal Administration must examine whether and how it can do this. - -- **Contribution to a third-party project**: The point to be checked is the project\'s policy for contribution (Contributor Licence Agreement, Developer Certificate of Origin, etc.). - -Procurement law issues are dealt with in [Em002-7 Strategic Aspects of Procurement and Open Source Software](em002-7.md). - -## Special case: New collaboration for the development, maintenance and support of open source software - -The collective costs of open source software decrease when it is developed and further maintained collaboratively. This can occur without formal cooperation arrangements, or with no more than joint planning. - -Where a more formal collaboration is sought, a market assessment should be carried out to ensure that collaboration is the most appropriate form of cooperation. Collaborations are more cost-effective than individual development by each party (see [Em002-4.1](./Em002-4.1%20Checklist%20OSS%20Community.odt)). - -It should be noted that, for collaborations, it makes sense to initiate the collaboration at a very early stage in the HERMES[^6] project methodology --- specifically during the situation analysis and -requirements phases. - -Collaboration is generally permitted in Switzerland under Article 4 EMOTA. - -In addition to all other considerations, collaborations have both a legal and a procurement law dimension. At present, each case is assessed individually. Over time, standardised templates will become established. - -### Legal dimension - -Association memberships are feasible, though these are generally assessed on a case-by-case basis: who is behind the association, and what obligations are being entered into. -Delegation of memberships to eOperations or similar organisations would be possible. - -As long as no money changes hands and no formal obligations need to be entered into, a Memorandum of Understanding at the level of the federal office or the Federal Chancellery is possible. - -A situation requiring the conclusion of an international treaty should be avoided. - -There are also two special cases[^7] in which a collaboration would already be covered: - -- Contracts awarded under an international agreement concerning the joint implementation of a project by signatory states. - -- Contracts awarded in accordance with the special procedures or conditions of an international organisation. - -### Procurement law dimension - -In many cases, collaboration will take place between public sector organisations. In such cases, procurement is unproblematic where the arrangement is \'in-state\' (see [Em002-7 Strategic Aspects of Procurement and Open Source Software](em002-7.md)). - -Contracts with foreign companies not domiciled in Switzerland are possible, provided procurement law requirements are met. - -The procurement of an organisation\'s own resources takes place within the framework of a standard procurement process, or has already been completed. - -## Special case: Joining an existing collaboration - -This requires both a legal basis and compliance with procurement law. - -The simplest approach is to participate on a \'each party bears its own costs\' basis. This can also cover overhead costs, provided that either internal resources or correctly tendered external resources are used. - -Direct participation in foreign collaborations is more difficult. A simple association via a Memorandum of Understanding is the easiest option to achieve. - -## Special case: Contributing code to third-party OSS projects - -Where the Federal Administration makes modifications to the code of an existing OSS project, it makes sense to contribute these changes directly upstream to the original project. This means that ongoing maintenance no longer needs to be carried out by the Federal Administration. - -Under Article 9 EMOTA, such contributions are in fact encouraged. From a procurement law perspective, this is unproblematic. - -It is important that the rights holder makes the contribution. This means that the Federal Administration assumes responsibility for doing so on behalf of its staff and contractors. Specifically, any Contributor Licence Agreement for the project must be signed, or a Developer Certificate of Origin must be included with the pull request. - -A **Developer Certificate of Origin**[^8] **(DCO)** for the Federal Administration could read: - - - - - -
- Developer Certificate of Origin -Version 1.1 - -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. - -Everyone is permitted to copy and distribute verbatim copies of this licence document, but changing it is not allowed. - -Developer's Certificate of Origin 1.1 - -By making a contribution to this project, we certify that: - -(a) The rights to this contribution are owned by the Swiss Confederation and I am authorised to submit it under the open source licence indicated in the file; or - -(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source licence and I have the right under that licence to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different licence), as indicated in the file; or - -(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. - -(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source licence(s) involved. -
- -The structure of a Contributor Licence Agreement is described in [Em002-3 OSS Licensing Guidelines](em002-3.md), Section 8.9. - -The effective transfer of code takes place in accordance with the guidelines of the respective project. - -# Community concept - -A community\'s core is ultimately its structure and governance. These are recorded in a community concept. - -The community concept to be created by the project or application manager (or commissioned from third parties) should follow this section structure. Depending on the nature of specific community, not all sub-sections are necessary. Ideally, many sections will refer to already standardised documents or use standard processes of the corresponding repositories. The community concept can also be applied to existing projects led by others, especially if the effective governance is not yet documented in writing. - -By formalising the community, all participants are brought together and the onboarding of new participants is simplified. - -Structural draft of a community concept: - -1. Overview table - (name, repository, contact address, licence, depth of support, existing/new) - -2. Objectives - - a. of the application - - b. of the community - -3. Organisation - - a. Owner of the code - - b. Organisational form / committees - - c. Voting rights - - d. Project management - - e. Procurement issues (if applicable) - - f. Other governance aspects - -4. Roadmap and change process - -5. Development process - - a. Open development - - b. Committer rights - - c. Review process - - d. Task distribution and name citations - - e. Backups - -6. Financing of the community - -7. Marketing - -8. Handling external contributions - - a. Handling reported errors - - b. Handling enquiries - - c. Handling pull requests - - d. Handling forks - - e. CLA, DCO and assignment of rights/intellectual property - -9. Operation of the application - -In principle, each federal authority is responsible for creating the community concepts. DTI can publish existing patterns/examples and accepts corresponding examples for publication. -It also makes sense for community managers to exchange information with each other. - -A possible source for parts is also the documentation of the Eclipse Foundation,[^9] although appropriate tailoring should be carried out here in the sense of \'only doing what is necessary\'. - -# Fundamental decisions when building a community - -The principles of the community, or lack thereof, are determined using [Em002-4.1](./Em002-4.1%20Checklist%20OSS%20Community.odt). The relevant fundamental questions can be found in the morphological box in Figure 1. - -![](./assets/em002-4/media/image1.png) - -Figure 1 Morphological box OSS community - -It is advisable to **focus primarily on the near future** when designing the community; for example, if there are not yet any concrete interested parties for the application, it usually makes little sense to define a community with a simple company, its own association and complex processes for developing the roadmap.[^10] [^11] - -## Product management - -Depending on the type of application, its strategic importance and its status in the life cycle, there are different variants for mapping product management. -For organisations within federal authorities, this always concerns the application managers. The definition of the technical and technological roadmap and the release processes are particularly relevant for the community concept. - -Possibilities: - -a) **Organisations within the Confederation**: The Confederation wants to retain control; it alone defines the roadmap. - -b) **Joint organisation**: Together with other users or suppliers. - -c) **Open organisation**: Loose connections, no active roadmap. - -d) **Third parties**: Either the product already exists or the work is to be outsourced. - -### Organisations within the Confederation: - -If the application is of high strategic importance or the Confederation depends on being able to implement its changes quickly, then it can make sense to retain control. - -The federal authority alone decides, through the requirements manager, what is incorporated in the software and when. - -For potential other users of the application, this means that they are practically forced to use their own version (fork) of the application. - -Otherwise, they have hardly any opportunity to implement adjustments and extensions that may be important to them. This does not argue against publishing as open source: the code management tools[^12] offer extensive support for such scenarios, and adjustments and error corrections can be selectively adopted in both directions. - -Sharing the costs is typically difficult with this model. - -### Joint (Confederation has the lead or equal partners) - -Decisions regarding the roadmap and priorities should be coordinated and made jointly with the other members of the community. The Confederation participates as a member of the community but is not the lead organisation. - -For joint decision-making to work, structures and rules must be determined in advance. This also defines how the costs for implementing the jointly decided adjustments are divided among each other. - -With this model, a single version of the application is created, which is then used by all members. As a result, the total costs are significantly lower compared to the other variants. However, the flexibility of individual users is also lower, and they must coordinate their adjustment requests in advance with all others. Decision-making is slower and more time-consuming. - -This model is best suited for applications that are to be further developed jointly with clearly defined other organisations (e.g. cantons). - -### Open organisation - -In this model, the processes and structures are only loosely defined. The Confederation formally retains control but is open to contributions and adjustments. - -No roadmap or only a very rough one is defined; consensus is reached informally and in discussions directly on the publication platform. The community itself tends to be dynamic; members can be very active for a while and then withdraw again. - -This model is also suitable for smaller applications that are already in productive use and are \'finished\'. -This is also usually the best form for technically orientated applications or components that potentially appeal to a broader target group which cannot be precisely defined in advance. - -### Third party - -In this model, the processes and structures are defined by a third party and the federal authority is a member of the community but does not have the lead. This may have happened because, for example, the project was defined by another state or canton. Or it may be that the Confederation is not interested in continuing the program itself and transfer this task. - -## Integration of suppliers - -There are basically the following possibilities for integrating suppliers: - -a) **Supplier as contractor**: They are generally considered replaceable in the medium term. The supplier should develop the application cost-effectively and to a high quality based on orders from product management (or the community), but has at most advisory influence on the roadmap and prioritisation. - -b) **Long-term partners with co-determination**: They should be able to actively co-determine the development. This strengthens their role and they are potentially willing to invest in the application themselves. Typically, in this model, the suppliers then distribute the software and actively look for new customers. - -c) **Independent:** The suppliers define for themselves whether and how they want to work on the project. This can occur, for example, if several suppliers want to generate their own business based on the software. Liberal licences can potentially promote this. It can also occur if the Confederation\'s strategy differs from that of the supplier. -In this scenario, it is likely that the supplier will create a fork. - -d) **Lead**: If the supplier takes over product management, then they have the lead. The development is then determined by them. On the other hand, this can also mean that the Federal Administration has to take very little responsibility. With a minimum release, it is possible for the supplier to take on this role on their own. - -If the supplier takes on a strong role, this brings advantages for the Federal Administration: by actively marketing the application, there is a chance that the community will grow faster and stronger, thus reducing the costs per member more quickly. - -If a model with strong supplier co-determination is chosen, care must be taken that this does not result in a deviation from procurement law regulations. It is usually advisable to involve at least two suppliers to avoid creating too strong a dependency on a single supplier. There should also be the possibility for other suppliers to join the community. - -## Cost distribution - -The following options are available for splitting the costs of maintenance, further development and new functions: - -a) **Organisations within the Confederation***:* Especially when building ecosystems or if the federal authority will retain full control, the federal authority must also bear the costs. - -b) **Each their own**: Everyone pays for the changes they want themselves. - If necessary, it is decided on a case-by-case basis to pay for certain extensions jointly. - Recurring costs are billed according to a distribution key or on demand. - -c) **Originator pays principle**: Those who actually need the services or features pay for them. Standardised hourly rates may be applied. - -d) **Distribution key**: The costs are divided within the community according to a defined key. This only differs for specific expansions. These should be paid for directly by the users concerned. - The cost divider can be, for example, the size of the canton concerned or the number of users. Regarding the distribution key, see also Section **Fehler! Verweisquelle konnte nicht gefunden werden.**. - -e) **Contribution**: If the federal authority only contributes personnel to an existing project. - -Basically, variant b (cost sharing) usually only makes sense if there is also joint product management as in variant b (joint). Only those who can have a say will be willing to bear the follow-up costs of the decisions. - -## Support - -Within the cost distribution and effort, it is important to clarify who provides what support. According to Art. 9 EMOTA, a pure minimum release is possible. This variant may not deliver the desired effect and does not in itself build a community in which the federal authority has influence. - -a) **Minimum release**: No support (i.e. release generally occurs without organised support and participation of the federal authority). - -b) **Support by the Confederation**: The federal authority (or its service provider) provides defined support. - -c) **Support by third parties**: The federal authority or the community defines a support organisation. - -The effect to be achieved, e.g. on the Swiss ecosystem or initial funding of a community, can lead to the Confederation providing support.The level of support must of course be defined. In principle, a fee may also be charged. Due to the mechanisms of the Confederation, service providers or suppliers are then more likely to be able to offer commercial support. - -Offices may offer paid support in accordance with EMOTA (possibly also via service providers and third parties). To do this, they must publish the corresponding fees on their website, as the necessary legal basis is in place. The connection to the payment system can be discussed with the FDF. - -Examples of support and fees can be found in Annex G. - -## Development - -The basic methodology of development can also have an influence on the type of community. - -a) **Internal**: The use of internal repositories means that third parties cannot work directly. The stricter the separation, the more integration effort the Confederation has to make if it wants to incorporate third-party extensions. The release process is also more complex. - -b) **Third parties**: Either a supplier works on their own or the product already started/led by a third party is developed according to defined rules. - -c) **Open**: Software development takes place directly in a public repository. - The release according to EMOTA is therefore largely guaranteed. The expenses are to be paid during development. In this scenario, collaboration with third parties can also take place earlier (and more easily). - -# Detailed content for the community concept - -This section provides guidance on writing the community concept based on the fundamental decisions made (as per Section 5). - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- open - - Partner - - Federal government - - Contents or suggestions, if the basic decisions are:
-Product management c) Open organisation
-Supplier involvement: b) Supplier as partner
-Cost distribution: b) Each their own
-The text above can be copied into the template and adapted. -
- Joint - - - - - Each their own - - Contents or suggestions, if the basic decisions are:
-Product management b) Joint development
-Supplier involvement: a) or b) (not relevant)
-Cost distribution: c) Originator pays principle or d) Cost sharing -
- Joint - - - - - Originator - -
- -The community concept should be a dynamic document that can be adapted in consultation with the community. The concept should reflect the current situation and propose future development options. If more members join the community later, the organisation and processes can be further elaborated, and more complex mechanisms can be introduced. The following sub-sections directly follow the proposed structure of the community concept (see Section 4). - -If product management lies with third parties, they will define the concepts for the community. - -## Key information - -The following key information should be drawn up and published for each community so that potential interested parties can register for the software and the community: -- Software name - -- Repository - -- Owner - -- Responsible organisational unit/office - -- Contact address - -- Licence used - -- Support level - -- Existing project - -This information can all be displayed with publiccode.yml.[^13] - -## Objectives - -The objective should contain the actual purpose or \'vision\' of the application. This vision should also be included in the **README.md** file in the repository (see [Em002-2.2 Analysis and Preparation Checklist](./Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt)). - -At the same time, it should also describe what the community is aiming for: - -- Who should join? - -- Who are the potential interested parties? - -- Should new members be actively sought? - -- What are the main goals pursued by publishing as open source? - -## Organisation and governance - -In principle, for new developments, the aim is for the Confederation to be the owner of the master rights to the source code. - -The type of project management depends on which organisation had the lead (SAFe, HERMES) in the case of the Confederation. The organisational form should always seek minimum overhead (existing rather than new; simple partnership rather than an association). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - - - - Internal - - As the Confederation retains direct control, no additional organisational structures are necessary.
-The publishing entity (e.g. a federal office) retains ownership and assumes all coordination tasks. In this case, the 'Organisation' section can be kept very brief. -
- Joint - - - - - Internal - - For this scenario, organisation as a simple partnership is usually recommended.
-To enable joint development and coordination of the roadmap and requirements, it is advisable to create two groups, each with one participant per community member:
-
    - • Management Board: Defines the strategy and prioritisation. -
-
    - • Expert group: Develops requirements and specific content at the expert level. Depending on the scope, a separate expert group can also be established for each topic. -
- -The owner of the code is the office that published it. - -If the structures become more complex or more than five users or additional members are involved, it may be worth considering whether the community should be better organised as an association. Compare the explanations in the variant directly below. -
- Joint - - - - - Third party - - Organisation as an association is recommended.
Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association.

- -The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers. -
- Joint - - Contractor - - Internal - - Organisation as an association is recommended. Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association.

-The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers.
-Here, the suppliers are not members of the association, but only contractors. The manager should not be appointed by a supplier. -
- Joint - - Contractor - - Third party - - Organisation as an association is recommended. Either a separate association is founded specifically for the application, or the application is transferred to an existing association. An association is recommended because otherwise, the distribution of costs becomes complex, and there is likely to be enough work within the coordination tasks to employ a part-time manager for the association.
-The rights to the code are then transferred to the association, which takes over community management and ordering from suppliers.
-The suppliers are members of the association; the manager can also be provided by a supplier. -
- open - - - - - Internal - - There is no need for a detailed description of an organisation, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). -It should also be determined whether and to what extent external persons can be involved: -
    - • No direct integration: External parties can only submit suggestions and contributions (as pull requests). -
-
    - • Involvement as contributors: External parties who make frequent and good contributions are directly involved. -
-
    - • Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. -
- -The publishing organisation retains ownership. -This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information. -
- open - - Contractor - - Internal - - There is no need for a detailed description of an organisation, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). -It should also be determined whether and to what extent external persons can be involved: -
    - • No direct integration: External parties can only submit suggestions and contributions (as pull requests). -
-
    - • Involvement as contributors: External parties who make frequent and good contributions are directly involved. -
-
    - • Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. -
-The publishing organisation retains ownership.
-This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information.
-The supplier should only take on purely technical coordination tasks (code review, assessment). -
- Third party - - Partner - - Internal - - There is no need for a detailed description of an organisation, as it is deliberately designed to be open. However, it is important to establish who receives and processes external enquiries (responsibility). -It should also be determined whether and to what extent external persons can be involved: -
    - • No direct integration: External parties can only submit suggestions and contributions (as pull requests). -
-
    - • Involvement as contributors: External parties who make frequent and good contributions are directly involved. -
-
    - • Handover to external parties possible: If, after publication, external parties contribute more to further development than the publishing organisation, the application can also be transferred to them. -
- -The publishing organisation retains ownership. - This variant corresponds to the organisation of 'classic' open source projects; see for example https://opensource.guide/leadership-and-governance/ for further information. -
- - -With regard to governance, *\[BITKOM2023\]* Section 4.1, *\[IzCab2023\]* or can also be consulted. - -Examples of articles of association can be found in Annex E. - -NB: As the release must be guaranteed in accordance with Art. 9 EMOTA, the Federal Administration must ensure that the publication cannot be suddenly withdrawn (see the \'Open Source in Procurement Guidelines -- Software purchasing under Art. 9 EMOTA\' *\[BBL-WL\]*, paragraph V.2). - -## Roadmap and change process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - Contractor - - - - - The federal authority defines the roadmap and decides which changes will be implemented. The standard processes of the office XY are used for this. -
- Federal government - - Partner - - - - - The federal authority defines the roadmap in collaboration with company XY. It decides which changes will be implemented. The standard processes of the office XY are used for this. -
- Joint - - - - - Internal - - The process for developing the roadmap and approving changes must be determined by the members of the company or association. Depending on the member structure (number, size ratio, etc.), other processes may be appropriate.
-However, the processes must include measures for conflict resolution and finding a majority. -
- Joint - - - - - Third party - - The process for developing the roadmap and approving changes must be determined by the members of the company or association. Depending on the member structure (number, size ratio, etc.), other processes may be appropriate. - -However, the processes must include measures for conflict resolution and finding a majority. - -With the addition that a cost distribution key must also be established. Consideration should also be given as to how to handle cost sharing for adjustments not desired by the relevant members. Especially in associations with members of unequal size, situations may arise where a large member (e.g. the federal authority) bears a significant portion of the costs for an extension without deriving any benefit from it. -
- open - - - - - - - - Example, not suitable for all situations -There is no need to create a roadmap; the application currently meets the needs. - -Changes are decided upon in an open discussion and a consensus is sought. The final decision lies with the owner of the code (Swiss Confederation). -
- -## Development process - -If open development comes into play, it should be defined here. Task distribution and naming of central positions in the community concept are important. Also, how the security of the repository content is ensured. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - - - - - - - The committer rights (write access to the code) lie with the persons/entities/suppliers selected by the Confederation. After the contract expires, the respective rights are revoked. - -The service providers and suppliers are responsible for conducting the technical code review process for external contributions that have been technically accepted by the Confederation. They are responsible for the technical quality. The suppliers are compensated for this work by the Confederation. -
- Joint - - Contractor - - Internal - - In principle, all entities commissioned by a community member receive write access to the code (committer rights). After the contract expires, the respective rights are revoked. - -Where changed code affects core areas of the application, all changes must be reviewed by an entity specially commissioned by the community for this purpose. This entity is responsible for the technical quality of the application. It is also responsible for reviewing changes that have been technically accepted by the community. -
- Joint - - Partner - - Third party - - The committer rights (write access to the code) lie with the members of the community. These persons organise themselves and jointly bear responsibility for the quality of the code. - -If a community member commissions an external supplier for an adjustment or extension, the adjustment is reviewed by a member of the community. They are compensated for this by the client. - -Changes to the core of the application must be reviewed by a second member of the community. - -The suppliers who are community members are also responsible for reviewing external contributions and new technical code that has been technically accepted by the association. -
- open - - - - - - - - Initially, the committer rights lie with the developers or their employers. Committer rights are granted to all developers who actively contribute to the project for several months and demonstrate appropriate social competence. - -The individual developers generally retain their committer rights, even if they change their employer or the Confederation chooses a different supplier. Committer rights only expire if they are voluntarily relinquished or if the majority of other committers decide to revoke them. - -The Confederation has the right to designate individual developers from the companies it commissions as committers. It does not have the right to revoke someone's committer rights without reason. - -Code reviews are carried out by at least one person who acts as a committer. Committers organise themselves. - -The Confederation undertakes to compensate the review work as far as it is financially feasible for them. -
- -## Cost sharing and suppliers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - Contractor - - Internal - - Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). -
- Federal government - - Partner - - - - - Important: Check beforehand whether this is permissible under procurement law in the specific case. - -We will make additions to the documentation on this point. -The Confederation chooses the supplier XXX as a strategic partner and aims for long-term cooperation. -
- Joint - - Contractor - - Internal - - Each member of the community independently commissions one or more software suppliers to implement the adjustments and extensions they require. -Cost sharing is agreed on a case-by-case basis for adjustments requested by several members. The member with the largest share of the costs is responsible for selecting and commissioning the supplier. -(Regulations for software maintenance) -
- Joint - - Contractor - - Third party - - The association centrally selects the software suppliers periodically through WTO tenders or direct award procedures (depending on the scope of maintenance services). -The costs are allocated to the members according to a key: (to be defined: by population, user, etc.) -
- Joint - - Partner - - Internal - - Each member of the community independently commissions one or more software suppliers to implement the adjustments and extensions they require. -Cost sharing is agreed on a case-by-case basis for adjustments requested by several members. The member with the largest share of the costs is responsible for selecting and commissioning the supplier. - -(Regulations for software maintenance) -If necessary, supplemented by a contribution from the participating suppliers. Example: - Each software development company that is a member of the community commits to investing at least XY working days per year at its own expense in the further development, technological updating, or marketing of the application. -
- Joint - - Partner - - Third party - - The association centrally selects the software suppliers periodically through WTO tenders or direct award procedures (depending on the scope of maintenance services). -The costs are allocated to the members according to a key: (to be defined: by population, user, etc.) -If necessary, supplemented by the addition: - Each software development company that is a member of the community commits to investing at least XY working days per year at its own expense in the further development, technological updating, or marketing of the application. - -
- Third party - - Contractor - - - - - Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). -With the addition: - The improvements contributed by potential suppliers and activities in the community are considered as a factor in the evaluation. - -Changes requested by external parties are not financed by the Confederation, but must be commissioned and paid for by the parties themselves. -
- Third party - - Partner - - - - - Suppliers are periodically selected through WTO tenders or a direct award procedure (depending on the scope of the maintenance services). -With the addition: - The improvements contributed by potential suppliers and activities in the community are considered as a factor in the evaluation. -Changes requested by external parties are not financed by the Confederation, but must be commissioned and paid for by the parties themselves. - -
- -## Marketing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - Contractor - - - - - The Confederation does not actively market the application but publishes it on open-source software platforms. The publication of the application is announced in professional committees. -If interested parties come forward, we will consider whether to establish a joint community or continue working with their version of the software. -
- Joint - - Partner - - - - - Additionally:
-Suppliers may market the application and seek further interested parties. The Confederation may be cited as a reference. We consciously accept that divergent versions of the software may emerge as a result. -
- Joint - - Contractor - - Internal - - The application is marketed by the members or the association. -
- Joint - - Partner - - Internal - - The application is marketed by suppliers. -
- Joint - - - - - Third party - - The application is marketed by the association, the simple partnership and its members. -
- open - - - - - - - - The application may be marketed by suppliers, or explicit marketing may be foregone. -Alternative without explicit marketing: -The Confederation does not actively market the application but publishes it on open-source software platforms. In professional committees, we indicate that we have published the application and that collaboration is welcome. -We demonstrate the software to interested parties and attempt to integrate them into our processes for shaping the roadmap. -
- -## Handling external contributions - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Federal government - - Contractor - - - - - External contributions and enquiries must also be processed even if the Confederation remains the sole decision-maker regarding the software (except in cases of minimum release, where a fork is inevitable). -We propose the following approach: - -Handling reported errors -We attempt to reproduce errors reported by external individuals, requesting clarification if necessary. If reproduction is successful, the Confederation commissions the correction of errors. -If the error cannot be verified or if the effort to fix it is disproportionately high, we apologise to the person reporting the error and ask if they could submit a pull request to address it. -Handling enquiries -We respond to every incoming enquiry. If an enquiry cannot be resolved with reasonable effort and further time investment seems inefficient, we apologise, citing limited resources, and offer to connect the enquiring person with a supplier for further consultation. -Handling pull requests -We review each pull request carefully. To avoid unnecessary effort on the contributor's part, we immediately indicate if something contradicts our roadmap or if it is questionable whether we will accept the contribution. The Confederation decides independently and based on technical criteria which contributions to accept. Error corrections that have passed the review process are always accepted. -Handling forks -We support forks of our application. Those who implement the application should create their own fork. We review the resulting forks at least once a year and adopt good and suitable extensions. -
- Joint - - - - - - - - External refers to contributions from outside the defined community (association members). Deviations from above:
-Handling forks
-We aim to prevent (long-lived) forks of the application. Instead, interested parties should join the community directly. Within the community, we try to ensure all members use the main version. -
- Open - - - - - - - - Building a functioning community and an open culture is important to us. - -Handling reported errors -We attempt to reproduce and correct reported errors. We require active cooperation from the reporting individuals. If possible, they should create a pull request with an error correction directly. -Handling enquiries -We address each enquiry within a maximum of one week. Enquiries from active contributors are treated with priority and in depth. We try to involve other members in handling enquiries. -Handling pull requests -We aim to receive as many high-quality pull requests as possible. We involve all active contributors in the reviews and technical and professional assessment of pull requests. For controversial contributions, we try to reach a decision through informal voting. -Handling forks -We try to make forks unnecessary through active and open community management. If forks do emerge, we actively review them and attempt to incorporate the extensions and improvements developed there. In such cases, we actively request pull requests. -
- -In general, it should be noted that contributions can range from supporting other users to taking responsibility for entire parts of a project (see *\[BITKOM2023\]* Section 4.2). - -## Operation of the application - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Product management - - Supplier as - - Development - - Proposal -
- Joint - - - - - - - - Central operation can optionally be offered additionally by the central association, in the sense of Software as a Service (SaaS). It should be examined whether this is desired. -
- - - - Partner - - - - - It should be specified whether the supplier should also operate the software. -
- - - - Lead - - - - - It should be stated that the supplier is responsible for operation. -
- - -Support levels and support contacts should also be specified in this section. - -# Important information for community managers - -## It takes time - -Building communities is something that should be planned for the long term. Perseverance and consistency are two important qualities needed for a successful community. - -## Further suggestions for community building - -Further suggestions for good community management can be found at https://opensource.guide/code-of-conduct/ and https://opensource.guide/best-practices/. - -## Communications - -Publishing software and documentation opens a new communication channel for the Federal Administration. If this is not done carefully and professionally, the public image of the Confederation can suffer. - -OSS communities in the Federal Administration are faced with conflicting demands regarding communication: on the one hand, the general **guidelines for communication** apply; on the other hand, the community should facilitate **simple formal and informal collaboration** across organisational boundaries, preferably without formal quality controls and releases. - -The use of public repositories and potentially public issue tracking and wikis means that individual project staff members\' statements are visible to the public unfiltered. This requires project staff to maintain a professional demeanour and adhere to quality standards for publications in such settings. - -In OSS projects, this is normally regulated through the **Code of Conduct**. The Federal Administration\'s own Code of Conduct[^14] is very general, but the core principle is applicable here: -\"Staff carry out their duties with a sense of responsibility, integrity and loyalty. In their private lives they also take care not to tarnish the reputation, the credibility and the image of the Confederation\" - -## Open development - -If software development is planned in an open repository from the start, release happens automatically. The relevant checklists according to the instructions [Em002-2](em002-2.md) must be completed at the beginning, and the development processes of the service provider/supplier must allow this. The advantage is that the community can be built from the very beginning. Multiple organisations can also collaborate on the development. - -Closed repositories are an intermediate form, but are used for other partners in a collaboration. - -## User management - -The project (or the support organisation) determines whether developers and other project staff work on the project under their own name or anonymously. If people are not working anonymously and already have logins on the platforms, it is easiest to use these (whether business or private). - -The platform should generally allow the inclusion of third parties, as otherwise no developers from outside the Confederation will be able to collaborate. - -When leaving the project, the corresponding rights on the project must be deleted. Product management is responsible for this. - -## Merging communities - -Where possible, the number of communities should be kept small. This means: - -- If a community already exists where a similar structure is envisaged for similar problems involving the same people, a single community should be used. - -- Multiple projects that are related and address the same target audience can be consolidated into one community. - -- No fundamentally different community structures should be created unnecessarily where existing ones are already in place. - -## Handling third-party contributions - -The contribution of software to other projects is addressed in Section 3.3. The same principles apply in reverse. - -The following points are important: - -- A suitable Contributor Licence Agreement must be used to ensure that the source code subsequently belongs to the Confederation (see also [Em002-3 OSS Licensing Guidelines](em002-3.md), section on Contributor Licence Agreements). This must be signed by the owner of the contribution. - -- Confirmations must be filed. - -- Contributions must be reviewed before being integrated into the codebase. - -- Submissions should be responded to in a timely manner (issues, requests, pull requests) and handled as constructively as possible. - -- All channels and governance arrangements should be listed in the community concept, on the website and in the repository. - -## Security-relevant reports - -In addition to standard bug reports, provision must be made -- where the nature of the project requires it -- for security-related vulnerabilities to be reported confidentially, as is the case with a bug bounty programme, for example. - -The documents from trustbroker.swiss can serve as an example: - -- - -## Avoiding forks - -While forks are natural in the open source world, reintegrating source code, features and so on from forks is far from straightforward. It may be worth reaching out to the individuals or organisations considering a fork and trying to keep them engaged with the main project. Striking a balance between competing interests is often necessary in such cases. - -## Cost allocation - -It makes sense to agree on general distribution keys between the main partners. These can be adjusted every few years or when the situation fundamentally changes. For efficient work on the software, the large partners should tend to take on slightly larger shares than they actually have to (if necessary, also the overall coordination). The organisation should work and not argue about finances. If the collaboration covers several projects (for example, the industry solutions in the field of standard gauge railways), a standardised distribution key should be used for all projects. -From the perspective of federal authorities, it is an improvement if the costs do not have to be borne alone. - -Possible criteria for distribution keys: - -- Estimation of benefit distribution (e.g. between federal authority and a supplier hoping for other customers) - -- Number of inhabitants/users (e.g. between offices, communes, cities) - -- Financial strength (e.g. cantons) - -- Gross national product (e.g. between cantons) - -- Who wants more control - -To avoid discussions, the distribution key should not simply be attached to the annual budget. A clause along the lines of the originator pays principle may allow faster adjustments for some partners if they are willing to pay extra. - -The distribution key should also apply to overheads, maintenance/support, and a minimum of further development. These parts should be solved in the long term if possible. - -It should be borne in mind that when third-party funding is involved, those parties will typically want a greater say. Community management needs to be equipped to handle this. - -## Supplementary services according to Art. 9 paras 5 and 6 EMOTA - -The federal authorities can (themselves, through service providers or suppliers) provide supplementary services, particularly for integration, maintenance, ensuring information security, and support. - -The limitation is that they should serve the authorities\' tasks and can be provided with proportionate effort. - -It follows that the federal authority cannot be the development company for third parties. It fixes bugs, can handle security-relevant aspects, can provide some support and integration assistance (all activities that help to build a community). New developments and additional features for third parties should primarily focus on the normal work purpose of the authority. Of course, it may be that providing the software is part of the task, in which case developments can be made at any time. It is also stated that software development is not the core task of the federal authority. - -This means that if features are substantially developed exclusively for third parties, they are to be integrated in partnership or through the supplier. - -To avoid procurement law problems, care should be taken in procuring software and services to ensure that features can be provided to third parties (possibly only governmental third parties) by suppliers. - -The setting of fees has already been touched upon in the \'Support\' section. EMOTA is already the legal basis for such fees. These must be communicated on the website of the respective federal authority. Examples are listed in Annex G. - -Art. 9 para. 6 states that normally the private sector should not be competed with. This means that the fees should not be set too low and should at least cover costs. In case of doubt, it is better to set hourly rates too high rather than too low. - -Generally, it is recommended to work with one to three different standard hourly rates. - -If a federal department wishes to define exceptions to para. 6, this must not compete with the private sector. Under certain circumstances, it may be easiest to set the fees and increase them if there is opposition from private sector companies that can actually offer the service. - -## Digital sovereignty - -As long as the Confederation does not have its own repository, to ensure digital sovereignty, it is recommended to regularly make copies from public repositories. - -It should be noted that not only the source code but also other information such as issue tracking, wiki, configurations, etc. is copied. - -Furthermore, user management needs to be resolved to ensure control over the published source code. The overarching goal is to ensure development independent of the respective platform and to enable the community to switch.[^15] - -# Annex - -## Changes from previous version - -- Section 1 \'Main points at a glance\' added - -- Community purpose added to Section 3 - -- Sections 3.1 to 3.3 on Collaboration added - -- New Section 7.7 Handling third-party contributions - -- Noted that suppliers should not publish entirely on their own (in accordance with *\[BBL-WL\]*, V.2) - -- Publicode.yml mentioned - -- Alignment with new [Em002-7](./em002-7.md) - -- Further editorial changes and improvements - -## References - -See *Em002 Strategic Guidelines for Open Source Software in the Federal Administration*. - -## Abbreviations - -See [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](./em002.md) and [Em002-6 FAQ about OSS](./em002-6.md). - -## Examples of existing community concepts - -In the spirit of collecting best practices, the following are community concepts and comparable documents that have already been developed. These are not necessarily just concepts from federal authorities, but also from other organisations. - -- GERES Community ([[http://geres-community.ch]{.underline}](http://geres-community.ch)) - - Classification: - -- Product management a) Joint development - -- Supplier rather a) Contractor - -- Cost distribution: b) Cost sharing - - NB: The commune register GERES is not open source, but many aspects of the organisation can also be relevant for open source applications. - Documents: Statutes (public) and Rules of Procedure (on request). - -- [iGov Portal](https://www.igovportal.ch) - -[This section currently contains concepts from the Canton of Bern and will be supplemented as soon as federal examples are available.]{.mark} - -## Examples of collaborations - -The following examples illustrate how collaborations have been structured. - -## Collaboration: ZenDiS[^16] in Germany - -ZenDiS is an organisation whose aim is to reduce dependency in public administration (primarily in Germany) by promoting open source software. - -![](./assets/em002-4/media/image2.png) - -Figure 2: Goals and approaches to strengthening digital sovereignty (ZenDiS) - -ZenDiS works with strategic partners to this end. - -Cooperation between the Federal Administration and ZenDiS is therefore unlikely to be unrestricted, and coordination would not be binding. This may change in due course. - -In concrete terms, the Federal Administration would need to establish its own organisation for Switzerland and coordinate informally with ZenDiS. This could potentially be done via eOperations, though eOperations only becomes active when a specific requirement is raised and a budget is made available. A justification for such a parallel organisation could be found in the context of eGovernment or EMOTA. - -NB: ZenDiS is subject to EU/German procurement law. There are significant differences compared to Switzerland. ZenDiS therefore cannot be replicated on a one-to-one basis in Switzerland, and cooperation with ZenDiS is not straightforward. - -## Collaboration: Open Trip Planner (OTP) - -Open Trip Planner[^17] is an open source travel planning application. It is organised as a project of the Software Freedom Conservancy in New York. Individual developers are employed by transport companies and suppliers. A notable feature is that a public sector actor -- specifically ENTUR[^18] -- has taken on one of the leading roles. ENTUR develops primarily for its own needs but also has a collaborative focus, particularly for the Nordic countries. ENTUR is organised as a company owned by the Norwegian Ministry of Transport and Communications. As the largest actor, ENTUR also absorbs a significant share of the coordination costs. Anyone can submit feature requests; these are discussed in coordination meetings and developed if someone funds them. Funding is provided primarily on a per-feature basis by the interested party or parties. In essence, each party bears its own costs. Support services would also need to be put out to tender separately in Switzerland. - -## New collaboration initiated by the Confederation: Swiss Trust Broker[^19] - -The Trust Broker is a piece of Confederation software for eIAM, available as open source. Development is carried out by the Confederation. Several cantons have decided to deploy it either directly as SaaS or with their own instances. As it is available under the AGPL licence, any extensions made will benefit the Confederation in turn. Given its security-critical nature, development for the Federal Administration is carried out exclusively by the Confederation. Other -organisations may submit requirements, which will be implemented if the project team considers them appropriate. - -## New collaboration initiated by the cantons: inosca {#e.4-new-collaboration-initiated-by-the-cantons-inosca .unnumbered} - -Through inosca,[^20] a number of cantons have established a development community focused on electronic permits, originating with the eBau project.[^21] -eBau also includes Caluma,[^22] a framework for collaborative editing -- an example of a component extracted from a broader solution and developed into a standalone, widely applicable framework. This can also be used in other projects, even where some parts are subject to exception conditions, thereby allowing the maximum number of other bodies to benefit from the code. - -The community meets at least once a month (optionally twice) to exchange views on technical topics and plan the shared roadmap. All participants may raise topics. Where a topic is deemed relevant to the community, interested cantons come forward and organise themselves into a working group. Outcomes are feedback continuously to the community. inosca operates on a fundamental principle: those who design, fund. That is, all cantons participating in a working group share the cost of the new feature. The feature is put out to tender and costs are divided among the community according to a predefined cost-sharing formula. Once a feature is completed and deployed, it immediately becomes freely available to all other cantons. - -The community has additionally decided to set aside a modest fixed annual amount to cover the administrative costs of running the community. This budget is allocated each year to the parties taking on an organisational role. - -## SNOWPACK by WSL -- direct contributions from developers - -SNOWPACK[^23] is an open source project developed by WSL for modelling snowpack formation. It is a highly specialised model, and the community has accordingly been integrated into the existing specialist community. Some issues have already been earmarked as potential contributions. The working model here is that each party bears its own costs and contributes features. Coding style and release process guidelines are also documented in this context. - -## Inspiration for association statutes - -The statutes should be kept as simple as possible. - -The following statutes can serve as inspiration. - -- eCH: - -- Stop Piracy: - -[Further examples of statutes will be added as soon as they are available.]{.mark} - -## Examples of support and fees - -- Fees for statistical services: [https://www.fedlex.admin.ch/eli/cc/2003/326/de](https://www.fedlex.admin.ch/eli/cc/2003/326/en) - -- FDPIC fees: - -- Free services from IPI for courses in the field of intellectual property (not software, but as an example): - -Examples will be added as soon as they are available. - -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: The community of an open source project typically represents a - pyramid.\ - The foundation of this pyramid is the users of the software, - especially the committed ones who actively participate in the - community, for example in the form of bug reports and feature - requests or through contributions to mailing lists.\ - Directly above in the pyramid are contributors. These are parts of - the community that propose their own code contributions. They - typically do not have write access to the repository. Their - contributions are reviewed by maintainers of the project and - incorporated into the repository after reaching the project-typical - quality.\ - At the top of the pyramid are the maintainers or committers of a - project. In this role, a developer has a higher responsibility. This - is expressed, for example, in the ability to accept contributions. - This right is often manifested through write access to the - repository. At this level, control over the software, its quality, - and range of functions takes place. In more complex projects, this - level can be further subdivided. For example, the Linux kernel is - known to have subsystem maintainers at multiple levels, and - ultimately only a single developer, Linus Torvalds, incorporates the - patches into the project repository. Another example is projects of - the Eclipse Foundation, which typically have a project lead with - additional rights in the context of the Eclipse Foundation - development process, such as initiating the release process or - formal election of committers or project leads *\[BITKOM2023\]*. - -[^6]: - -[^7]: - -[^8]: - -[^9]: See - -[^10]: With an association (or foundation), a separate legal entity is - created to look after the software and the product. This only pays - off from a certain level of importance, complexity and the existence - of several (equal) partners. A roadmap is used to show the wider - public and potential additional users of the software what is - planned. - -[^11]: It may also be possible, especially for projects that involve - several state actors from the outset, to approach existing - foundations and see whether the projects and governance can be - managed under their umbrella, analogous to https://finos.org or - or https://www.eclipse.org/collaborations/ - or https://iot.eclipse.org or - https://outreach.eclipse.foundation/open-regulatory-compliance. - -[^12]: e.g. GitHub - -[^13]: - -[^14]: https://www.epa.admin.ch/dam/epa/fr/dokumente/aktuell/medienservice/120_verhaltenskodex_e.pdf.download.pdf/120_verhaltenskodex_e.pdf - -[^15]: See also - - -[^16]: [ZenDiS home page: Co-creating Digital - Sovereignty](https://www.zendis.de/en) - -[^17]: [OpenTripPlanner](https://www.opentripplanner.org/) - -[^18]: - -[^19]: [GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of - the trustbroker.swiss - service](https://github.com/trustbroker-swiss/trustbroker.swiss) - -[^20]: - -[^21]: - -[^22]: - -[^23]: diff --git a/docs/en/em002-5.adoc b/docs/en/em002-5.adoc new file mode 100644 index 0000000..945da98 --- /dev/null +++ b/docs/en/em002-5.adoc @@ -0,0 +1,327 @@ += Em002-5 EMOTA and OSS Factsheet +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +[IMPORTANT] +==== +This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. +==== + +''' + +== Information sheet: Application of OSS Article 9 EMOTA + +The new https://www.fedlex.admin.ch/eli/cc/2023/682/en#art_9[Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA)] came into force on 1 January 2024. It stipulates that federal authorities must publish the source code of software they develop or commission. Exceptions are made where third-party rights or security-relevant reasons preclude or restrict publication. + +image::./assets/em002-5/media/image1.png[Overview diagram of the OSS Article 9 EMOTA process,600] + +This document provides guidance for [.underline]#project managers# or other [.underline]#persons responsible for the procurement of software#. + +== Introductory questions: + +Does the federal authority procure or use standard software without customisation? +If yes, see a) + +or + +Does a software application or component have to be developed specifically for the federal government (customised software = make)? +If yes, see b) + +=== a) Procurement and use of standard software + +Where the Confederation purchases software without customisation, Article 9 EMOTA does not apply. Every federal authority is free to decide whether to procure and use open source or other software. +Assistance with the procurement of software can be found on the website of the https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Federal Office for Buildings and Logistics (FOBL)] and the https://perimap.admin.ch/goto_perimap_file_46835_download.html[Information sheet on software procurement and Art. 9 EMOTA] from the CCPP. If necessary, link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] can also be consulted. + +=== b) Creation or further development of software + +If a federal authority develops software itself or through third parties, OSS Article 9 EMOTA must be applied. This also includes software that is further developed as part of a contribution in existing OSS projects. Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. Please complete the link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist]. + +NOTE: This checklist also serves as a justification for why software [.underline]#does not# have to be published. It should therefore be consulted as early as possible in the project. The guide link:em002-2.adoc[Em002-2] describes the entire process. + +Further questions to be clarified are: + +=== Under which open source licence is it published? + +The fundamental question of whether the software is published under a [.underline]#copyleft# licence (in which case AGPL V3 is a good choice, for example) or [.underline]#permissively# (in which case under an MIT licence, for example) must be answered. With regard to licence selection, the link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] provides detailed information. Please complete the link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist]. + +NOTE: Ideally, this should be completed by the (technical) project manager or IT architect. + +=== Where and how should the software and associated artefacts be published? + +Please complete the link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] + +NOTE: This is a collective record of where and how software is published. It may be necessary to involve other organisations. + +=== Should an OSS community be established? + +link:em002-4.adoc[Em002-4 OSS Community Guidelines] describe the advantages and tasks involved in setting up an OSS community on the basis of a concept. + +[.underline]#If yes#: Fill in the link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] which provides information about the desired type and platform for the community. + +NOTE: The project team has a great deal of leeway here as to whether and what type of community should be created. It may be necessary to involve other units. + +Answer these questions and check regularly (approx. once a year) whether there have been any significant changes. + +Each federal authority (e.g. office, administrative unit) that develops or commissions software is independently responsible for the entire publication process. + +== Overview of tools and resources + +image::./assets/em002-5/media/image2.png[Overview of OSS tools and resources,600] + +The tools and resources are available on the Federal Chancellery website +under https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[OSS tools]. They are also https://github.com/swiss/opensource-guidelines/tree/main/docs/en[published in English on GitHub] where you can give feedback directly. The OSS Catalogue (opensource.admin.ch) provides an overview of software published by the federal authorities. For enquiries please contact: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. + +== Target groups of the various OSS tools + +The OSS tools and resources are aimed at different target groups. The following table provides a recommendation as to which documents are relevant for each target group. + +.OSS tools and resources by target group +[options="header",cols="3,1,1,1,1,1,1,1,1,1"] +|=== +|Document \ Target group |Management |IT management (a) |ISBO / DSBO (a) |Application Manager |Project Management |Legal Services |Procurement |Development |Communications + +|Em002 Strategic Guidelines +a|X + +3,4,5 +a|*X* + +2-5 + +Annex B, C +a|X + +2-5 + +Annex B, C +| +a|(X) + +5 + +Annex B +| +| +| +|(X) + +|Em002-1 Practical Guidelines +|X +|*X* +|*X* +|*X* +|X +| +| +| +| + +|Em002-2 Instructions for Publishing OSS +| +a|(X) + +1,3,5 +a|X + +1,3 5 +a|(X) + +1,3,5 +a|*(X)* + +3,5 +| +| +a|X + +1-5 +| + +|Em002-2.1 OSS Preliminary Assessment Checklist +| +a|*(X)* + +(c) +a|*X* + +(b), (c) +a|X + +(b) +a|X + +(b) +| +| +| +| + +|Em002-2.2 OSS Analysis and Preparation Checklist +| +| +a|*X* + +*(c)* +a|*X* + +*(c)* +a|*X* + +*(c)* +| +| +a|X + +(b) +| + +|Em002-2.3 OSS Release and Publication Checklist +| +| +a|*X* + +(c) +a|*X* + +(c) +| +| +| +a|X + +(b) +a|X + +(d) + +|Em002-3 OSS Licensing Guidelines +| +|*(X)* +|*(X)* +| +| +|*X* +a|(X) + +8 +|(X) +| + +|Em002-4 OSS Community Guidelines +a|(X) + +3 +a|X + +3,5 +a|X + +4,5 +|*X* +| +| +| +|(X) +|X + +|Em002-4.1 OSS Community Checklist +| +a|*(X)* + +(c) +a|*(X)* + +(c) +a|(X) + +(d) +a|X + +(b) +a|(X) + +(d) +| +| +a|(X) + +(d) + +|Em002-5 OSS Tools information sheet (e) +|X +|X +|X +|X +|X +|X +|X +|X +|X + +|Em002-6 FAQ about OSS (e) +|(X) +|(X) +|(X) +|X +| +|X +|(X) +|(X) +|(X) + +|Em002-7 Strategic Aspects of Procurement and OSS +| +|*(X)* +|*(X)* +| +|(X) +|X +|X +| +| + +|CCPP information sheet +|X +|*X* +|*X* +|X +|(X) +|X +|X +| +| + +|FOBL Guidelines +| +| +| +|*(X)* +|*(X)* +| +|X +| +| + +|FOBL Checklist for blanket exception +| +|*(X)* +| +|(X) +|(X) +| +|X +| +| +|=== + +Glossary: + +* X -- Target group, (X) -- If interested/needed, at least management summary +* (a) person responsible for Art. 9 EMOTA in the OU. Can be IT management or delegated +* (b) fill in +* (c) authorise +* (d) to consult +* (e) Primarily for information and reference +* Bold = Proposal of the responsible body in an OU (may be regulated differently) +* Numbers and capital letters: relevant sections and annexes. If none are specified, the entire document is relevant. +* Responsibility for the documents: FCh/DTI (yellow), CCPP and FOBL (blue) diff --git a/docs/en/em002-5.md b/docs/en/em002-5.md deleted file mode 100644 index b42757a..0000000 --- a/docs/en/em002-5.md +++ /dev/null @@ -1,343 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - - # Information sheet: Application of OSS Article 9 EMOTA - -The new [Federal Act on the Use of Electronic Means to Carry Out -Official Tasks (EMOTA)](https://www.fedlex.admin.ch/eli/cc/2023/682/en#art_9) came intov force on 1 January 2024. It stipulates that federal authorities must publish the source code of software they develop or commission. Exceptions are made where third-party rights or security-relevant reasons preclude or restrict publication. - -![](./assets/em002-5/media/image1.png) -This document provides guidance for project managers or other persons responsible for the procurement of software. - -# Introductory questions: - -Does the federal authority procure or use standard software without customisation? -If yes, see a) - -or - -Does a software application or component have to be developed specifically for the federal government (customised software = make)? -If yes, see b) - -## a) Procurement and use of standard software - -Where the Confederation purchases software without customisation, Article 9 EMOTA does not apply. Every federal authority is free to decide whether to procure and use open source or other software. -Assistance with the procurement of software can be found on the website of the [Federal Office for Buildings and Logistics (FOBL)](https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html) and the [Information sheet on software procurement and Art. 9 EMOTA](https://perimap.admin.ch/goto_perimap_file_46835_download.html) from the CCPP. If necessary, [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) can also be consulted. - -## b) Creation or further development of software - -If a federal authority develops software itself or through third parties, OSS Article 9 EMOTA must be applied. This also includes software that is further developed as part of a contribution in existing OSS projects. Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. Please complete the [Em002-2.1 OSS Preliminary Assessment Checklist](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt). - -**Note**: This checklist also serves as a justification for why software does not have to be published. It should therefore be consulted as early as possible in the project. The guide [Em002-2](em002-2.md) describes the entire process. - -Further questions to be clarified are: - -## Under which open source licence is it published? - -The fundamental question of whether the software is published under a copyleft licence (in which case AGPL V3 is a good choice, for example) or [permissively]{.underline} (in which case under an MIT licence, for example) must be answered. With regard to licence selection, the [Em002-3 OSS Licensing Guidelines](em002-3.md) provides detailed information. Please complete the [Em002-2.2 OSS Analysis and Preparation Checklist](Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt). - -**Note**: Ideally, this should be completed by the (technical) project manager or IT architect. - -## Where and how should the software and associated artefacts be published? - -Please complete the [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt) - -**Note**: This is a collective record of where and how software is published. It may be necessary to involve other organisations. - -## Should an OSS community be established? - -[Em002-4 OSS Community Guidelines](em002-4.md) describe the advantages and tasks involved in setting up an OSS community on the basis of a concept. - -If yes: Fill in the [Em002-4.1 OSS Community Checklist](Em002-4.1%20Checklist%20OSS%20Community.odt) which provides information about the desired type and platform for the community. - -**Note**: The project team has a great deal of leeway here as to whether and what type of community should be created. It may be necessary to involve other units. - -Answer these questions and check regularly (approx. once a year) whether there have been any significant changes. - -Each federal authority (e.g. office, administrative unit) that develops or commissions software is independently responsible for the entire publication process. - -# Overview of tools and resources - -![](./assets/em002-5/media/image2.png) - -The tools and resources are available on the Federal Chancellery website -under [OSS tools](https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html). They are also [published in English on GitHub](https://github.com/swiss/opensource-guidelines/tree/main/docs/en) where you can give feedback directly. The OSS Catalogue (opensource.admin.ch) provides an overview of software published by the federal authorities. For enquiries please contact: . - -# Target groups of the various OSS tools - -The OSS tools and resources are aimed at different target groups. The following table provides a recommendation as to which documents are relevant for each target group. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Document \ Target group - Management - - IT management (a) - - ISBO / DSBO (a) - - Application Manager - - Project Management - - Legal Services - - Procurement - - Development - - Communications -
Em002 Strategic Guidelines

X

-

3,4,5

X
-2-5
-Annex B, C		X
-2-5
-Annex B, C

(X)

-

5
-Annex B

(X)
Em002-1 Practical GuidelinesXXXXX
Em002-2 Instructions for Publishing OSS

(X)

-

1,3,5

X

-

1,3 5

(X)

-

1,3,5

(X)

-

3,5

X

-

1-5

Em002-2.1 OSS Preliminary Assessment Checklist

(X)

-

(c)

X

-

(b), (c)

X

-

(b)

X

-

(b)

Em002-2.2 OSS Analysis and Preparation Checklist

X

-

(c)

X

-

(c)

X

-

(c)

X

-

(b)

Em002-2.3 OSS Release and Publication Checklist

X

-

(c)

X

-

(c)

X

-

(b)

X

-

(d)

Em002-3 OSS Licensing Guidelines(X)(X)X

(X)

-

8

(X)
Em002-4 OSS Community Guidelines

(X)

-

3

X

-

3,5

X

-

4,5

X(X)X
Em002-4.1 OSS Community Checklist

(X)

-

(c)

(X)

-

(c)

(X)

-

(d)

X

-

(b)

(X)

-

(d)

(X)

-

(d)

Em002-5 OSS Tools information sheet (e)XXXXXXXXX
Em002-6 FAQ about OSS (e)(X)(X)(X)XX(X)(X)(X)
Em002-7 Strategic Aspects of Procurement and OSS(X)(X)(X)XX
CCPP information sheetXXXX(X)XX
FOBL Guidelines(X)(X)X
FOBL Checklist for blanket exception(X)(X)(X)X
- -Glossary: - -- X -- Target group, (X) -- If interested/needed, at least management - summary - -- \(a\) person responsible for Art. 9 EMOTA in the OU. Can be IT management or delegated - -- \(b\) fill in - -- \(c\) authorise - -- \(d\) to consult - -- \(e\) Primarily for information and reference - -- Bold = Proposal of the responsible body in an OU (may be regulated differently) - -- Numbers and capital letters: relevant sections and annexes. If none are specified, the entire document is relevant. - -- Responsibility for the documents: FCh/DTI (yellow), CCPP and FOBL (blue) diff --git a/docs/en/em002-6.adoc b/docs/en/em002-6.adoc new file mode 100644 index 0000000..69ada27 --- /dev/null +++ b/docs/en/em002-6.adoc @@ -0,0 +1,808 @@ += Em002-6 FAQ on OSS and Art. 9 EMOTA +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +== Background and purpose + +=== Background and purpose of the FAQs + +A number of questions frequently arise in connection with the tools available for publishing OSS. The following compilation answers the most common questions and aims to provide a better understanding of individual topics and aspects. + +=== Structure and organisation + +The FAQs are organised by subject, as follows: + +[start=2] +. Terms and definitions +. Roles and responsibilities +. Process +. Tools +. Legal matters +. General + +Each section is structured as follows: + +[cols="1,9",options="header"] +|=== +|Q |Question + +|A +|Answer +|=== + +== Terms and definitions + +=== Open source software + +[cols="1,9",options="header"] +|=== +|Q |*What is meant by open source software?* + +|A +|This is defined in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] +|=== + +=== Software and licences + +[cols="1,9",options="header"] +|=== +|Q |*What is meant by software?* + +|A +|This is defined in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. For licences, see link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*What is meant by licences?* + +|A +|Here we are referring to software licences. Further information can be found in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |Should custom-built AI models be considered as software and thus subject to the legal requirements of a? What about the training data? + +a|A +a|Open source refers to software whose source code is freely accessible and modifiable under minimum conditions. This also includes custom-trained AI models (including the algorithm, training procedure, and code). + +AI models are trained on the basis of data, possibly Open (Government) Data*. Open Data refers to datasets that are free to use, share and process. AI models with underlying training data based on Open (Government) Data are considered software subject to EMOTA and therefore must also be published. + +However, if the training data contains (sensitive) personal data or classified information, publication can be waived on security-relevant grounds. When open-sourcing an AI model, the training data does not necessarily have to be published; however, this is in keeping with the open source ethos and is strongly encouraged by the open source community. For further information regarding AI, we refer to the Competence Network for Artificial Intelligence (CNAI).footnote:[See: https://cnai.swiss/ and also Art. 10 EMOTA] +|=== + +[cols="1,9",options="header"] +|=== +|Q |Must tools with generative AI capabilities (e.g. GitHub Copilot) be checked before use to ensure that no intellectual property belonging to third parties or the federal government is violated? + +a|A +a|Content generated by an AI model itself cannot be protected by copyright because there is no creative activity behind it. However, AI-generated content that draws on copyrighted works of third parties may infringe the rights of these third parties. Also, given that AI outputs are notoriously unreliable, they should only be used after careful examination in each case. + +Furthermore, the operators of AI systems may reserve the right in their terms and conditions to use inputs to train the system. This, in turn, can lead to inputs or parts thereof being displayed to third parties. Where this cannot be ruled out, it must be ensured that inputs do not violate the rights of the Confederation or third parties. + +It is recommended to examine and approve the use of AI tools individually. Unapproved tools may not be used, but employees can apply for approval of a tool. Often it makes sense to resolve such issues by contract with the supplier, or some suppliers may offer special subscriptions by which they respect third-party rights, e.g. DeepL. +|=== + +=== Legal basis in EMOTAfootnote:[SR 172.019] + +[cols="1,9",options="header"] +|=== +|Q |*What is the legal basis for the publication of OSS?* + +a|A +a|According to Art. 9 EMOTA, federal authorities of the central Federal Administration must disclose the source code of software they develop or commission. Any person is allowed to use, further develop or modify the software without being charged fees of any kind. + +Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. + +More information can be found in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*What is meant by security-relevant reasons?* + +|A +|The security-relevant reasons permitted under Art. 9 EMOTA and how to deal with them are defined in Section 3.2 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*What are third-party rights?* + +|A +|Third-party rights under Art. 9 EMOTA and how to deal with them are defined in Section 3.3 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Is it possible for exceptions to be time-limited?* + +a|A +a|The grounds for an exception under Art. 9 EMOTA (third-party rights and security-relevant reasons) may cease to apply over time. + +If that happens, the source code of the software must be released. +|=== + +[cols="1,9",options="header"] +|=== +|Q |What legal consequences should be considered in case of a violation of Art. 9 EMOTA? + +a|A +a|There are two types of violations: + +. Third-party rights are violated +. A federal authority refuses to publish OSS (e.g. citing security-relevant reasons that are not valid) + +Answer to 1: + +This will regularly be a breach of contract and claims for damages may be asserted in accordance with the Swiss Code of Obligations. + +Answer to 2: + +This has no direct consequence. If a third party wants to be able to use the source code of a federal authority, they have to submit a request under the Freedom of Information Act (FoIA; SR 152.3) to the responsible authority. + +If there is a high level of interest, it may make sense to consider publication in the interest of both parties. There is no obligation to publish retroactively, although this can be done voluntarily. +|=== + +[cols="1,9",options="header"] +|=== +|Q |Can liability claims be asserted in the case of damage caused by OSS? + +|A +|In principle, liability claims should be excluded in the contracts. However, it is not possible to exclude liability for gross negligence or culpable negligence. In such cases, a federal authority could be held liable under the Government Liability Act (GLA; SR 170.32). +|=== + +[cols="1,9",options="header"] +|=== +|Q |*From which date must software be published?* + +a|A +a|According to Art. 9 para. 1 EMOTA, software that is or has been developed after 1 January 2024 must be published. + +For software developed before 1 January 2024, release should be considered when major changes are pending. + +If there is considerable interest from third parties, existing software may also be released voluntarily (possibly with cost sharing). In this case, a community (see link:em002-4.adoc[Em002-4]) should also be considered. + +For smaller scripts, publication is usually not the best option. There may be repositories for tools that then go through the release process at the same time. + +For administrative units of the decentralised Federal Administration that are subject to EMOTA, the publication requirement has applied since 1 May 2025. Exceptions to the publication requirement exist for software developed without federal funding and research software (Art. 3 para. 1 DigiO). +|=== + +[cols="1,9",options="header"] +|=== +|Q |Is it possible to demand retroactive publication for software developed before 1 January 2024? + +a|A +a|The law does not provide for retroactive publication. + +Furthermore, contracts concluded before 1 January 2024 may contain third-party rights that preclude publication. + +If a new major version is pending (major according to Semantic Versioningfootnote:[See: https://en.wikipedia.org/wiki/Version_control]), a release of the entire software should be considered. Otherwise, the source code of the new functionalities would at least have to be released. +|=== + +[cols="1,9",options="header"] +|=== +|Q |On what basis would a third party have to request the release of source code + +|A +|A third party would have to submit a request under the FoIA to the competent authority. +|=== + +== Roles and responsibilities + +=== Role of the Federal Chancellery + +[cols="1,9",options="header"] +|=== +|Q |*Who makes the basic implementation tools available?* + +a|A +a|The DTI Sector of the Federal Chancellery provides tools for the federal authorities as a document set accompanying Em002. This includes the strategic guidelines and other practical guidelines including FAQs, as well as checklists to ensure legally compliant implementation. + +The OSS tools are updated by DTI. +|=== + +[cols="1,9",options="header"] +|=== +|Q |Is the Federal Chancellery responsible for granting exemptions (e.g. for security-relevant reasons)? + +a|A +a|There is no central body that rules on exemptions to the publication obligation under Art. 9 EMOTA. Each federal authority is responsible for its own legally compliant implementation. + +The federal departments may establish regulations. + +The Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL] from the FOBL should be completed. +|=== + +=== Role of administrative units + +[cols="1,9",options="header"] +|=== +|Q |*Who is responsible for operational implementation of OSS releases?* + +a|A +a|Each federal authority (e.g. office, administrative unit) that develops or commissions software is independently responsible for the entire publication process. + +The federal departments may establish binding regulations and control mechanisms within their area of responsibility, e.g. to prevent reputational damage. + +It is recommended to appoint a person responsible for OSS per federal office, e.g. IT Manager (IM), Enterprise Architect, ISBO or DSBO, to ensure uniform and efficient processes. If this is not specified, the federal office management is generally responsible for compliant implementation. + +This officer could then also be consulted for granting exemptions to the publication obligation. +|=== + +=== Collaborations with third-party providers + +[cols="1,9",options="header"] +|=== +|Q |*How should a federal authority's in-house developments be published?* + +|A +|Copyright arises with the respective natural persons who developed the source code, although this is usually transferred to the employer by way of the employment contract. In contracts with external service providers, it is important to clearly delineate new developments and to agree on the contractual assignment/transfer of copyright. Ultimately, for joint in-house developments, the parties involved must agree on the open source licence for the source code under which the software is published as an independent open source project. Publication under an open source licence does not mean waiving copyright: this remains with the respective rights holders. Only on the basis of their copyright can they legally defend against licence violations or grant more extensive licences in parallel to OSS licences. +|=== + +=== Disclosure of personal data + +[cols="1,9",options="header"] +|=== +|Q |Under what conditions may personal data, such as that of developers, be published as part of OSS? + +a|A +a|There is no general rule for this. The decision lies with the project. + +In any case, the applicable data protection regulations must be complied with. According to Article 36 para. 1 FADP, federal bodies may only disclose personal data if they have a legal basis for doing so. + +Article 36 para. 2 FADP specifies the following exceptions, among others: + +(b) The data subject has consented to the disclosure. + +(e) The data subject has made their data generally accessible and has not explicitly prohibited processing. + +In most cases, it is advisable to obtain the consent of the persons concerned in advance, as they usually also have an interest in their work being publicly visible. If consent is not given, or if there are other reasons against publication, the source code should be published without personal data, referring only to the federal authority concerned. + +This consent should be obtained from suppliers and employees as part of the procurement and hiring processes. +|=== + +=== Procurement + +[cols="1,9",options="header"] +|=== +|Q |*Where can I find the documentation for OSS procurement?* + +a|A +a|With Version 2.0, a tool link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software] was made available. + +The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled Software Procurement and Art. 9 EMOTA [KBB-MB] as well as two documents 'Sample criteria – EMOTA procurement and open source.docx' and 'Sample contract texts – software development.docx'. + +Further resources can be found on the public procurement learning and template platform (www.perimap.admin.ch). + +Further assistance is available on the FOBL intranet (accessible only on the federal network) with the Open Source in Procurement Guidelines [BBL-WL] and the Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL]. + +The relevant information can be found on the FOBL intranet pages (only available within the Confederation). + +Links: FOBL IT procurement toolbox +|=== + +== Process + +=== Guidance + +[cols="1,9",options="header"] +|=== +|Q |*Is there central guidance on how OSS is handled in the Federal Administration?* + +a|A +a|Yes, the DTI Section of the Federal Chancellery provides comprehensive materials for this purpose. + +Note that these tools are an ICT recommendation and not a binding requirement. + +Link to OSS tools +|=== + +[cols="1,9",options="header"] +|=== +|Q |*How should a federal authority's in-house developments that were created in collaborations be published? How should existing rights be handled?* + +a|A +a|When developing software, [.underline]#copyright arises with the respective natural persons# who developed the source code. + +If the developer is in an employment relationship, the developments belong to the employer (Art. 332 CO). + +For contracts with external service providers, it is therefore important to clearly delineate new developments and to agree on the contractual assignment/transfer of copyright. Ultimately, for joint in-house developments, the parties involved must agree on the open source licence for the source code under which the software is published as an independent open source project. + +Publication under an open source licence does not mean waiving copyright: this remains with the respective rights holders. + +Only on the basis of their copyright can they legally defend against licence violations or grant more extensive licences in parallel to OSS licences. + +The [.underline]#original rights# should therefore always lie with the federal government for new or further developments, if possible. [.underline]#Contributor Licence Agreements# (CLA) or Developer Certificate of Origin (DCO) should be used for other participants. Instructions for this can be found in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Do changes have to be published?* + +a|A +a|According to Art. 9 EMOTA: yes, if they were developed after 1 January 2024. + +However, this should be done in a way that also provides benefit. The document link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] provides information on the process. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*When is the publication 'sufficient' according to EMOTA?* + +a|A +a|Art. 9 EMOTA is not specific in this regard and there is a great deal of room for manoeuvre. The source code must be publicly accessible. + +For example, the requirements of the law are satisfied by simply publishing the source code in a zip file on a website. + +In order to achieve a benefit, including through the publication of documentation etc., this should be done on a code repository according to best practices. Information on this can be found in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*In the future, will service procurers be telling service providers how the software should be published and how to ensure quality?* + +a|A +a|The rules of the individual federal authority apply to both service providers and service procurers. + +However, it makes sense to include the corresponding tools at suitable points in the existing processes and quality gates. + +Based on its development experience, the service provider can make suggestions for its service procurer here and treat this uniformly (just as the development process is treated uniformly). +|=== + +=== Licence selection + +[cols="1,9",options="header"] +|=== +|Q |*Under which open source licence should software be developed?* + +a|A +a|There are no strict requirements regarding the choice of licence as long as the licence terms of the software components used in the software to be developed are adhered to. + +For completely new developments, a licence type should be chosen that enables a broad and sustainable basis for further developments. + +For this, it is important that the licence in question should be widely accepted in the relevant developer community. + +*The use of AGPL (with copyleft) and MIT is therefore recommended.* + +These two licences represent the two extremes of the licence spectrum, so to speak. + +AGPL with a very strong copyleft permanently enforces the principle of 'public money – public code'. In the case of further developments, namely proprietary solutions, this will weaken towards LGPL. + +MIT, on the other hand, is a very liberal licence where almost anything is possible. + +The two licences cover the entire spectrum. If particular importance is attached to not naming the federal government in the case of permissive licences, BSD-3 is to be preferred over MIT. + +For a more detailed selection of licences, please refer to link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +|=== + +=== Quality criteria for OSS + +[cols="1,9",options="header"] +|=== +|Q |*Does open source software have to meet certain quality criteria?* + +|A +|As a rule, all quality criteria for any other software also applies. Open source primarily makes everything more transparent. To comply with the licence, the criteria for a 'good' release, and any community rules in place, some additional points are necessary. These are outlined in link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*What are the requirements planned for quality gates?* + +a|A +a|No central requirements are planned. The rules of the federal authority (administrative units) developing the software are applicable. + +Apart from the general requirements, there are no special requirements for OSS quality. However, Hermes will be updated to incorporate Art. 9 EMOTA. + +Publication is the Federal Administration's way of going public. If this is not done carefully and professionally, the public image of a federal authority can quickly suffer. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*How are development guidelines regulated?* + +|A +|Apart from the general requirements set out in the tools, there are no special requirements regarding the development of open source software. Guidance is provided in link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Does OSS have to be published in a specific location?* + +a|A +a|The Confederation does not currently operate its own central repository. The federal authorities are therefore basically free in their publication. As many federal authorities already use GitHub, this platform is currently the preferred choice. There is also a central GitHub account (swiss) that can be used. + +GitHub - swiss/index: An overview of current repository organisations. + +This is especially the case if a federal authority does not yet have a GitHub account ('organisation') or does not use another platform such as GitLab or BitBucket. + +Please contact the responsible unit in the DTI (opensource@bk.admin.ch) to check whether publication via the central GitHub account (swiss) is appropriate and possible. + +Federal authorities should in all cases maintain a local copy of the code. It is also advisable for each federal authority to have a corresponding strategy. It is also advisable for each federal authority to have corresponding internal rules in place. + +Further recommendations are given in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +=== Documentation + +[cols="1,9",options="header"] +|=== +|Q |*What are the documentation requirements for OSS publication?* + +a|A +a|The tools made available by the Federal Chancellery's DTI Sector provide information on the legal requirements; see OSS tools. + +It is recommended that the OSS checklists be completed and stored centrally in each federal authority (administrative unit). +|=== + +=== Contributions to projects by the Federal Administration + +[cols="1,9",options="header"] +|=== +|Q |*Can and should an administrative unit contribute code to an 'upstream' project and does it thereby meet the requirements of Art. 9 EMOTA?* + +a|A +a|* If the projects are open source, then Art. 9 EMOTA is fulfilled. However, the projects must also remain open source. If they fail to do so, the code must be published again. +* Upstream contributions have the advantage that maintenance takes place within the upstream project and the benefit for the community is maximised. ++ +The following disadvantages exist: less control and influence, a CLA may have to be signed or a DCO (see link:em002-4.adoc[Em002-4] Section 3.3). The contributions also do not appear in the publiccode.yml and the federal directories. A completely different advantage is that with such contributions, the developers continue to develop within the ecosystem. +* As long as the risks and effort remain manageable (CLA content, collection of the code), upstream contributions are to be welcomed. +* The licence of the upstream project then applies to the contribution. This corresponds to the procedure in link:em002-3.adoc[Em002-3]. +* *Forking of upstream projects should be avoided:* The entire maintenance and update burden then falls to the federal authority. Inadequate maintenance of the fork also represents a security risk. There is hardly any benefit for the community. +* Contributions to upstream projects should generally be viewed positively and actively discussed by the federal authorities' project managers. +* If the upstream project belongs to the Federal Administration and involves third-party contributions, link:em002-7.adoc[Em002-7] Section 9 will help. +|=== + +=== Support + +[cols="1,9",options="header"] +|=== +|Q |*Is the federal authority required to provide support for published software?* + +a|A +a|No, but it can if it so wishes. + +According to Art. 9 paras 5 and 6 EMOTA, it may also charge fees for support. +|=== + +[cols="1,9",options="header"] +|=== +|Q |*How should an authority proceed if it wishes to charge for support?* + +|A +|For resource reasons, this is not part of the current project to provide tools. If required, this could be included in the tools in a subsequent stage. For the time being, each federal authority regulates this itself. (See also link:em002-4.adoc[Em002-4 OSS Community Guidelines]) +|=== + +== Tools + +=== Guidance + +[cols="1,9",options="header"] +|=== +|Q |Is there any central guidance on working with open source software in the Federal Administration? + +a|A +a|Yes, the DTI Sector of the Federal Chancellery provides comprehensive materials for this as part of link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. + +OSS is discussed in general terms in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. Release under Art. 9 EMOTA is addressed in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|=== + +=== Checklists + +[cols="1,9",options="header"] +|=== +|Q |*Do the tools also include checklists for releasing open source software?* + +a|A +a|Yes, the DTI Sector of the Federal Chancellery provides the following checklists for free use: + +* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] + +See the *Checklist for Art. 9 EMOTA Blanket Exception* [BBL-CL] from the FOBL. +|=== + +=== Security matters + +[cols="1,9",options="header"] +|=== +|Q |*Are there special OSS security risks?* + +a|A +a|In this context, supply chain attacks, zero-day vulnerabilities and typosquatting attacks are mentioned, for example. + +Such security issues must be taken into account in OSS and in its procurement, but also generally in the development of software and in the procurement of commercial software. At best, they can be somewhat amplified if the OSS project used was careless when integrating libraries and containers. + +In the medium term, a general strategy is needed to mitigate these risks (through the NCSC/SEPOS). If necessary, secure sources for containers and libraries must be made available. + +In general, all those responsible in the IT environment must be aware of these possible attack vectors. Possible attempts include: + +* Supply chain attacks: `XZ_Utils_backdoor` (https://en.wikipedia.org/wiki/XZ_Utils_backdoor), Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/) +* Zero-day vulnerabilities: Log4Shell (https://www.ibm.com/de-de/think/topics/log4j) +* Typosquatting: https://en.wikipedia.org/wiki/Typosquatting +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Does publishing source code increase the risk of a malicious copy of an app? (e.g. a phishing or fake app)* + +a|A +a|No. Withholding source code offers no effective protection against fake apps and is moreover incompatible with Article 9 EMOTA, which establishes the open source principle for the Federal Administration. + +The risk of a third party building a visually identical app to harvest data exists regardless of whether the source code is published. Since the Confederation's design systems are publicly available, the look and feel of an app can be replicated by an attacker without access to the source code. Apps can also be decompiled to extract assets such as logos from the published version. + +Security and trust are therefore ensured not through obscurity, but through verification and cryptographic security: + +* *Digital signatures:* Official apps must be cryptographically signed, providing technical assurance that an app is an unmodified original from the Confederation. The smartphone operating system verifies this signature. +* *App store verification:* The Apple and Google app stores offer processes to verify publishers as official government bodies. Google, for example, explicitly labels Federal Chancellery (FCh) apps as government apps, giving users confidence in their authenticity. +* *Reproducible builds:* Through independent, reproducible builds, it can be technically demonstrated that the published source code corresponds exactly to the app available in the store. + +A blanket exemption for security-related reasons under Article 9 of EMOTA is therefore not applicable to apps. + +[.underline]#Recommendation:# + +Rather than withholding source code, the focus should be on app store processes and monitoring. Official channels must be kept up to date and fake apps reported promptly for removal by the platform operators (Apple and Google). +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Does it make sense for requisitioners within the Federal Administration to join forces to procure OSS?* + +a|A +a|Yes, definitely. This can be done directly and informally between administrative units. + +The problem is rather that the administrative units do not know much about each other's needs. + +One solution could be for administrative units to keep a 'most wanted' list of OSS tools (or libraries) to be developed or made available and to share this list. + +Such a centrally managed list could also help to better analyse the need for OSS components and better assess the maturity level of the administrative unit. Ultimately, an artifact repository would make sense. + +Maintaining such a list would then be the task of an OSPO, should one be introduced. At best, this could also be done via Digital Public Services Switzerland for the entire federal structure. +|=== + +== Legal matters + +=== Use of English + +[cols="1,9",options="header"] +|=== +|Q |*Is the Confederation allowed to use licences in the original language English?* + +a|A +a|According to Art. 9 para. 4 EMOTA, internationally established licence texts should be used wherever possible and practical. + +Insisting on German-language OSS licences would largely negate the purpose of Art. 9 para. 4 EMOTA as there are very few internationally established licence texts where a version in one of Switzerland's official languages (German, French and Italian as specified in Art. 70 para. 1 Cst.) is recognised as authoritative for interpretation. + +This situation parallels English-language courses at higher education institutions such as ETH, where English as the teaching language is permitted – subject to the three conditions under Article 36 of the Federal Constitution (St Gallen Commentary on the Federal Constitution, 4th ed. 2023, Art. 70 N 29; namely a legal basis, public interest, and proportionality must exist for English to be permitted). + +Based on the above, Art. 9 para. 4 EMOTA should be interpreted as providing the legal basis for using English-language licences, since international licences are predominantly in English. The provision must therefore refer to these. + +The public interest in Art. 9 EMOTA lies, among other things, in the exchange with the respective developer communities.footnote:[BBl 2022 804, p. 66] In the computing industry, these communities are typically international and use English as their working language. Restricting licences to German-language ones would at the very least make cooperation with international communities difficult, if not impossible, because software licensed in this way would hardly be used internationally. This would also conflict with the intended purpose of Article 9 EMOTA. + +Moreover, internationally established OSS licences are, by definition, valid worldwide. The legislator evidently intended to enable international use of the released software. Restricting OSS releases to German-language licences would severely limit the international usability of the released software. + +Additionally, English is firmly established as the standard language in the computing industry's commercial sphere, which includes OSS releases. Using English-language licences therefore represents a reasonable and proportionate limitation on the contractual partners' rights. Moreover, English-language licences are both appropriate and necessary to achieve the intended objectives. +|=== + +=== Liability disclaimer + +[cols="1,9",options="header"] +|=== +|Q |*Most OSS licences include liability disclaimers. Is this adequate, or are additional measures needed? What is the position regarding defective software? (including consideration of the Government Liability Act)* + +a|A +a|The applicable licences exclude liability for slight negligence. *Liability cannot be excluded for gross negligence or intentional acts*. However, the practical liability risks are minimal. + +Distributing modified software under a licence incompatible with the original software's licence (for instance, using an MIT licence without copyleft where the code originally used was under a GPL licence with copyleft) breaches the original licence. Due to the absence of good faith protection in intellectual property law, this neither allows other users to suddenly use the original software under the new licence, nor creates an enforceable obligation to offer the new licence under the original software's licence terms. The sole consequence is breach of the original licence, potentially resulting in damages claims (licence analogy) against a federal authority. + +However, this risk can be managed through systematic checking according to the guidelines, as is now standard practice in the software industry. Specifically, licensing requires creating a bill of materials listing all pre-existing software incorporated into the new software, which must be strictly adhered to during licensing. + +Where third-party rights exist, Art. 9 para. 1 EMOTA anyway does not require publication of the software in any case (or potentially only its newly written portions; this should be clarified in the guidelines). + +Under Article 11 of the Government Liability Act, the Confederation's liability is governed by civil law when it acts as a civil law entity. This is the case under Art. 9 para. 2 EMOTA; consequently, additional liability under the Government Liability Act is excluded. +|=== + +=== Permissive software + +[cols="1,9",options="header"] +|=== +|Q |*If software is based on a library/program component published under a permissive licence, can the main software (excluding the library) be published under a non-permissive licence?* + +|A +|Yes, this is unproblematic. See the information provided in the guidelines link:em002-3.adoc[Em002-3]. +|=== + +=== Licence provisions + +[cols="1,9",options="header"] +|=== +|Q |*Can software be used by several different offices? What licence provisions apply within the Federal Administration? Is the Federal Administration considered a corporate group? (This applies to unmodified open source software from third parties.)* + +a|A +a|Distributing software under permissive licences is generally straightforward. + +However, with copyleft licences, the question arises whether distribution within the central or decentralised Federal Administration triggers copyleft obligations and thus risks compromising the confidentiality of the Confederation's own developments. When distributing to institutions of the decentralised Federal Administration that have their own legal personality, this is indeed the case, whereas it does not apply within the central Federal Administration, as all departments operate under the same legal entity. + +Corporate group companies are legally independent but remain under the economic control of the parent company. Legal literature considers the distribution of copyleft-licensed code to a group company as triggering copyleft obligations. Since group companies often receive open-source software during software development, they require their own right of use, meaning that distribution to a group company triggers copyleft obligations. + +In contrast, distribution within the central Federal Administration does not trigger copyleft obligations. However, for the decentralised Federal Administration, where separate legal entities exist, the above applies: distribution triggers copyleft obligations, and the software must be offered in source code form under the same licence terms as the original software. An instruction not to distribute the software to third parties would violate the licence and could also breach Art. 9 EMOTA. +|=== + +=== Relationship between the FoIA and EMOTA + +[cols="1,9",options="header"] +|=== +|Q |*How do the Freedom of Information Act (FoIA) and EMOTA relate to each other?* + +a|A +a|According to Art. 6 FoIA, official documents must be issued. An official document under Art. 5 para. 1 FoIA is defined as any information recorded on any medium that is in the possession of an authority and relates to the performance of a public task. OSS fundamentally falls under the FoIA. The FoIA applies when an individual requests source code from a department or office for their own use. The office must disclose the source code to the person concerned unless exceptions under Article 7 FoIA apply. If the office refuses to disclose the source code, the FoIA procedure applies. A different case arises when someone demands that the office publish the source code on its website. Then the procedure would not follow the FoIA but EMOTA. Since EMOTA itself does not specify a procedure, general administrative law must suffice. This provides either the option of an administrative decision, a real act, or a general declaratory decision from the office concerned. This decision can then be appealed to the Federal Administrative Court. + +While disclosure obligations for software developed by a federal authority under the FoIA are conceivable (if the relevant conditions are met), it should be noted that disclosure of software under the FoIA does not automatically grant an OSS licence. The use of software disclosed under the FoIA is thus limited to the purposes set by the FoIA, such as viewing the code or executing it for observation purposes. However, FoIA disclosure does not include a licence for regular use of the software or as a basis for further software development (details in T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern [tr: Legal Requirements for the Use of Open Source Software in Public Administration, particularly in the Canton of Bern], Zurich 2017, https://carlgrossmann.com/?ddownload=11748, N 393 ff.). + +The decision to license software as OSS, even if it falls under the FoIA, continues to follow EMOTA; there remains no entitlement to the granting of a licence. + +Importantly, software developed before 1 January 2024, while not subject to EMOTA, must still be released according to the FoIA. +|=== + +=== OSS and data protection + +[cols="1,9",options="header"] +|=== +|Q |*Can developers' personal data be published without further consideration? What data protection aspects need to be considered?* + +a|A +a|From a data protection perspective, publishing personal data (e.g. names or email addresses) is problematic unless employees have given prior consent. This is because the disclosure of personal data can, in principle, be avoided through pseudonymisation or anonymisation of repository entries, which would be required according to the principle of data minimisation and proportionality (Art. 6 para. 2 FADP). + +However, such consent should generally be easy to obtain, as employees often have an interest in publicly demonstrating their capabilities (at noted in Poledna/Schlauri/Schweizer, N 68, with references). Consent may also be implied through the use of names in the repository, at least where no employer directive exists to the contrary. + +Nevertheless, it is advisable to address the provider's responsibility for their employees' personal data in the contracts. +|=== + +== General + +[cols="1,9",options="header"] +|=== +|Q |*Does it matter whether OSS is used commercially or non-commercially?* + +|A +|Open source licences generally do not distinguish between commercial and non-commercial use. Therefore, OSS can be used for any purpose, including commercial applications. Commercial suppliers often try to integrate OSS components into proprietary products. This is only permissible if the OSS components are not under a licence with copyleft effects (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). +|=== + +[cols="1,9",options="header"] +|=== +|Q |*Are there restrictions on which organisations are permitted for communities?* + +a|A +a|Ultimately, each case must always be considered individually: who is behind it, and what commitments are being made? + +As long as no money changes hands and no formal commitments are made, the situation is relatively straightforward and unproblematic. + +Association memberships are possible, as is informal collaboration. + +It is possible to delegate memberships to eOperations or similar organisations. + +See also link:em002-4.adoc[Em002-4 OSS Community Guidelines], Section 3.1 +|=== + +[cols="1,9",options="header"] +|=== +|Q |How does ISO Standard 5230 relate to the guidelines? + +a|A +a|ISO Standard 5230:2020 was reviewed and taken into account during the drafting of the guidelines. The list below sets out the requirements of the standard and how these have been addressed in the guidelines: + +*3.1 Programme foundation* + +* The 'link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]' and the referenced strategies provide the framework. The respective federal departments and offices are responsible for implementation. + +*3.2 Relevant tasks defined and supported* + +* The guide 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]' and the checklists define specific tasks for publication. There is currently no central body within the Federal Administration. + +*3.3 Open source content review and approval* + +* The publication process is described in the resource 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). +* The resource 'link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]' provides comprehensive information on licensing. + +*3.4 Compliance artifact creation and delivery* + +* The publication process is described in the resource 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). +* Implementation is not described in further detail and takes place within the federal departments or offices. + +*3.5 Understanding open source community engagements* + +* The resource 'link:em002-4.adoc[Em002-4 OSS Community Guidelines]' describes how to set up and maintain a community. A concept must be defined and implemented for each project. + +*3.6 Adherence to the specification requirements* + +* The final chapter sets out requirements for organisations or projects wishing to explicitly confirm compliance with the OpenChain requirements. + +The ISO standard outlines further areas of responsibility for an Open Source Programme Office (OSPO) which are not covered by the guidance documents. +|=== + +== Annex + +=== Abbreviations + +[cols="1,4",options="header"] +|=== +|Abbreviation |Meaning +|AI |Artificial intelligence +|AO |Application owner +|CCPP |Competence Centre for Federal Public Procurement +|CLA |Contributor Licence Agreement +|DCO |Developer Certificate of Origin +|DPSS |Digital Public Services Switzerland (www.digital-public-services-switzerland.ch/strategy) +|EMOTA |Federal Act on the Use of Electronic Means to Carry Out Official Tasks +|FITSU |Federal IT Steering Unit (until 2021) +|FOBL |Federal Office for Buildings and Logistics +|FoIA |Freedom of Information Act +|FSF |Free Software Foundation +|HERMES |_Handbuch der Elektronischen Rechenzentren des Bundes_, a method for system development (www.hermes.admin.ch) +|OSI |Open Source Initiative +|OSPO |Open Source Programme Office +|OSS |Open source software +|OSSD |open source software development +|OU |Organisational unit (usually a federal office) +|SPc |Service procurer +|SPDX |Software Package Data Exchange +|SPv |Service provider +|=== + +=== Glossary + +Further terms can be found in TERMDAT, the Federal Administration's https://www.bk.admin.ch/bk/en/home/dokumentation/languages/termdat.html[terminology database]. + +Application area:: +This refers to the categories of office automation (OA) software as defined in [A029] and other classifications. + +Branch:: +A development branch of an OSS + +Collaboration:: +The term 'collaboration' derives from the Latin word 'collaborare', which means 'to work together'. + +It describes a way of working in which several people or teams work together towards a common goal, contributing their skills and resources. The focus is on mutual exchange, transparency and the sharing of knowledge. + +According to the Gabler Business Dictionary, collaboration also refers to 'cooperation between a company and its customers and suppliers, using modern information technologies to integrate internal and cross-company business processes.' + +Contribution:: +OSS contribution refers to the contribution to the development and improvement of open source software (OSS). This can take the form of providing code, documentation, tests, feedback or other types of contributions. (Google AI) + +Contributor Licence Agreement (CLA):: +A Contributor Licence Agreement (CLA), also known as a Contributor Agreement, is a document that sets out the terms under which intellectual property may be contributed to a project or initiative. This usually refers to a software project under an open-source licence (Wikipedia). + +Core developer:: +Developer of an OSS project who has committer access rights to the repository. + +Market analysis:: +A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html). Possible sources of OSS software can be found in link:em002-1.adoc[Em002-1 Practical Guidelines for OSS] in Section 7. + +OSS:: +Open source software + +Product:: +Used here as a synonym for 'application'. ++ +The term originates from ITIL. In ITIL (Information Technology Infrastructure Library), a product is a configuration of resources designed to deliver value to a customer or organisation. Unlike a service, which is typically an ongoing, interactive process, a product is a static entity. ++ +Products can be software, hardware, data or other resources provided by the organisation. (Google AI) + +Product standardisation:: +In this document, standardisation primarily refers to SD120, the ICT standard service for office automation, and other standardisations by DTI. + +Subscription:: +When subscribing to software, a subscription is taken out. This means that the software is not purchased. + +In most cases, this involves not only permission to use the software, but also includes all relevant services and support. + +Upstream project:: +Upstream is a term used in distributed software development (often open source) and refers to the direction of a patch to its origin (upstream), i.e. to the original developers or maintainers of the software, or to the original project. These can also be software libraries. diff --git a/docs/en/em002-6.md b/docs/en/em002-6.md deleted file mode 100644 index 3685c28..0000000 --- a/docs/en/em002-6.md +++ /dev/null @@ -1,511 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# Background and purpose - -## Background and purpose of the FAQs - -A number of questions frequently arise in connection with the tools available for publishing OSS. The following compilation answers the most common questions and aims to provide a better understanding of individual topics and aspects. - -## Structure and organisation - -The FAQs are organised by subject, as follows: - -2. Terms and definitions - -3. Roles and responsibilities - -4. Process - -5. Tools - -6. Legal matters - -7. General - -Each section is structured as follows: - - |Q | Question| - |:--|:--| - |A | Answer| - - -# Terms and definitions - -## Open source software - - - | Q | **What is meant by open source software?**| - |:--|:--| - | A | This is defined in [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration ](./em002-1.md)| - - -## Software and licences - - -| Q | **What is meant by software?**| -|:--|:--| -| A | This is defined in [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration ](./em002-1.md).

For licences, see [Em002-3 OSS Licensing Guidelines](./em002-3.md).| - -| Q | **What is meant by licences?**| -|:--|:--| -| A | Here we are referring to software licences. Further information can be found in [Em002-3 OSS Licensing Guidelines](./em002-3.md).| - - -| Q | Should custom-built AI models be considered as software and thus subject to the legal requirements of a? What about the training data? | -|:--|:--| -| A | Open source refers to software whose source code is freely accessible and modifiable under minimum conditions. This also includes custom-trained AI models (including the algorithm, training procedure, and code).

AI models are trained on the basis of data, possibly Open (Government) Data*. Open Data refers to datasets that are free to use, share and process. AI models with underlying training data based on Open (Government) Data are considered software subject to EMOTA and therefore must also be published.

However, if the training data contains (sensitive) personal data or classified information, publication can be waived on security-relevant grounds. When open-sourcing an AI model, the training data does not necessarily have to be published; however, this is in keeping with the open source ethos and is strongly encouraged by the open source community. For further information regarding AI, we refer to the Competence Network for Artificial Intelligence (CNAI).[^5]| - -| Q |Must tools with generative AI capabilities (e.g. GitHub Copilot) be checked before use to ensure that no intellectual property belonging to third parties or the federal government is violated?| -|:--|:--| -| A | Content generated by an AI model itself cannot be protected by copyright because there is no creative activity behind it. However, AI-generated content that draws on copyrighted works of third parties may infringe the rights of these third parties. Also, given that AI outputs are notoriously unreliable, they should only be used after careful examination in each case. 

Furthermore, the operators of AI systems may reserve the right in their terms and conditions to use inputs to train the system. This, in turn, can lead to inputs or parts thereof being displayed to third parties. Where this cannot be ruled out, it must be ensured that inputs do not violate the rights of the Confederation or third parties.

It is recommended to examine and approve the use of AI tools individually. Unapproved tools may not be used, but employees can apply for approval of a tool. Often it makes sense to resolve such issues by contract with the supplier, or some suppliers may offer special subscriptions by which they respect third-party rights, e.g. DeepL. | - - -## Legal basis in EMOTA[^6] - -| Q | **What is the legal basis for the publication of OSS?** | -|:--|:--| -| A |According to Art. 9 EMOTA, federal authorities of the central Federal Administration must disclose the source code of software they develop or commission. Any person is allowed to use, further develop or modify the software without being charged fees of any kind.

Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons.

More information can be found in [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md).| - - |Q | **What is meant by security-relevant reasons?**| - |:--|:--| - | A| The security-relevant reasons permitted under Art. 9 EMOTA and how to deal with them are defined in Section 3.2 of [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md).| - - | Q | **What are third-party rights?** | - |:--|:--| - | A | Third-party rights under Art. 9 EMOTA and how to deal with them are defined in Section 3.3 of [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md).| - -| Q | **Is it possible for exceptions to be time-limited?**| -|:--|:--| -| A | The grounds for an exception under Art. 9 EMOTA (third-party rights and security-relevant reasons) may cease to apply over time.

If that happens, the source code of the software must be released.| - -|Q|What legal consequences should be considered in case of a violation of Art. 9 EMOTA?| -|:--|:--| -| A|There are two types of violations:

1. Third-party rights are violated

2. A federal authority refuses to publish OSS (e.g. citing security-relevant reasons that are not valid)

Answer to 1:

This will regularly be a breach of contract and claims for damages may be asserted in accordance with the Swiss Code of Obligations.

Answer to 2:

This has no direct consequence. If a third party wants to be able to use the source code of a federal authority, they have to submit a request under the Freedom of Information Act (FoIA; SR 152.3) to the responsible authority.

If there is a high level of interest, it may make sense to consider publication in the interest of both parties. There is no obligation to publish retroactively, although this can be done voluntarily. - -|Q | Can liability claims be asserted in the case of damage caused by OSS?| -|:--|:--| -|A | In principle, liability claims should be excluded in the contracts. However, it is not possible to exclude liability for gross negligence or culpable negligence. In such cases, a federal authority could be held liable under the Government Liability Act (GLA; SR 170.32).| - -| Q | **From which date must software be published?**| -|:--|:--| -| A | According to Art. 9 para. 1 EMOTA, software that is or has been developed after 1 January 2024 must be published.

For software developed before 1 January 2024, release should be considered when major changes are pending.

If there is considerable interest from third parties, existing software may also be released voluntarily (possibly with cost sharing). In this case, a community (see [Em002-4]) should also be considered.

For smaller scripts, publication is usually not the best option. There may be repositories for tools that then go through the release process at the same time.

For administrative units of the decentralised Federal Administration that are subject to EMOTA, the publication requirement has applied since 1 May 2025. Exceptions to the publication requirement exist for software developed without federal funding and research software (Art. 3 para. 1 DigiO).| - -| Q | Is it possible to demand retroactive publication for software developed before 1 January 2024?| -|:--|:--| -| A | The law does not provide for retroactive publication.

Furthermore, contracts concluded before 1 January 2024 may contain third-party rights that preclude publication.

If a new major version is pending (major according to Semantic Versioning[^7]), a release of the entire software should be considered. Otherwise, the source code of the new functionalities would at least have to be released. | - -| Q | On what basis would a third party have to request the release of source code | -|:--|:--| -| A | A third party would have to submit a request under the FoIA to the competent authority.| - - -# Roles and responsibilities - -## Role of the Federal Chancellery - -| Q | **Who makes the basic implementation tools available?**| -|:--|:--| -| A | The DTI Sector of the Federal Chancellery provides tools for the federal authorities as a document set accompanying Em002. This includes the strategic guidelines and other practical guidelines including FAQs, as well as checklists to ensure legally compliant implementation.

The OSS tools are updated by DTI.| - -| Q | Is the Federal Chancellery responsible for granting exemptions (e.g. for security-relevant reasons)?| -|:--|:--| -| A | There is no central body that rules on exemptions to the publication obligation under Art. 9 EMOTA. Each federal authority is responsible for its own legally compliant implementation.

The federal departments may establish regulations.

The Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL] from the FOBL should be completed.| - -## Role of administrative units - - -| Q | **Who is responsible for operational implementation of OSS releases?** | -|:--|:--| -| A | Each federal authority (e.g. office, administrative unit) that develops or commissions software is independently responsible for the entire publication process.

The federal departments may establish binding regulations and control mechanisms within their area of responsibility, e.g. to prevent reputational damage.

It is recommended to appoint a person responsible for OSS per federal office, e.g. IT Manager (IM), Enterprise Architect, ISBO or DSBO, to ensure uniform and efficient processes. If this is not specified, the federal office management is generally responsible for compliant implementation.

This officer could then also be consulted for granting exemptions to the publication obligation. | - - -## Collaborations with third-party providers -| Q | **How should a federal authority\'s in-house developments be published?**| -|:--|:--| -| A | Copyright arises with the respective natural persons who developed the source code, although this is usually transferred to the employer by way of the employment contract.

In contracts with external service providers, it is important to clearly delineate new developments and to agree on the contractual assignment/transfer of copyright.

Ultimately, for joint in-house developments, the parties involved must agree on the open source licence for the source code under which the software is published as an independent open source project. Publication under an open source licence does not mean waiving copyright: this remains with the respective rights holders. Only on the basis of their copyright can they legally defend against licence violations or grant more extensive licences in parallel to OSS licences.| - - -## Disclosure of personal data - -| Q|Under what conditions may personal data, such as that of developers, be published as part of OSS?| -|:--|:--| -|A| There is no general rule for this. The decision lies with the project.

In any case, the applicable data protection regulations must be complied with. According to Article 36 para. 1 FADP, federal bodies may only disclose personal data if they have a legal basis for doing so.

Article 36 para. 2 FADP specifies the following exceptions, among others:

b. The data subject has consented to the disclosure.

e. The data subject has made their data generally accessible and has not explicitly prohibited processing.

In most cases, it is advisable to obtain the consent of the persons concerned in advance, as they usually also have an interest in their work being publicly visible. If consent is not given, or if there are other reasons against publication, the source code should be published without personal data, referring only to the federal authority concerned.

This consent should be obtained from suppliers and employees as part of the procurement and hiring processes. - -## Procurement - -| Q | **Where can I find the documentation for OSS procurement?** | -|:--|:--| -| A |With Version 2.0, a tool [Em002-7 Strategic Aspects of Procurement and Open Source Software](./em002-7.md) was made available.

The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled Software Procurement and Art. 9 EMOTA [KBB-MB] as well as two documents 'Sample criteria – EMOTA procurement and open source.docx' and 'Sample contract texts – software development.docx.

Further resources can be found on the public procurement learning and template platform (www.perimap.admin.ch).

Further assistance is available on the FOBL intranet (accessible only on the federal network) with the Open Source in Procurement Guidelines [BBL-WL] and the Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL].

The relevant information can be found on the FOBL intranet pages (only available within the Confederation).

Links: FOBL IT procurement toolbox | - -# Process - -## Guidance - - -| Q | **Is there central guidance on how OSS is handled in the Federal Administration?**| -|:--|:--| -| A |Yes, the DTI Section of the Federal Chancellery provides comprehensive materials for this purpose.

Note that these tools are an ICT recommendation and not a binding requirement.

Link to OSS tools| - -| Q | **How should a federal authority\'s in-house developments that were created in collaborations be published? How should existing rights be handled?**| -|:--|:--| -| A | When developing software, copyright arises with the respective natural persons who developed the source code.

If the developer is in an employment relationship, the developments belong to the employer (Art. 332 CO).

For contracts with external service providers, it is therefore important to clearly delineate new developments and to agree on the contractual assignment/transfer of copyright. Ultimately, for joint in-house developments, the parties involved must agree on the open source licence for the source code under which the software is published as an independent open source project.

Publication under an open source licence does not mean waiving copyright: this remains with the respective rights holders.

Only on the basis of their copyright can they legally defend against licence violations or grant more extensive licences in parallel to OSS licences.

The original rights should therefore always lie with the federal government for new or further developments, if possible. Contributor Licence Agreements (CLA) or Developer Certificate of Origin (DCO) should be used for other participants. Instructions for this can be found in [Em002-3 OSS Licensing Guidelines](./em002-3.md), [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md) and [Em002-4 OSS Community Guidelines](./em002-4.md).| - -| Q | **Do changes have to be published?** | -|:--|:--| -| A | According to Art. 9 EMOTA: yes, if they were developed after 1 January 2024.

However, this should be done in a way that also provides benefit. The document [Em002-2 Instructions for Publishing Open Source Software](./em002-2.md) provides information on the process. | - -| Q | **When is the publication \'sufficient\' according to EMOTA?** | -|:--|:--| -| A |Art. 9 EMOTA is not specific in this regard and there is a great deal of room for manoeuvre. The source code must be publicly accessible.

For example, the requirements of the law are satisfied by simply publishing the source code in a zip file on a website.

In order to achieve a benefit, including through the publication of documentation etc., this should be done on a code repository according to best practices. Information on this can be found in [Em002-2 Instructions for Publishing Open Source Software](./em002-2.md).| - -| Q | **In the future, will service procurers be telling service providers how the software should be published and how to ensure quality?**| -|:--|:--| -| A | The rules of the individual federal authority apply to both service providers and service procurers.

However, it makes sense to include the corresponding tools at suitable points in the existing processes and quality gates.

Based on its development experience, the service provider can make suggestions for its service procurer here and treat this uniformly (just as the development process is treated uniformly).| - - -## Licence selection - -| Q | **Under which open source licence should software be developed?** | -|:--|:--| -| A | There are no strict requirements regarding the choice of licence as long as the licence terms of the software components used in the software to be developed are adhered to.

For completely new developments, a licence type should be chosen that enables a broad and sustainable basis for further developments.

For this, it is important that the licence in question should be widely accepted in the relevant developer community.

**The use of AGPL (with copyleft) and MIT is therefore recommended.**

These two licences represent the two extremes of the licence spectrum, so to speak.

AGPL with a very strong copyleft permanently enforces the principle of 'public money – public code'. In the case of further developments, namely proprietary solutions, this will weaken towards LGPL.

MIT, on the other hand, is a very liberal licence where almost anything is possible.

The two licences cover the entire spectrum. If particular importance is attached to not naming the federal government in the case of permissive licences, BSD-3 is to be preferred over MIT.

For a more detailed selection of licences, please refer to [Em002-3 OSS Licensing Guidelines](em002-3.md).| - - -## Quality criteria for OSS - - -| Q | **Does open source software have to meet certain quality criteria?** | -|:--|:--| -| A | As a rule, all quality criteria for any other software also applies. Open source primarily makes everything more transparent. To comply with the licence, the criteria for a 'good' release, and any community rules in place, some additional points are necessary. These are outlined in [Em002-2.2 OSS Analysis and Preparation Checklist](Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt) and [Em002-4.1 OSS Community Checklist](Em002-4.1%20Checklist%20OSS%20Community.odt). | - -| Q | **What are the requirements planned for quality gates?** | -|:--|:--| -| A | No central requirements are planned. The rules of the federal authority (administrative units) developing the software are applicable.

Apart from the general requirements, there are no special requirements for OSS quality. However, Hermes will be updated to incorporate Art. 9 EMOTA.

Publication is the Federal Administration's way of going public. If this is not done carefully and professionally, the public image of a federal authority can quickly suffer. | - -| Q | **How are development guidelines regulated?**| -|:--|:--| -| A | Apart from the general requirements set out in the tools, there are no special requirements regarding the development of open source software. Guidance is provided in [Em002-2.2 OSS Analysis and Preparation Checklist](Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt) and [Em002-4 OSS Community Guidelines](./em002-4.md).| - -| Q | **Does OSS have to be published in a specific location?** | -|:--|:--| -| A | The Confederation does not currently operate its own central repository. The federal authorities are therefore basically free in their publication. As many federal authorities already use GitHub, this platform is currently the preferred choice. There is also a central GitHub account (swiss) that can be used.

GitHub - swiss/index: An overview of current repository organisations.

This is especially the case if a federal authority does not yet have a GitHub account ('organisation') or does not use another platform such as GitLab or BitBucket.

Please contact the responsible unit in the DTI (opensource@bk.admin.ch) to check whether publication via the central GitHub account (swiss) is appropriate and possible.

Federal authorities should in all cases maintain a local copy of the code. It is also advisable for each federal authority to have a corresponding strategy. It is also advisable for each federal authority to have corresponding internal rules in place.

Further recommendations are given in [Em002-2 Instructions for Publishing Open Source Software](./em002-2.md).| - - -## Documentation - - -| Q | **What are the documentation requirements for OSS publication?** | -|:--|:--| -| A |The tools made available by the Federal Chancellery's DTI Sector provide information on the legal requirements; see OSS tools.

It is recommended that the OSS checklists be completed and stored centrally in each federal authority (administrative unit).| - -## Contributions to projects by the Federal Administration - - -| Q | **Can and should an administrative unit contribute code to an \'upstream\' project and does it thereby meet the requirements of Art. 9 EMOTA?**| -|:--|:--| -| A |• If the projects are open source, then Art. 9 EMOTA is fulfilled. However, the projects must also remain open source. If they fail to do so, the code must be published again. 

• Upstream contributions have the advantage that maintenance takes place within the upstream project and the benefit for the community is maximised.

The following disadvantages exist: less control and influence, a CLA may have to be signed or a DCO (see [Em002-4](em002-4.md) Section 3.3).

The contributions also do not appear in the publiccode.yml and the federal directories. A completely different advantage is that with such contributions, the developers continue to develop within the ecosystem.

• As long as the risks and effort remain manageable (CLA content, collection of the code), upstream contributions are to be welcomed.

• The licence of the upstream project then applies to the contribution. This corresponds to the procedure in [Em002-3](em002-3.md).

• Forking of upstream projects should be avoided: The entire maintenance and update burden then falls to the federal authority. Inadequate maintenance of the fork also represents a security risk. There is hardly any benefit for the community.

• Contributions to upstream projects should generally be viewed positively and actively discussed by the federal authorities' project managers. 

• If the upstream project belongs to the Federal Administration and involves third-party contributions, [Em002-7](em002-7.md) Section 9 will help.| - -## Support - - -|Q | **Is the federal authority required to provide support for published software?**| -|:--|:--| -|A | No, but it can if it so wishes.

According to Art. 9 paras 5 and 6 EMOTA, it may also charge fees for support.| - -| Q | **How should an authority proceed if it wishes to charge for support?**| -|:--|:--| -| A | For resource reasons, this is not part of the current project to provide tools. If required, this could be included in the tools in a subsequent stage. For the time being, each federal authority regulates this itself.

(See also [Em002-4 OSS Community Guidelines](em002-4.md) | - - -# Tools - -## Guidance - - -| Q |Is there any central guidance on working with open source software in the Federal Administration? | -|:--|:--| -| A |Yes, the DTI Sector of the Federal Chancellery provides comprehensive materials for this as part of [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](em002.md).

OSS is discussed in general terms in [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration](./em002-1.md). Release under Art. 9 EMOTA is addressed in [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md). | - -## Checklists - -| Q | **Do the tools also include checklists for releasing open source software?**| -|:--|:--| -| A |Yes, the DTI Sector of the Federal Chancellery provides the following checklists for free use:.

• [Em002-2.1 OSS Preliminary Assessment Checklist](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt).
• [Em002-2.2 OSS Analysis and Preparation Checklist](Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt)
• [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt).
• [Em002-4.1 OSS Community Checklist](Em002-4.1%20Checklist%20OSS%20Community.odt).

See the *Checklist for Art. 9 EMOTA Blanket Exception* [BBL-CL] from the FOBL.| - -## Security matters - -| Q | **Are there special OSS security risks?**| -|:--|:--| -| A |In this context, supply chain attacks, zero-day vulnerabilities and typosquatting attacks are mentioned, for example.

Such security issues must be taken into account in OSS and in its procurement, but also generally in the development of software and in the procurement of commercial software. At best, they can be somewhat amplified if the OSS project used was careless when integrating libraries and containers.

In the medium term, a general strategy is needed to mitigate these risks (through the NCSC/SEPOS). If necessary, secure sources for containers and libraries must be made available.

In general, all those responsible in the IT environment must be aware of these possible attack vectors. Possible attempts include:

• Supply chain attacks:
XZ_Utils_backdoor (https://en.wikipedia.org/wiki/XZ_Utils_backdoor),
Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/ )
• Zero-day vulnerabilities:
Log4Shell (https://www.ibm.com/de-de/think/topics/log4j )
• Typosquatting: https://en.wikipedia.org/wiki/Typosquatting | - -| Q | **Does publishing source code increase the risk of a malicious copy of an app? (e.g. a phishing or fake app)**| -|:--|:--| -| A | No. Withholding source code offers no effective protection against fake apps and is moreover incompatible with Article 9 EMOTA, which establishes the open source principle for the Federal Administration.

The risk of a third party building a visually identical app to harvest data exists regardless of whether the source code is published. Since the Confederation's design systems are publicly available, the look and feel of an app can be replicated by an attacker without access to the source code. Apps can also be decompiled to extract assets such as logos from the published version.

Security and trust are therefore ensured not through obscurity, but through verification and cryptographic security:

• Digital signatures: Official apps must be cryptographically signed, providing technical assurance that an app is an unmodified original from the Confederation. The smartphone operating system verifies this signature.
•App store verification: The Apple and Google app stores offer processes to verify publishers as official government bodies. Google, for example, explicitly labels Federal Chancellery (FCh) apps as government apps, giving users confidence in their authenticity.
• Reproducible builds: Through independent, reproducible builds, it can be technically demonstrated that the published source code corresponds exactly to the app available in the store.

A blanket exemption for security-related reasons under Article 9 of EMOTA is therefore not applicable to apps.

Recommendation:
Rather than withholding source code, the focus should be on app store processes and monitoring. Official channels must be kept up to date and fake apps reported promptly for removal by the platform operators (Apple and Google).| - -| Q | **Does it make sense for requisitioners within the Federal Administration to join forces to procure OSS?**| -|:--|:--| -| A |Yes, definitely. This can be done directly and informally between administrative units.

The problem is rather that the administrative units do not know much about each other's needs.

One solution could be for administrative units to keep a 'most wanted' list of OSS tools (or libraries) to be developed or made available and to share this list.

Such a centrally managed list could also help to better analyse the need for OSS components and better assess the maturity level of the administrative unit. Ultimately, an artifact repository would make sense.

Maintaining such a list would then be the task of an OSPO, should one be introduced. At best, this could also be done via Digital Public Services Switzerland for the entire federal structure.| - -# Legal matters - -## Use of English - - -| Q | **Is the Confederation allowed to use licences in the original language English?**| -|:--|:--| -| A |According to Art. 9 para. 4 EMOTA, internationally established licence texts should be used wherever possible and practical.

Insisting on German-language OSS licences would largely negate the purpose of Art. 9 para. 4 EMOTA as there are very few internationally established licence texts where a version in one of Switzerland's official languages (German, French and Italian as specified in Art. 70 para. 1 Cst.) is recognised as authoritative for interpretation.

This situation parallels English-language courses at higher education institutions such as ETH, where English as the teaching language is permitted – subject to the three conditions under Article 36 of the Federal Constitution (St Gallen Commentary on the Federal Constitution, 4th ed. 2023, Art. 70 N 29; namely a legal basis, public interest, and proportionality must exist for English to be permitted).

Based on the above, Art. 9 para. 4 EMOTA should be interpreted as providing the legal basis for using English-language licences, since international licences are predominantly in English. The provision must therefore refer to these.

The public interest in Art. 9 EMOTA lies, among other things, in the exchange with the respective developer communities.[^8] In the computing industry, these communities are typically international and use English as their working language. Restricting licences to German-language ones would at the very least make cooperation with international communities difficult, if not impossible, because software licensed in this way would hardly be used internationally. This would also conflict with the intended purpose of Article 9 EMOTA.

Moreover, internationally established OSS licences are, by definition, valid worldwide. The legislator evidently intended to enable international use of the released software. Restricting OSS releases to German-language licences would severely limit the international usability of the released software.

Additionally, English is firmly established as the standard language in the computing industry's commercial sphere, which includes OSS releases. Using English-language licences therefore represents a reasonable and proportionate limitation on the contractual partners' rights. Moreover, English-language licences are both appropriate and necessary to achieve the intended objectives.| - -## Liability disclaimer - -| Q | **Most OSS licences include liability disclaimers. Is this adequate, or are additional measures needed? What is the position regarding defective software? (including consideration of the Government Liability Act)**| -|:--|:--| -| A | The applicable licences exclude liability for slight negligence. **Liability cannot be excluded for gross negligence or intentional acts**. However, the practical liability risks are minimal.

Distributing modified software under a licence incompatible with the original software's licence (for instance, using an MIT licence without copyleft where the code originally used was under a GPL licence with copyleft) breaches the original licence. Due to the absence of good faith protection in intellectual property law, this neither allows other users to suddenly use the original software under the new licence, nor creates an enforceable obligation to offer the new licence under the original software's licence terms. The sole consequence is breach of the original licence, potentially resulting in damages claims (licence analogy) against a federal authority.

However, this risk can be managed through systematic checking according to the guidelines, as is now standard practice in the software industry. Specifically, licensing requires creating a bill of materials listing all pre-existing software incorporated into the new software, which must be strictly adhered to during licensing.

Where third-party rights exist, Art. 9 para. 1 EMOTA anyway does not require publication of the software in any case (or potentially only its newly written portions; this should be clarified in the guidelines).

Under Article 11 of the Government Liability Act, the Confederation's liability is governed by civil law when it acts as a civil law entity. This is the case under Art. 9 para. 2 EMOTA; consequently, additional liability under the Government Liability Act is excluded. | - -## Permissive software -| Q | **If software is based on a library/program component published under a permissive licence, can the main software (excluding the library) be published under a non-permissive licence?**| -|:--|:--| -| A | Yes, this is unproblematic. See the information provided in the guidelines [Em002-3](em002-3.md).| - - -## Licence provisions - -| Q | **Can software be used by several different offices? What licence provisions apply within the Federal Administration? Is the Federal Administration considered a corporate group? (This applies to unmodified open source software from third parties.)** | -|:--|:--| -| A | Distributing software under permissive licences is generally straightforward.

However, with copyleft licences, the question arises whether distribution within the central or decentralised Federal Administration triggers copyleft obligations and thus risks compromising the confidentiality of the Confederation's own developments. When distributing to institutions of the decentralised Federal Administration that have their own legal personality, this is indeed the case, whereas it does not apply within the central Federal Administration, as all departments operate under the same legal entity.

Corporate group companies are legally independent but remain under the economic control of the parent company. Legal literature considers the distribution of copyleft-licensed code to a group company as triggering copyleft obligations. Since group companies often receive open-source software during software development, they require their own right of use, meaning that distribution to a group company triggers copyleft obligations.

In contrast, distribution within the central Federal Administration does not trigger copyleft obligations. However, for the decentralised Federal Administration, where separate legal entities exist, the above applies: distribution triggers copyleft obligations, and the software must be offered in source code form under the same licence terms as the original software. An instruction not to distribute the software to third parties would violate the licence and could also breach Art. 9 EMOTA. | - -## Relationship between the FoIA and EMOTA - -| Q | **How do the Freedom of Information Act (FoIA) and EMOTA relate to each other?**| -|:--|:--| -| A |According to Art. 6 FoIA, official documents must be issued. An official document under Art. 5 para. 1 FoIA is defined as any information recorded on any medium that is in the possession of an authority and relates to the performance of a public task. OSS fundamentally falls under the FoIA. The FoIA applies when an individual requests source code from a department or office for their own use. The office must disclose the source code to the person concerned unless exceptions under Article 7 FoIA apply. If the office refuses to disclose the source code, the FoIA procedure applies. A different case arises when someone demands that the office publish the source code on its website. Then the procedure would not follow the FoIA but EMOTA. Since EMOTA itself does not specify a procedure, general administrative law must suffice. This provides either the option of an administrative decision, a real act, or a general declaratory decision from the office concerned. This decision can then be appealed to the Federal Administrative Court.

While disclosure obligations for software developed by a federal authority under the FoIA are conceivable (if the relevant conditions are met), it should be noted that disclosure of software under the FoIA does not automatically grant an OSS licence. The use of software disclosed under the FoIA is thus limited to the purposes set by the FoIA, such as viewing the code or executing it for observation purposes. However, FoIA disclosure does not include a licence for regular use of the software or as a basis for further software development (details in T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern [tr: Legal Requirements for the Use of Open Source Software in Public Administration, particularly in the Canton of Bern], Zurich 2017, https://carlgrossmann.com/?ddownload=11748, N 393 ff.).

The decision to license software as OSS, even if it falls under the FoIA, continues to follow EMOTA; there remains no entitlement to the granting of a licence.

Importantly, software developed before 1 January 2024, while not subject to EMOTA, must still be released according to the FoIA. | - -## OSS and data protection - - -| Q | **Can developers\' personal data be published without further consideration? What data protection aspects need to be considered?**| -|:--|:--| -| A | From a data protection perspective, publishing personal data (e.g. names or email addresses) is problematic unless employees have given prior consent. This is because the disclosure of personal data can, in principle, be avoided through pseudonymisation or anonymisation of repository entries, which would be required according to the principle of data minimisation and proportionality (Art. 6 para. 2 FADP).

However, such consent should generally be easy to obtain, as employees often have an interest in publicly demonstrating their capabilities (at noted in Poledna/Schlauri/Schweizer, N 68, with references). Consent may also be implied through the use of names in the repository, at least where no employer directive exists to the contrary.

Nevertheless, it is advisable to address the provider's responsibility for their employees' personal data in the contracts. | - -# General - -| Q | **Does it matter whether OSS is used commercially or non-commercially?**| -|:--|:--| -| A | Open source licences generally do not distinguish between commercial and non-commercial use. Therefore, OSS can be used for any purpose, including commercial applications. Commercial suppliers often try to integrate OSS components into proprietary products. This is only permissible if the OSS components are not under a licence with copyleft effects (see also [Em002-3 OSS Licensing Guidelines](em002-3.md)).| - -| Q | **Are there restrictions on which organisations are permitted for communities?**| -|:--|:--| -| A | Ultimately, each case must always be considered individually: who is behind it, and what commitments are being made?

As long as no money changes hands and no formal commitments are made, the situation is relatively straightforward and unproblematic.

Association memberships are possible, as is informal collaboration.

It is possible to delegate memberships to eOperations or similar organisations.

See also [Em002-4 OSS Community Guidelines](./em002-4.md), Section 3.1 | - - - - - - - - - - - -
- Q - - How does ISO Standard 5230 relate to the guidelines? -
- A - - ISO Standard 5230:2020 was reviewed and taken into account during the drafting of the guidelines. The list below sets out the requirements of the standard and how these have been addressed in the guidelines: -
    - 3.1 Programme foundation - -
-
    - 3.2 Relevant tasks defined and supported - -
-
    3.3 Open source content review and approval - - -
-
    - 3.4 Compliance artifact creation and delivery - -
      - • Implementation is not described in further detail and takes place within the federal departments or offices. -
    -
-
    3.5 Understanding open source community engagements -
      - • The resource ' Em002-4 OSS Community Guidelines' describes how to set up and maintain a community. A concept must be defined and implemented for each project. -
    -
-
    3.6 Adherence to the specification requirements -
      - • The final chapter sets out requirements for organisations or projects wishing to explicitly confirm compliance with the OpenChain requirements. -
    -
-The ISO standard outlines further areas of responsibility for an Open Source Programme Office (OSPO) which are not covered by the guidance documents. -
- -# Annex - -## Abbreviations - - - |Abbreviation | Meaning| - |:--|:--| - | AI |Artificial intelligence| - | AO | Application owner | - | CCPP | Competence Centre for Federal Public Procurement | - | CLA | Contributor Licence Agreement | - | DCO | Developer Certificate of Origin | - | DPSS | Digital Public Services Switzerland (www.digital-public-services-switzerland.ch/strategy)| - | EMOTA | Federal Act on the Use of Electronic Means to Carry Out Official Tasks | - | FITSU | Federal IT Steering Unit (until 2021) | - | FOBL | Federal Office for Buildings and Logistics| - | FoIA | Freedom of Information Act | - | FSF | Free Software Foundation | - | HERMES | *Handbuch der Elektronischen Rechenzentren des Bundes*, a method for system development (www.hermes.admin.ch) | - | OSI | Open Source Initiative | - | OSPO | Open Source Programme Office | - | OSS | Open source software | - | OSSD | open source software development | - | OU | Organisational unit (usually a federal office) | - | SPc | Service procurer | - | SPDX | Software Package Data Exchange | - | SPv | Service provider | - - -## Glossary - - -Further terms can be found in TERMDAT, the Federal Administration\'s [terminology database](https://www.bk.admin.ch/bk/en/home/dokumentation/languages/termdat.html). - -

-
- Application area -
-
- This refers to the categories of office automation (OA) software as defined in [A029] and other classifications. -
-
- -
-
- Branch -
-
- A development branch of an OSS -
-
-
-
- Collaboration -
-
- The term ‘collaboration’ derives from the Latin word ‘collaborare’, which means ‘to work together’.
It describes a way of working in which several people or teams work together towards a common goal, contributing their skills and resources. The focus is on mutual exchange, transparency and the sharing of knowledge.
According to the Gabler Business Dictionary, collaboration also refers to 'cooperation between a company and its customers and suppliers, using modern information technologies to integrate internal and cross-company business processes.' -
-
-
-
- Contribution -
-
- OSS contribution refers to the contribution to the development and improvement of open source software (OSS). This can take the form of providing code, documentation, tests, feedback or other types of contributions. (Google AI) -
-
-
-
- Contributor Licence Agreement (CLA) -
-
- A Contributor Licence Agreement (CLA), also known as a Contributor Agreement, is a document that sets out the terms under which intellectual property may be contributed to a project or initiative. This usually refers to a software project under an open-source licence (Wikipedia). -
-
-
-
- Core developer -
-
- Developer of an OSS project who has committer access rights to the repository. -
-
-
-
- Market analysis -
-
- A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (seehttps://perimap.admin.ch/goto_perimap_file_38221_download.html ). Possible sources of OSS software can be found in Em002-1 Practical Guidelines for OSS in Section 7. -
-
-
-
- OSS -
-
- Open source software -
-
-
-
- Product -
-
- Used here as a synonym for ‘application’.

The term originates from ITIL. In ITIL (Information Technology Infrastructure Library), a product is a configuration of resources designed to deliver value to a customer or organisation. Unlike a service, which is typically an ongoing, interactive process, a product is a static entity.

Products can be software, hardware, data or other resources provided by the organisation. (Google AI) -
-
-
-
- Product stand- -ardisation -
-
- In this document, standardisation primarily refers to SD120, the ICT standard service for office automation, and other standardisations by DTI. -
-
-
-
- Subscription -
-
- When subscribing to software, a subscription is taken out. This means that the software is not purchased.
In most cases, this involves not only permission to use the software, but also includes all relevant services and support. -
-
-
-
- Upstream project -
-
- Upstream is a term used in distributed software development (often open source) and refers to the direction of a patch to its origin (upstream), i.e. to the original developers or maintainers of the software, or to the original project. These can also be software libraries. -
-
- -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: See: and also Art. 10 EMOTA - -[^6]: SR 172.019 - -[^7]: See: - -[^8]: BBl 2022 804, p. 66 diff --git a/docs/en/em002-7.adoc b/docs/en/em002-7.adoc new file mode 100644 index 0000000..6341ece --- /dev/null +++ b/docs/en/em002-7.adoc @@ -0,0 +1,717 @@ += Em002-7 OSS Guideline: Applying Article 9 EMOTA +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +*Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. + +''' + +== Main points at a glance + +This document supplements the Em002 set of OSS tools with aspects concerning procurement. It builds on the _Information Sheet on Software Procurement and Art. 9 EMOTA_ published by the Federal Procurement Competence Centre (CCPP)footnote:[The Competence Centre for Federal Public Procurement (CCPP) advises procurement and requesting offices on matters relating to procurement law in accordance with Art. 37 OPPO. Central email address for enquiries: rechtsdienst.kbb@bbl.admin.ch] _[KBB-MB]_, and summarises the content of FOBLfootnote:[The Federal Office for Buildings and Logistics (FOBL) is the central procurement office of the Swiss Confederation (Arts 5--7 OPPO). It carries out procurement within its area of responsibility, consolidates where appropriate and may conclude framework agreements.] documents such as the _Open Source in Procurement Guidelines_ [BBL-WL], which are available on the intranet only.footnote:[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] The document also addresses digital sovereignty as a procurement criterion. + +The use of open source software can be divided into four aspects: + +* Consumption: The use of pre-existing OSS +* Creation: The development of new OSS +* Contribution Contributing in-house modifications to an existing OSS project +* Collaboration: The joint further development of OSS with third parties. + +In all these situations, a public contracting authority must comply with the relevant procurement legislation. + +*Consumption:* + +* Procurement law applies when services are purchased on the market for payment (Art. 8 PPA). + +In other words: + +* The use of OSS that is available free of charge (without licence fees, support or maintenance contracts, etc.) does not generally constitute procurement. +* Value-added services purchased for the use of OSS (support, warranty, maintenance, and further development) must be procured in accordance with procurement law. +* When procuring software, it is generally permissible to specify OSS as a requirement, e.g. where the administrative unit (AU) expects to derive specific benefits, such as greater data sovereignty or simplified compliance with Art. 9 EMOTA in the event of foreseeable bespoke adaptations. However, the market must not be unduly restricted. + +*Creation and contribution:* + +* When developing software or software components, including with a view to subsequent contribution to an OSS project, Art. 9 EMOTA must always be taken into account. Where third-party services are purchased for this purpose, procurement law applies. +* When contributing to OSS projects, the AU passes on its own work to third parties; this process is therefore not subject to procurement law. +* The acceptance of third-party contributions to a federal OSS project is likewise unproblematic from a procurement law perspective, provided no payment is made. + +*Collaboration:* + +* Collaboration between various public contracting authorities on an OSS project gives rise to a broad range of legal requirements. From a procurement law perspective, those arrangements involving the provision of services for payment require careful examination. +* In an informal collaboration, each participating party may procure or provide development services independently and then make them available free of charge. Coordination services may likewise be provided or procured. +* In a formalised collaboration, e.g. through an association of public-sector actors, the central body may also be able to provide or procure development services, provided it is itself subject to procurement law. +* Joint procurement by contracting authorities from different countries is not, however, straightforwardly permissible. + +For the sustainable use of open source software, it is important that OSS is not merely consumed, but that as many stakeholders as possible also contribute to the ecosystem. There are many ways to do this: from regular code contributions and creating documentation to funding developers, and much more. + +== Objective and purpose + +The Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/de] requires that additional considerations be taken into account when procuring newly developed software and software development services. + +To support compliance with Art. 9 EMOTA, DTI has developed tools and resources as part of link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] + +image::./assets/em002-7/media/image1.png[Overview of OSS tools] + +Figure 1: Overview of OSS tools + +This document goes beyond the core of Article 9 EMOTA and also sets out how open source should generally be handled in the context of procurement. + +Section 3:: The importance of digital sovereignty in the context of open source and procurement +Section 4:: Relevant procurement use cases in connection with software and open source software +Section 5:: Creation: Tendering for software and services in connection with Art. 9 EMOTA +Section 6:: Consumption: Software procurement: equal treatment of open source software +Section 7:: Consumption: Procurement of additional services (support/maintenance/further development) for OSS +Section 8:: Collaboration: Procurement law aspects of collaborations for the creation, maintenance and support of OSS +Section 9:: Contribution Contributing to OSS projects + +== Digital sovereignty and procurement + +=== Introduction to digital sovereignty and OSS + +Through Art. 9 EMOTA, the Federal Administration is making an important contribution to digital sustainability and sovereignty by publishing its software as OSS. + +Digital sovereignty is not an end in itself, but a prerequisite for an effective, democratic and future-oriented administration. It is a multi-faceted concept encompassing technological, organisational and political dimensions. + +[cols="1"] +|=== +| *Digital sovereignty means the state having the necessary control and capacity to act in the digital space in order to ensure that government tasks are fulfilled.* +|=== + +When procuring software in particular, consideration should be given to the implications for the digital sovereignty of the Federal Administration. + +In its *roles as user, operator and contracting authority* in the field of ICT and software, the Federal Administration can consciously fulfil its responsibilities in this area. + +There are three strategic objectives in the area of software: + +*Interchangeability*: [.underline]#As a user#, the public administration seeks to be able to choose freely and flexibly between providers, IT solutions and technologies. This requires the availability of capable and proven alternatives, and IT architectures, procurement channels and staffing that are designed to facilitate switching. + +*Design capability*: [.underline]#As an IT operator#, the public administration has the ability to shape and co-design its IT systems. To this end, it has the necessary expertise and appropriate cooperative structures to understand and evaluate IT solutions and, where necessary, ensure their development, further development and operation. + +*Influence*: [.underline]#As a contracting authority#, the public administration can articulate and enforce its requirements and needs vis-à-vis technology providers. This applies to product features (functions, operating options, availability, information security and data protection, etc.) as well as to contract design and licensing models. + +*Open standards* and *open source software* best support these goals through *open source principles*. + +OSS supports digital sovereignty in the following ways: + +* IT security for public administration, critical infrastructure and security-sensitive applications can be assured [.underline]#at all times# through [.underline]#full access# to the source code. +* OSS enables public bodies to build, operate, control and adapt their own IT infrastructure without restrictive licence conditions. +* OSS provides full control over updates, features and security patches, in terms of both content and timing. +* OSS can prevent dependence on individual vendors or licensing models and supports interchangeability. +* OSS allows the entire software supply chain to be displayed and traced transparently. +* OSS can be customised and expanded -- well suited to the specific requirements of public authorities and educational institutions, though this requires in-depth knowledge on the part of an organisation's own employees. +* Investment in OSS also benefits local businesses and communities (local value creation), increasing the resilience of the Swiss economy. +* OSS is based on collaboration and open interfaces, facilitating interoperability between systems and promoting open standards -- even across national borders. +* OSS improves IT security and data security through transparency and adaptability. +* OSS software licensed under OSI licences guarantees clear legal conditions and continuity, along with the fundamental freedoms of OSS, protecting developers and users alike. + +*Open standards:* To support software interchangeability, public procurement tenders should require compliance with open standards,footnote:[For example, open standards such as eCH, ODF; see also https://en.wikipedia.org/wiki/Open_standard[Open standard -- Wikipedia]] thereby minimising lock-in. +*Open interfaces:* Interfaces should likewise be disclosed to enable interoperability. + +Federal authorities are generally required to comply with the eCH standards.footnote:[https://www.ech.ch/[www.ech.ch]] + +The Bern University of Applied Sciences set out the relevant considerations in the study _Technological Perspectives of Digital Sovereignty_ [Stü2024], commissioned by the FDFA, using the 'sovereignty house' model, in which software is presented as a key pillar. + +image::./assets/em002-7/media/image2.png[Schematic representation of the aspects of digital sovereignty enabling the provision of innovative products and services] + +_Figure 2: Schematic representation of the aspects of digital sovereignty enabling the provision of innovative products and services [Stü2024]_ + +=== Measuring digital sovereignty + +Aspects of digital sovereignty may be required in a public tender, but any such requirements must be objectively justified. There is no general preference for OSS. + +*How, then, can the degree of digital sovereignty be measured for a given technology, product or service?* + +This operationalisation must be made as objective and transparent as possible. + +Various initiatives are attempting to do this. The OSBA, for example, has developed a *sovereignty index*footnote:[https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet[An index for digital sovereignty | OSBA -- Open Source Business Alliance]] _[OSBA-VK]. Nextcloud_ has published a Digital Sovereignty Index (DSI),footnote:[https://dsi.nextcloud.com/[dsi.nextcloud.com]] which compares entire countries but can also provide useful criteria. +The European Union has published a Cloud Sovereignty Frameworkfootnote:[https://commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en?filename=Cloud-Sovereignty-Framework.pdf[commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en?filename=Cloud-Sovereignty-Framework.pdf]] for the cloud. +The _Centre for Digital Sovereignty ZenDiS_ is working on a sovereignty check designed to evaluate IT solutions and organisations against transparent sovereignty criteria. + +The Federal Administration is also involved in developing a *digital sovereignty framework* that will, among other things, enable the degree of fulfilment to be determined across a range of perspectives. + +Possible perspectives include: + +[cols="1,2,4",options="header"] +|=== +|# |Perspective |Description + +|A +|Technological control +|To what extent does the Federal Administration have control over the technologies used and their further development? + +|B +|Data sovereignty +|Who has access to, control over and decision-making power regarding the data -- particularly sensitive administrative data? + +|C +|Legal capacity to act +|To what extent can Switzerland and the Federal Administration influence the legal and political framework for digitalisation? + +|D +|Resilience +|How robust and crisis-proof are the Federal Administration's digital systems and processes in the face of disruptions, crises and dependencies? + +|E +|Economic control +|How can the Federal Administration exercise economic control and strategic sourcing to secure its digital sovereignty cost-efficiently, while minimising dependencies and risks in IT procurement? +|=== + +For each of these perspectives, the degree of digital sovereignty can be determined against a scale to be defined: + +image::./assets/em002-7/media/image3.png[Degree of digital sovereignty] + +Figure 3: Degree of digital sovereignty. + +These two dimensions produce the following matrix: + +image::./assets/em002-7/media/image4.png[Matrix Digital Sovereignty] + +Figure 4: Matrix Digital Sovereignty. + +Specific criteria can be described in the individual intersections (grey fields) to make the classification as objective as possible. + +Such a framework is currently being developed as part of Priority 4, 'Strengthening digital sovereignty', of the 'Digital Federal Administration Strategy'.footnote:[https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html[www.bk.admin.ch -- Digitale Bundesverwaltung]] + +The Federal Council brought the umbrella directive Digital Sovereignty in the Federal Administrationfootnote:[W012 - Directives for Digital Sovereignty in the Federal Administration] into force on 1 January 2026. Projects must incorporate the various aspects into the definition of the procurement object and, where necessary, into a tender, on the basis of the specific sovereignty requirement -- for example from a risk perspective in the context of business continuity management. + +== Use cases for software procurement + +Information and communication technology (ICT) and software are not an end in themselves in the Federal Administration, but always serve to fulfil a legal mandate. Given advancing digitalisation and the Federal Administration's central role in Switzerland, information technology must be a core competence of the administration. + +The following *factors* therefore have a direct bearing on procurement: + +* *Digitalisation*: The digital strategyfootnote:[https://digital.swiss/en/] calls for the digitalisation of processes. +* *Process optimisation*: Processes within the Federal Administration and in its external relations can and should be optimised. +* *Digital sovereignty*: The importance of digital sovereignty is growing steadily; see _[Stü2024]_. +* The principle of *public money, public goods* and compliance with Art. 9 EMOTA. +* *Economic freedom*: Measures should not unnecessarily restrict economic freedom. +* General *security* considerations: The security of information processing systems is of increasing importance. +* Crisis and disaster management (*resilience*): Given the current global situation, the administration must consider how it can continue to provide the necessary working tools under critical circumstances. +* Strategic independence and *supply chain* considerations: These follow from digital sovereignty and resilience. +* Avoiding/minimising *vendor lock-in*: Dependencies are almost impossible to avoid in IT, but reliance on a single vendor should be reduced wherever possible. +* *Empowering* the Federal Administrationfootnote:[Not only among managers, project managers and ICT architects, but across all staff.] (including management) in ICT matters: Controlling, developing and operating information technology requires appropriate skills across the workforce. + +This document distinguishes between *software types* as follows: + +* *Commodity -- Specialised applications/Industry -- Specialised applications/Federal authority*: +** Standard application (commodity software) without special business logic. +** Specialised application: Specific requirement of the industry/all federal levels or specific requirement of the federal authority +* *Targeted -- strategic -- essential*: +** Targeted application +** Strategic application with significant importance for a federal authority or the Federal Administration as a whole +** Essential and business-critical -- must remain functional in all circumstances (e.g. air traffic control) + +Applications may be used across one or more *fields of application*. + +What matters here is the *standardisation* of applications by product within each area: + +* No strategy +* Single-product strategy +* Multi-product strategy + +In addition to product standardisation, which must be examined carefully, there is also standardisation for interoperability (data formats, API, business elements).footnote:[E.g. via eCH] +Standardisation _is permissible_ provided it is proportionate and does not unduly restrict competition (e.g. Art. 30 para. 3 PPA). It may reduce operating and maintenance costs and generate synergy effects, particularly where all federal levels are involved. On the other hand, it increases lock-in, dependency and, in some cases, security risks (cluster risk). + +Total costs of ownership (TCO) -- covering operation, maintenance and further development -- should always be considered in procurement. Long-term cost implications must not be overlooked. Open source business models differ in certain respects from those of proprietary providers. + +The following sections focus increasingly on open source, discussing the relevant procurement approach and how it should be implemented. + +The choice between consumption, contribution, collaboration and creation is made _on a project-specific basis_ according to economic efficiency and the legal situation, with costs distributed as broadly as possible. From this perspective, the four Cs as defined in link:em002.adoc[Em002 OSS Strategic Guidelines], Section 3, are ranked in descending order of importance: + +image::./assets/em002-7/media/image5.png[Ranking of the four Cs: Consumption, Contribution, Collaboration, Creation] + +. Consumption +. Contribution +. Collaboration +. Creation + +With simple *consumption*, costs are spread across a large number of other users, but the federal authority has no control over further development. Creation is the inverse: full control, but full cost. + +With *contribution*, financial outlay is limited to the element developed, which is then handed over to another organisation for maintenance. + +*Collaboration* is the most complex scenario, as arrangements can vary considerably. In the best-case scenario, costs are shared and the federal authority has sufficient influence to implement its requirements without compromise (see Section 8). + +Ideally, *creation* accounts for the smallest share. Software may be developed in-house, through services, or via a contract for work. + +Pure consumption will only be feasible for standard applications. + +=== Software requires additional services such as maintenance, support and further development. + +Although open source applications can be used free of charge, their strategic deployment across thousands of instances requires maintenance, support and, where necessary, further development. + +Federal authorities have an interest in long-term support for deployed versions (see Section 3.2.3 in _[BITKOM2024]_). + +Art. 9 EMOTA itself covers only the in-house development or further development of software and is not relevant to any other open source considerations -- digital sovereignty and other factors apply instead. However, restrictions under Art. 9 EMOTA on individual development components may have repercussions for the overall project where proprietary or additional developments are foreseeable. Collaboration can then be used to exploit synergy effects and, where possible, reduce costs across the Federal Administration as a whole. + +=== Publication requirement for software procurement + +Where requirements indicate a need to adapt software, or a potential need for later adaptation, Art. 9 EMOTA is relevant and publication is mandatory for those parts, unless one of the two exceptions applies. When procuring an open source solution, such publication would already be addressed through a contribution to the open source project. Even where procurement involves only the licensing of standard software or ICT procurement falling under an exemption, any additional developments must in principle be published, and this must be reflected in the procurement documents and draft contract. + +*The publication requirement under Art. 9 EMOTA is therefore relevant to any procurement where in-house development or further development is likely* (see also _[KBB-MB]_). + +== Creation: Tenders for software and services involving Article 9 EMOTA + +This section addresses the implications of Art. 9 EMOTA for tenders for software and services that may involve the creation or modification of software. + +It applies to both centralised and decentralised Federal Administration. Exceptions to this requirement are set out in the Digitalisation Ordinance _[DigiO]_. + +=== Relevance of Article 9 EMOTA for software creation + +A transaction falls within the scope of Art. 9 EMOTA if it falls within the relevant category of Table 1. The make-or-buy decision remains central to procurement. Analysis of the various use cases shows that, in principle, Art. 9 EMOTA is relevant in principle in all cases, except where pre-existing software is being procured (e.g. pure licences). Section II.4 of the _Open Source in Procurement Guidelines [BBL-WL]_ sets out the strategic approach, and Annex VII.A describes in detail what constitutes software. A detailed breakdown of the strategic decision is provided in Table 1. + +[cols="3,2,4",options="header"] +|=== +|Use case |Make or buy |Publication obligation under Art. 9 para. 1 EMOTA + +|Developing software within the Federal Administration +|Make +|Yes, publication obligation + +|Having software developed by third parties +|Buy as IT service contract +|Yes, publication obligation + +|Procuring existing software +|Buy +a|Generally no, but check whether publication requirements apply to any parts being developed. Handling of third-party rights is particularly relevant (see link:./em002-3.adoc[Em002-3 OSS Licensing Guidelines]). + +|Acquiring software from other public bodies +|Make or buy +a|-- Within the Federal Administration: publication obligation for the transferring administrative unit. + +-- Others: Examine on a case-by-case basis whether adaptations by the Federal Administration give rise to a publication obligation, at least for those parts. + +|Procuring development resources +|Make +|Yes, publication obligation (contracts must allow for publication) + +|Collaborating with other public bodies on software development +|Make +|Yes, publication obligation (contracts must allow for publication), particularly where there are substantial development contributions by or for the Confederation +|=== + +_Table 1: Classification of publication requirement and make-or-buy decision (based on a table by Rika Koch, BFH)_ + +NB: Art. 9 EMOTA must also be taken into account for existing software and SaaS where the software is to be further developed or adapted for the federal government. Even where the likelihood of this is low, it should be addressed in the procurement process. + +Where clarification is needed, the recommended reference is link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. The checklists should be *completed provisionally as early as possible* for potentially relevant projects. The _Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL]_ may also be used for this purpose. + +=== Preparing a procurement under Article 9 EMOTA + +In addition to the usual preparatory steps, the following two documents should be consulted whenever a procurement involves software components: + +* _Information sheet on software procurement and Art. 9 EMOTA [KBB-MB] and_ +* _Open Source in Procurement Guidelines [BBL-WL]_. + +Where Art. 9 EMOTA is clearly relevant, the administrative unit should have: + +* provisionally completed the checklists link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] through to link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]; +* taken a basic decision on whether to use a copyleft or permissive licence;footnote:[A more detailed analysis can be carried out later using _Em002-3 OSS Licensing Guidelines_ if needed).] +* searched for possible open source alternatives (or potential base projects for contributions/collaboration) in accordance with link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software], using the tools specified therein for market research/market analysis;footnote:[See also link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration], Section 7.] +* clarified the structure of any relevant community (link:em002-4.adoc[Em002-4 OSS Community Guidelines] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]). + +Where an existing OSS project is to be used, supported or built upon through collaboration, Sections 5, 0, 8 and 9 of this document must be read. + +=== Creation via existing service contracts + +Where creation is handled via existing partner agreements, OSS publication must be ensured at the mini-tender stage, unless one of the two exceptions applies. + +New service tenders should always include a requirement for publication in accordance with Art. 9 EMOTA (see _[BBL-WL] and_ _[KBB-MB])_. + +=== Building a community + +Building and maintaining a community maximises the benefits of open source software, but also involves considerable effort. + +Where a community and collaboration make sense, this has implications for procurement from the outset. link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community] should therefore be completed on the basis of the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. + +Where the federal authority is to take on a significant role in the community (e.g. a governance role) or where collaboration is planned (see Section 8), it may be necessary to procure additional services: community building, consolidation of requirements, management of further development. + +=== Sample criteria and contract elements for IT procurement + +The CCPP maintains a template of possible procurement criteria and a framework agreement chapter template for software-related tenders _[KBB-KV]_. + +The CCPP has published two template documents on Perimap.admin.ch showing how the minimum requirements for a procurement-compliant acquisition under Art. 9 EMOTA can be met. [KBB-KV] + +. https://perimap.admin.ch/goto_perimap_file_47064_download.html[Sample criteria -- Procurement EMOTA and Open Source] +. https://perimap.admin.ch/goto_perimap_file_47059_download.html[Sample contract texts -- Software development] + +== Consumption: Software procurement: Equal treatment of open source software + +This section addresses the procurement and use (consumption) of open source software, highlighting key strategic aspects. +Reference is also made to _[BBL-WL] and_ _[KBB-MB]_. + +*There is currently no legally prescribed preference for open source software in procurement.* + +When tendering for IT applications, all licence types and business models are considered. To meet the stated requirements, providers may offer software solutions based on unmodified open source, closed source or proprietary software, or on combinations of licence models and value-added services or subscriptions. + +The following pointsfootnote:[The primary procurement reference documents are those published by the FOBL and CCPP on the relevant platforms.] should be taken into account by federal authorities: + +* Regardless of its solution and licensing model, the service provider must specify in its tender *which licence conditions the service procurer must comply with when using the service*. +* The service provider is *free to choose the solution* with which it intends to meet the advertised requirements and the form of remuneration it wishes to receive (licence, maintenance or subscription fees), provided this is technically feasible and economically reasonable. +* The full *lifecycle* should be taken into account in the specifications and pricing. + +This enables the Federal Administration to assert its interests regarding intellectual property, warranty and liability -- independently of the software or licence model -- at the level of the applicable general terms and conditions, and to enshrine these in the contract. + +Where *software adaptations* are made on behalf of or in fulfilment of a contract with the federal authority, Art. 9 EMOTA applies. +As a precaution, publication approval should be requested in the tender, since experience shows that adaptations are usually required sooner or later, even if not foreseeable at the time of tendering. + +Where the service procurer procures *value-added services* from a provider in addition to the software, OSS suppliers often offer a subscription model that provides a local contact with warranty and liability commitments, alongside the direct relationship with the intellectual property holders of the OSS components (who are often based abroad and sometimes unknown). + +=== OSS as a strategic procurement criterion + +Where a federal authority wishes to procure open source software for strategic reasons, several scenarios are possible: + +* Functional invitation to tender without OSS-specific criteria. +As this involves no restrictions, no special justification is required. +* Functional invitation to tender with eligibility criterion, technical criteria and award criteria requiring open source, full access to source code, or demonstrable experience in open source publication. + +*Any preference for open source is permissible under procurement law where it allows the specific needs of the awarding office to be (better) met*.footnote:[See [BBL-WL], [BBL-CL], [KKB-MB], [KBB-KV]] + +A further reason for favouring OSS -- beyond digital sovereignty -- is that where the administration requires significant software adaptations, these must be published under Art. 9 EMOTA. +Publication is most straightforward when the entire product has always been open source, and adaptations can in some cases be made directly within the product. Otherwise, an exception must be defined and, where necessary, parts of the code must be isolated and still released. + +=== The use of OSS without payment is not subject to procurement law. + +OSS can often be downloaded and used directly. Procurement law applies only where services are obtained from third parties in return for payment (including non-monetary consideration). + +Downloading and using OSS free of charge does not in itself constitute procurement. + +It is also possible to procure the necessary services for downloaded OSS at a later stage, provided this is not done abusively.footnote:[Analogy: A commune may use its own timber and commission construction of a maintenance depot using that timber -- it is not required to procure the timber itself.] + +Maintenance, support and further development services for the product are then tendered separately in accordance with procurement law. + +There are already examples of OSS being used free of charge on the Federal Administration's standard workstations and therefore not procured.footnote:[Examples of OSS with standardisation potential: Gimp, FileZilla, VLC Media Player and 7-zip as Shell 2 products (according to [A029]), which can be used because installation is free of charge. In 2024, BIT designated Red Hat OpenShift as a strategic product for certain application areas on the basis of its unique technical features. OpenShift is currently the strategic platform for containers and operating systems.] + +=== Coordinating requirements with other stakeholders + +A specialised application always requires a requirement owner (usually a federal office). It generally makes sense for the body with the need to harmonise its requirements with those of other government agencies --- either internally or through collaboration (see Section 8) --- to the extent that an available market product or a collaborative development is conducive to development and rollout. + +Where many stakeholders have the same or similar requirements, it may be worth meeting those needs on a common basis. This applies to all forms of software. + +Two aspects should be noted: where adaptations are subsequently made by a federal authority at the request of third parties, Art. 9 EMOTA applies again -- though this is unproblematic where open source software is used. + +With OSS, requirements may need to be aligned more actively by the federal authority, since there may be no driving force such as a commercial vendor seeking to steer and develop its own product. + +=== Considering other potential public actors in procurement + +The ZenDiSfootnote:[https://www.zendis.de/en[https://www.zendis.de/] ZenDiS's stated mission is to enable the administration to break free from critical dependencies on individual technology providers.] example shows that it can be both feasible and worthwhile to issue a tender covering all federal levels simultaneously. + +*Fair competition must always be maintained.* When issuing tenders, consideration should always be given to whether the solution might usefully be procured for other bodies as well. + +Where this is the case, those potential additional clients should be contacted and their needs reflected in the tender documents, particularly the requirements. A degree of flexibility in the requirements is important in such cases. + +Example: eOperations Switzerland Ltd (http://www.eoperations.ch[www.eoperations.ch]) can be used for such collaborations. eOperations consolidates requirements from various agencies and conducts procurement itself, without necessarily using the product itself. This may also be a useful model for OSS procurement. + +== Consumption: Procurement of support and maintenance for OSS + +Public administration can use open source software in various ways, from simple download and installation through to formal procurement (see Section 6.2). + +Where OSS is deployed in critical areas, consistently high standards of security,footnote:[See also link:em002-6.adoc[Em002-6 FAQ-OSS], Section 5.3] maintenance and further development are required. In regular software procurement, this is usually covered by the tender. The requirements apply to both the software itself and to the relevant libraries and frameworks used. Support and maintenance warrant particular attention, since further development is often covered under the same contract and in any case constitutes creation and therefore falls within the scope of Art. 9 EMOTA. + +These labour-intensive services almost always exceed the threshold value under the Public Procurement Act (PPA) when calculated over the application lifecycle. Where they are purchased from third parties, procurement law must be complied with. Exceptions may apply, such as in-state procurement from another public contracting authority,footnote:[Art. 10 para. 3 let. b PPA.] or in exceptional cases direct procurement of specialist services.footnote:[Art. 21 para. 2 let. c PPA.] + +The following table sets out the case distinctions for the procurement of services such as support. + +[cols="1,1,1,2"] +|=== +2+h|Background 2+h|Results + +h|Lifecycle costs + +→ WTO threshold?footnote:[Internal costs may be excluded. Full life cycle must be considered.] +h|In-state?footnote:[In-state procurement is not subject to tendering: state sponsorship required, no market participation. Applies only within the Swiss public sector.] +h|WTO tender required?footnote:[Federal procurement guidelines always apply where any payment is made.] +h|Comments + +|No +|No +|No footnote:[Software with support generally exceeds the PPA threshold; 'no' will only apply in rare cases (e.g. financing a single feature for an existing OSS project).] +.2+|Rarely a complete software package with support -- mostly minor support and individual features. + +|No +|Yes +|No + +|Yes +|No +|Yes +|Only the volume to third parties is relevant. + +|Yes +|Yes +|No +|The tender was issued by the other public body. +|=== + +_Table 2: Case distinction -- procurement of support_ + +=== Support and maintenance are always part of software + +Support and maintenance are essential for the sustainable operation of software in a public authority environment. In a world of zero-day exploits,footnote:[A zero-day exploit refers to the exploitation of a security vulnerability for which no patch is yet available from the component developer.] rapid and professional patch deployment is critical. This 'infrastructure' must be funded -- particularly since the administration has higher requirements than a private consumer. + +*The question is therefore not IF support and maintenance will be required, but HOW they are to be provided.* + +The federal authority must determine what level of support, maintenance, warranty and liability it requires based on its quality of service requirements. + +It is important that any service provider for maintenance and support can demonstrate sufficient experience with the product or the relevant open source community -- only then will it be able to fulfil these tasks effectively (see also _[KBB-MB]_, II.5).footnote:[The service contract may also need to cover the potential transfer of knowledge to a successor organisation.] + +Support and maintenance must also be funded at the product level. Where no one contributes (the free-riderfootnote:[https://en.wikipedia.org/wiki/Free-rider_problem] problem), the project's future is jeopardised, and with it its use within the Federal Administration. Given its scale, the Federal Administration can reasonably be expected to contribute to the costs of software it deploys strategically. + +=== Organisations that can provide support + +The quality of support has a direct impact on end-user satisfaction and productivity. A structured support system with fast response times and genuine technical expertise ensures that users and administrators receive effective solutions to their issues, saving the contracting authority's working time and promoting acceptance of the software solution. + +To meet contractually agreed response times under service level agreements (SLAs), the provider must have qualified staff with the necessary expertise. + +Possible sources of support include: + +*In-house*: + +* Federal offices +* Service providers + +*In-state*: + +* Other public contracting authorities in Switzerland +* Services procured by other public contracting authorities in Switzerland + +*Third parties*: + +* Procured service + +=== Further development for specific features + +Where a federal authority requires only a limited number of specific enhancements to a piece of open source software, this can be done using internal resources or procured services. + +Such further developments should aim to be offered back to and integrated into the original project. This not only benefits the project ecosystem but ensures the enhancements are maintained within the project going forward. Without this, each new release of the original project may require the bespoke development to be updated manually (see also Section 8). + +=== Subscription + +Many companies and projects in the open source environment offer free support within certain limits, provided voluntarily by any user, mainly through open channels such as forums and public ticket systems. This free offering is not designed for professional users with specific SLA requirements. + +For professional users such as federal authorities, OSS subscriptions that include warranty, maintenance and support are often available. + +Some providers also offer special 'enterprise versions' that no longer meet the OSI's open source criteria. + +Examples of subscriptions: OpenShift from Red Hat, openDesk from ZenDiS + +=== Certifications in the open source sector and OpenChain + +As with proprietary software, various certifications exist in the open source sector. It may be worthwhile for the administration to check for potentially relevant certifications in the area covered by the tender before issuing it. + +*OpenChain* is an ISO standard addressing open source development and licence compatibility (see below). + +Where relevant certifications exist and are pertinent to the service, they should be taken into account in the assessment of providers. It is important that the certification itself is considered meaningful, and that providers can demonstrate they are able to deliver the service even without certification. + +Given the complexity involved, requiring certifications as an eligibility criterion is inadvisable. As an award criterion -- with the possibility of demonstrating compliance with certification content through references -- they may be appropriate depending on the OSS product, provided it is permissible to use references to demonstrate that certification criteria are being met.footnote:[NB: Requiring a certification that is excessive or ill-suited to the subject of the tender will inevitably produce less competitive bids.] + +Self-certification under OpenChain may at best serve as a substitute where no other certification exists. References addressing the relevant criteria can also stand in for missing certifications. + +*Certification of partner companies* + +Some open source developers and projectsfootnote:[such as Nextcloud or Univention] certify partner companies with which they collaborate. Such certifications can demonstrate an existing relationship between the provider and the software developer. Note that many OSS projects do not offer such certifications. Proven collaboration in reference projects is an equally valid -- and less restrictive -- indicator of the desired quality. + +*Certification of employees* + +Some open source manufacturers or communitiesfootnote:[such as LibreOffice or RedHat] certify individuals with specialist expertise in the relevant software. Where a service provider employs certified staff, this can demonstrate expertise in upstream publication of adaptations and patches, and in providing high-quality third-level support -- particularly where several staff members work with the product. This also depends on the structure of the OSS project's ecosystem. + +As an alternative to certifications, demonstrable project experience in references relating to the procurement subject can also serve as a differentiating criterion. + +*OpenChain standard* + +The OpenChain standard represents both best practice in licence compatibility and a certification of interest to procuring authorities. + +ISO/IEC 5230 'OpenChain' focuses on software supply chains, streamlined procurement and licence compliance. The OpenChain standard can be awarded by an accredited certification body or obtained through self-certification. This certification is suitable for demonstrating in general terms that a provider has already dealt extensively with open source licence requirements and the specifics of the open source ecosystem. +Since the creation of a Software Bill of Materials (SBOM) is part of the standard, this certification also evidences a supplier's commitment to supply chain security through support of foundational components. + +=== Further options for procuring maintenance, support or further development services + +It makes sense to handle further development services under the same contract as support and maintenance, since the distinction is not always straightforward and is often not practical in the context of open source software. Further developments funded by a federal authority fall within the scope of Art. 9 EMOTA. + +The following options are currently availablefootnote:[Other, more niche options may also exist.] for procuring support, maintenance and/or further development services for OSS: + +* In-house, with competence building: Deploy own development resources +* Procurement: According to volume and in compliance with the PPA. This may also be done via service contracts already put out to tender. To ensure that strategic partners can provide experienced core developers for OSS projects central to the Federal Administration, it may be worth permitting subcontracting or requiring the relevant expertise in certain tenders. +* Cooperation agreements with third parties for maintenance, support or further development: unproblematic as long as each party bears its own costs. +* Federal participation in organisations: unproblematic as long as each party bears its own costs. + +== Collaboration: Procurement law aspects of collaborative creation, maintenance and support of OSS + +The costs of open source software decrease when it is developed collaboratively, whether informally or through a structured arrangement. link:em002-4.adoc[Em002-4 OSS Community Guidelines] sets out the relevant approaches. + +Collaboration with other public contracting authorities or third parties is unproblematic under procurement law as long as each party bears its own costs. Difficulties arise where the collaboration does not result in OSS, since the Federal Administration is bound by Art. 9 EMOTA. + +Such cooperation is permitted under Art. 4 EMOTA. + +The question of how to handle overheads or a centralised structure must be addressed: the structure needs sufficient funding to sustain the project through difficult periods. An alternative is a single managing partner (e.g. if one participant is large enough to take on the coordination role). Where the federal authority assumes this role, the relevant services must be provided in-house or tendered in the normal way if third parties are to be engaged. + +At the contractual level, the following applies to collaborations: + +* Where no money changes hands and no formal obligations are required, a Memorandum of Understanding at the level of the federal office or Federal Chancellery is possible. +* The establishment of a joint structure -- such as an association or public-law corporation -- is possible in principle but must be assessed on a case-by-case basis. Where the joint structure is itself to procure services from third parties, the application of procurement law must be regulated. + +Membership may in some cases be exercised through other organisations such as eOperations or eCH. + +*Cooperation with foreign countries* + +Cooperation with foreign authorities is unproblematic as long as no money changes hands and no obligations of any kind are entered into. + +Cooperation agreements at the appropriate level are possible in principle but must be assessed case by case. +International treaties should be avoided given the high hurdles involved, though they would in principle also be possible. + +Two special casesfootnote:[https://www.eda.admin.ch/deza/en/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] exist where collaboration would already be covered: + +* Contracts awarded under an international agreement for the joint implementation of a project by signatory states. +* Contracts awarded in accordance with the special procedures or conditions of an international organisation. + +== Contribution: Contributing to OSS projects + +Most of the characteristics and legal considerations relating to contributions are covered in link:em002-4.adoc[Em002-4 OSS Community Guidelines]. + +From a procurement law perspective, contributions are generally unproblematic, since the services are provided to develop code for a project that is either of direct relevance to the authority or has already been addressed from a procurement law standpoint. + +*Contributions from third parties to OSS projects run by federal authorities are also unproblematic under procurement law, as long as no money changes hands.* + +Note: Since the federal authority is obliged to publish software it develops, it must also ensure that it remains published. If an OSS project is taken down by its operators, the federal authority may in the worst case need to republish it independently. In practice, the source code typically remains available (e.g. as an archive), the project continues as a fork, or the project -- and with it the source code -- has simply become irrelevant. + +== Annex A: References: + +A significant portion of the references are _already mentioned in Em002 Strategic Guidelines for Open Source Software in the Federal Administration_. + +[cols="1,4"] +|=== +|[A029] +a|Product standard for office automation (OA) client software + +Intranet: +https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/standards/a029-bab_client_software.html+ + +|[BBL2015] +|Information sheet: Software tenders: Ensuring broad competition; 2015; no longer in force + +|[BITKOM2024] +|Open Source Software 2.0 Guidelines. Berlin: Bitkom e. V. Bundes-verband Informationswirtschaft, Telekommunikation und neue Medien e. V. BIT-KOM. 2024. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html + +|[BöB] +|Federal Act on Public Procurement (PPA) https://www.fedlex.admin.ch/eli/oc/2020/126/de + +|[DigiV] +|Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) SR 172.019.1 -- Ordinance of 2 April 2025 \| Fedlex + +|[BBL-WL] +a|Open Source in Procurement Guidelines: Software purchasing in accordance with Art. 9 EMOTA; FOBL; on the intranet: +https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html+ + +|[BBL-CL] +a|for Art. 9 EMOTA Blanket Exception, FOBL, on the intranet: +https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html+ + +|[KKB-MB] +a|Information sheet: Procurement of software and Art. 9 EMOTA of the Competence Centre for Federal Public Procurement: +https://perimap.admin.ch/goto_perimap_file_46835_download.html+ + +|[KBB-KV] +a|Sample criteria -- Procurement and EMOTA. +https://perimap.admin.ch/goto_perimap_file_47064_download.html+ + +Sample contractual texts -- Software development +https://perimap.admin.ch/goto_perimap_file_47059_download.html+ + +|[KBB-Perimap] +|CCPP learning and template platform + +|[OSBA-VK] +|Award criteria for sustainable procurement of open source software \| OSBA -- Open Source Business Alliance + +|[Sto2024] +|Certificate of competency 3 on Procurement-related criteria in relation to the new _Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) based on Art. 9 (open source software)_ by Reto Stoll, 2024 + +|[Stü2015] +|Open source business model: Added value of the subscription offer, Matthias Stürmer, 2015 + +|[Stü2024] +|Technological Perspective on Digital Sovereignty, Matthias Stürmer, 2024, https://arbor.bfh.ch/entities/publication/b77d2f8b-4148-4325-82cd-405fa077a28a + +|[SIK] +a|SIK for procuring open source software: +https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/+, 2015 + +|[W012] +|W012 -- Directives for Digital Sovereignty in the Federal Administration, V1.0 2025 +|=== + +== Annex B: Glossary + +This glossary covers specific terms related to procurement topics. + +The general glossary for the Em002 document set can be found in Em002-6 OSS-FAQ. + +Further terms can be found in the terminology database TERMDAT https://www.bk.admin.ch/bk/en/home/dokumentation/languages/termdat.html[terminology database of the Federal Administration]. + +[cols="1,4"] +|=== +|Application area +|This refers to the office automation (OA) software categories according to [A029] and other classifications. + +|Branch +|A development branch of an OSS. + +|CCPP +|Competence Centre for Federal Public Procurement + +|Collaboration +a|The term collaboration derives from the Latin word 'collaborare' and means 'to work together'. +It describes a way of working in which several people or teams work together towards a common goal, contributing their skills and resources. The focus is on mutual exchange, transparency and the sharing of knowledge. + +According to the Gabler Business Dictionary, collaboration also refers to 'cooperation between a company and its customers and suppliers, using modern information technologies to integrate internal and cross-company business processes.' + +|Committer +|A committer is a person who enters a change to data in a version control system. + +|Contribution +|OSS contribution refers to the contribution to the development and improvement of open source software (OSS). This can take the form of providing code, documentation, tests, feedback or other types of contributions. (Google AI) + +|Contributor Licence Agreement (CLA) +|A Contributor Licence Agreement (CLA), also known as a Contributor Agreement, is a document that sets out the terms under which intellectual property may be contributed to a project or initiative. This usually refers to a software project under an open-source licence (Wikipedia). + +|DTI +|Digital Transformation and ICT Steering Sector. Part of the Federal Chancellery FCh + +|eOperations +|eOperations Switzerland enables joint digital public services for the federal government, cantons and communes. https://www.eoperation.ch[www.eoperation.ch] + +|FITSU +|Federal IT Steering Unit. Predecessor of FCh-DTI + +|FOBL +|Federal Office for Buildings and Logistics + +|Life cycle +|A software life cycle describes the process of software development with the aim of providing software to the customer. As a rule, the cycle begins with a problem identified by the customer and its analysis, and ends on the customer side with the replacement of the software by a successor. + +|Lock-in +|The lock-in effect refers to close customer loyalty to products/services or a provider or vendor, which makes it difficult for the customer to switch products or providers due to the costs and other barriers involved in switching. + +|Market analysis +a|A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html). + +Possible sources of OSS software can be found in link:em002-1.adoc[Em002-1 Practical Guidelines for OSS] in Section 7. + +|Product +a|Used here as a synonym for 'application'. + +The term originates from ITIL. In ITIL (Information Technology Infrastructure Library), a product is a configuration of resources designed to deliver value to a customer or organisation. Unlike a service, which is typically an ongoing, interactive process, a product is a static entity. + +Products can be software, hardware, data or other resources provided by the organisation. (Google AI) + +|Product standardisation +|In this document, standardisation primarily refers to SD120, the ICT standard service for office automation, and other standardisations by DTI. + +|SBOM +|A Software Bill of Materials (SBOM) is an inventory list of all components and software dependencies that are part of the development and deployment of a piece of software. + +|Subscription +|When subscribing to software, a subscription is taken out. This means that the software is not purchased. + +In most cases, this involves not only permission to use the software, but also includes all relevant services and support. + +|Upstream project +|Upstream is a term used in distributed software development (often open source) and refers to the direction of a patch to its origin (upstream), i.e. to the original developers or maintainers of the software, or to the original project. These can also be software libraries. + +|ZenDiS +|ZenDiS is a publicly owned limited liability company (GmbH) in Germany. It supports the federal government, states, and municipalities in implementing digital sovereignty. With opdencode.de and container.gov.de, it offers a platform for secure open-source development. (https://www.zendis.de[www.zendis.de]) + +|Zero-day exploit +|A zero-day exploit refers to the exploitation of a security vulnerability for which no patch is yet available from the component manufacturer. +|=== diff --git a/docs/en/em002-7.md b/docs/en/em002-7.md deleted file mode 100644 index 037fa1c..0000000 --- a/docs/en/em002-7.md +++ /dev/null @@ -1,1213 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# Main points at a glance - -This document supplements the Em002 set of OSS tools with aspects concerning procurement. It builds on the *Information Sheet on Software Procurement and Art. 9 EMOTA* published by the Federal Procurement Competence Centre (CCPP)[^7] *[KBB-MB]*, and summarises the content of FOBL[^8] documents such as the *Open Source in Procurement Guidelines* [BBL-WL], which are available on the intranet only.[^9] The document also addresses digital sovereignty as a procurement criterion. - -The use of open source software can be divided into four aspects: - -- Consumption: The use of pre-existing OSS - -- Creation: The development of new OSS - -- Contribution Contributing in-house modifications to an existing OSS project - -- Collaboration: The joint further development of OSS with third parties. - -In all these situations, a public contracting authority must comply with the relevant procurement legislation. - -**Consumption:** - -- Procurement law applies when services are purchased on the market for payment (Art. 8 PPA). - -In other words: - -- The use of OSS that is available free of charge (without licence fees, support or maintenance contracts, etc.) does not generally constitute procurement. - -- Value-added services purchased for the use of OSS (support, warranty, maintenance, and further development) must be procured in accordance with procurement law. - -- When procuring software, it is generally permissible to specify OSS as a requirement, e.g. where the administrative unit (AU) expects to derive specific benefits, such as greater data sovereignty or simplified compliance with Art. 9 EMOTA in the event of foreseeable bespoke adaptations. However, the market must not be unduly restricted. - -**Creation and contribution:** - -- When developing software or software components, including with a view to subsequent contribution to an OSS project, Art. 9 EMOTA must always be taken into account. Where third-party services are purchased for this purpose, procurement law applies. - -- When contributing to OSS projects, the AU passes on its own work to third parties; this process is therefore not subject to procurement law. - -- The acceptance of third-party contributions to a federal OSS project is likewise unproblematic from a procurement law perspective, provided no payment is made. - -**Collaboration:** - -- Collaboration between various public contracting authorities on an OSS project gives rise to a broad range of legal requirements. From a procurement law perspective, those arrangements involving the provision of services for payment require careful examination. - -- In an informal collaboration, each participating party may procure or provide development services independently and then make them available free of charge. Coordination services may likewise be provided or procured. - -- In a formalised collaboration, e.g. through an association of public-sector actors, the central body may also be able to provide or procure development services, provided it is itself subject to procurement law. - -- Joint procurement by contracting authorities from different countries is not, however, straightforwardly permissible. - -For the sustainable use of open source software, it is important that OSS is not merely consumed, but that as many stakeholders as possible also contribute to the ecosystem. There are many ways to do this: from regular code contributions and creating documentation to funding developers, and much more. - -# Objective and purpose - -The Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA)[^10] requires that additional considerations be taken into account when procuring newly developed software and software development services. - -To support compliance with Art. 9 EMOTA, DTI has developed tools and resources as part of [Em002 Strategic Guidelines for Open Source Software in the Federal Administration](em002.md) and [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration](em002-1.md) - -![](./assets/em002-7/media/image1.png) - -Figure 1: Overview of OSS tools - -This document goes beyond the core of Article 9 EMOTA and also sets out how open source should generally be handled in the context of procurement. - -
-
- Section 3 -
-
- The importance of digital sovereignty in the context of open source and procurement -
-
-
-
- Section 4 -
-
- Relevant procurement use cases in connection with software and open source software -
-
-
-
- Section 5 -
-
- Creation: Tendering for software and services in connection with Art. 9 EMOTA -
-
-
-
- Section 6 -
-
- Consumption: Software procurement: equal treatment of open source software -
-
-
-
- Section 7 -
-
- Consumption: Procurement of additional services (support/maintenance/further development) for OSS -
-
-
-
- Section 8 -
-
- Collaboration: Procurement law aspects of collaborations for the creation, maintenance and support of OSS -
-
-
-
- Section 9 -
-
- Contribution Contributing to OSS projects -
-
- - -# Digital sovereignty and procurement - -## Introduction to digital sovereignty and OSS - -Through Art. 9 EMOTA, the Federal Administration is making an important contribution to digital sustainability and sovereignty by publishing its software as OSS. - -Digital sovereignty is not an end in itself, but a prerequisite for an effective, democratic and future-oriented administration. It is a multi-faceted concept encompassing technological, organisational and political dimensions. - - - - -
- Digital sovereignty means the state having the necessary control and capacity to act in the digital space in order to ensure that government tasks are fulfilled. -
- -When procuring software in particular, consideration should be given to the implications for the digital sovereignty of the Federal Administration. - -In its **roles as user, operator and contracting authority** in the field of ICT and software, the Federal Administration can consciously fulfil its responsibilities in this area. - -There are three strategic objectives in the area of software: - -**Interchangeability**: As a user, the public administration seeks to be able to choose freely and flexibly between providers, IT solutions and technologies. This requires the availability -of capable and proven alternatives, and IT architectures, procurement channels and staffing that are designed to facilitate switching. - -**Design capability**: As an IT operator , the public administration has the ability to shape and co-design its IT systems. To this end, it has the necessary expertise and appropriate cooperative structures to understand and evaluate IT solutions and, where necessary, ensure their development, further development and operation. - -**Influence**: As a contracting authority, the public administration can articulate and enforce its requirements and needs vis-à-vis technology providers. This applies to product features (functions, operating options, availability, information security and data protection, etc.) as well as to contract design and licensing models. - -**Open standards** and **open source software** best support these goals through **open source principles**. - -OSS supports digital sovereignty in the following ways: - -- IT security for public administration, critical infrastructure and security-sensitive applications can be assured at all times through full access to the source code. - -- OSS enables public bodies to build, operate, control and adapt their own IT infrastructure without restrictive licence conditions. - -- OSS provides full control over updates, features and security patches, in terms of both content and timing. - -- OSS can prevent dependence on individual vendors or licensing models and supports interchangeability. - -- OSS allows the entire software supply chain to be displayed and traced transparently. - -- OSS can be customised and expanded -- well suited to the specific requirements of public authorities and educational institutions, though this requires in-depth knowledge on the part of an organisation\'s own employees. - -- Investment in OSS also benefits local businesses and communities (local value creation), increasing the resilience of the Swiss economy. - -- OSS is based on collaboration and open interfaces, facilitating interoperability between systems and promoting open standards -- even across national borders. - -- OSS improves IT security and data security through transparency and adaptability. - -- OSS software licensed under OSI licences guarantees clear legal conditions and continuity, along with the fundamental freedoms of OSS, protecting developers and users alike. - -**Open standards:** To support software interchangeability, public procurement tenders should require compliance with open standards,[^11] thereby minimising lock-in. -**Open interfaces:** Interfaces should likewise be disclosed to enable interoperability. - -Federal authorities are generally required to comply with the eCH standards.[^12] - -The Bern University of Applied Sciences set out the relevant considerations in the study *Technological Perspectives of Digital Sovereignty* \[Stü2024\], commissioned by the FDFA, using the \'sovereignty house\' model, in which software is presented as a key pillar. - -![](./assets/em002-7/media/image2.png) - -*Figure 2: Schematic representation of the aspects of digital sovereignty enabling the provision of innovative products and services \[Stü2024\]* - -## Measuring digital sovereignty - -Aspects of digital sovereignty may be required in a public tender, but any such requirements must be objectively justified. There is no general preference for OSS. - -**How, then, can the degree of digital sovereignty be measured for a given technology, product or service?** - -This operationalisation must be made as objective and transparent as possible. - -Various initiatives are attempting to do this. The OSBA, for example, has developed a **sovereignty index**[^13] *\[OSBA-VK\]. Nextcloud* has published a Digital Sovereignty Index (DSI),[^14] which compares entire countries but can also provide useful criteria. -The European Union has published a Cloud Sovereignty Framework[^15] for the cloud. -The *Centre for Digital Sovereignty ZenDiS* is working on a sovereignty check designed to evaluate IT solutions and organisations against transparent sovereignty criteria. - -The Federal Administration is also involved in developing a **digital sovereignty framework** that will, among other things, enable the degree of fulfilment to be determined across a range of perspectives. - -Possible perspectives include: - - - - - - - - - - - - - - - - - - - - - - - - - - -
- A - - Technological control - - To what extent does the Federal Administration have control over the technologies used and their further development? -
- B - - Data sovereignty - - Who has access to, control over and decision-making power regarding the data – particularly sensitive administrative data? -
- C - - Legal capacity to act - - To what extent can Switzerland and the Federal Administration influence the legal and political framework for digitalisation? -
- D - - Resilience - - How robust and crisis-proof are the Federal Administration's digital systems and processes in the face of disruptions, crises and dependencies? -
- E - - Economic control - - How can the Federal Administration exercise economic control and strategic sourcing to secure its digital sovereignty cost-efficiently, while minimising dependencies and risks in IT procurement? -
- -For each of these perspectives, the degree of digital sovereignty can be determined against a scale to be defined: - -![](./assets/em002-7/media/image3.png) -Figure 3: Degree of digital sovereignty. - -These two dimensions produce the following matrix: - -![](./assets/em002-7/media/image4.png) - -Figure 4: Matrix Digital Sovereignty. - -Specific criteria can be described in the individual intersections (grey fields) to make the classification as objective as possible. - -Such a framework is currently being developed as part of Priority 4, 'Strengthening digital sovereignty', of the 'Digital Federal Administration Strategy'.[^16] - -The Federal Council brought the umbrella directive Digital Sovereignty in the Federal Administration[^17] into force on 1 January 2026. Projects must incorporate the various aspects into the definition of the procurement object and, where necessary, into a tender, on the basis of the specific sovereignty requirement -- for example from a risk perspective in the context of business continuity management. - -# Use cases for software procurement - -Information and communication technology (ICT) and software are not an end in themselves in the Federal Administration, but always serve to fulfil a legal mandate. Given advancing digitalisation and the Federal Administration\'s central role in Switzerland, information technology must be a core competence of the administration. - -The following **factors** therefore have a direct bearing on procurement: - -- **Digitalisation**: The digital strategy[^18] calls for the digitalisation of processes. - -- **Process optimisation**: Processes within the Federal Administration and in its external relations can and should be optimised. - -- **Digital sovereignty**: The importance of digital sovereignty is growing steadily; see *\[Stü2024\].* - -- The principle of **public money, public goods** and compliance with Art. 9 EMOTA. - -- **Economic freedom**: Measures should not unnecessarily restrict economic freedom. - -- General **security** considerations: The security of information processing systems is of increasing importance. - -- Crisis and disaster management (**resilience**): Given the current global situation, the administration must consider how it can continue to provide the necessary working tools under critical circumstances. - -- Strategic independence and **supply chain** considerations: These follow from digital sovereignty and resilience. - -- Avoiding/minimising **vendor lock-in**: Dependencies are almost impossible to avoid in IT, but reliance on a single vendor should be reduced wherever possible. - -- **Empowering** the Federal Administration[^19] (including management) in ICT matters: Controlling, developing and operating information technology requires appropriate skills across the workforce. - -This document distinguishes between **software types** as follows: - -- **Commodity -- Specialised applications/Industry -- Specialised applications/Federal authority**: - - - Standard application (commodity software) without special business logic. - - - Specialised application: Specific requirement of the industry/all federal levels or specific requirement of the federal authority - -- **Targeted -- strategic -- essential**: - - - Targeted application - - - Strategic application with significant importance for a federal authority or the Federal Administration as a whole - - - Essential and business-critical -- must remain functional in all circumstances (e.g. air traffic control) - -Applications may be used across one or more **fields of application**. - -What matters here is the **standardisation** of applications by product within each area: - -- No strategy - -- Single-product strategy - -- Multi-product strategy - -In addition to product standardisation, which must be examined carefully, there is also standardisation for interoperability (data formats, API, business elements).[^20] -Standardisation *is permissible* provided it is proportionate and does not unduly restrict competition (e.g. Art. 30 para. 3 PPA). It may reduce operating and maintenance costs and generate synergy effects, particularly where all federal levels are involved. On the other hand, it increases lock-in, dependency and, in some cases, security risks (cluster risk). - -Total costs of ownership (TCO) -- covering operation, maintenance and further development -- should always be considered in procurement. Long-term cost implications must not be overlooked. Open source business models differ in certain respects from those of proprietary providers. - -The following sections focus increasingly on open source, discussing the relevant procurement approach and how it should be implemented. - -The choice between consumption, contribution, collaboration and creation is made *on a project-specific basis* according to economic efficiency and the legal situation, with costs distributed as broadly as possible. From this perspective, the four Cs as defined in [Em002 OSS Strategic Guidelines](em002.md), Section 3, are ranked in descending order of importance: - - ![](./assets/em002-7/media/image5.png) - -1. Consumption - -2. Contribution - -3. Collaboration - -4. Creation - -With simple **consumption**, costs are spread across a large number of other users, but the federal authority has no control over further development. Creation is the inverse: full control, but full cost. - -With **contribution**, financial outlay is limited to the element developed, which is then handed over to another organisation for maintenance. - -**Collaboration** is the most complex scenario, as arrangements can vary considerably. In the best-case scenario, costs are shared and the federal authority has sufficient influence to implement its requirements without compromise (see Section 8). - -Ideally, **creation** accounts for the smallest share. Software may be developed in-house, through services, or via a contract for work. - -Pure consumption will only be feasible for standard applications. - -## Software requires additional services such as maintenance, support and further development. - -Although open source applications can be used free of charge, their strategic deployment across thousands of instances requires maintenance, support and, where necessary, further development. - -Federal authorities have an interest in long-term support for deployed versions (see Section 3.2.3 in *\[BITKOM2024\]*). - -Art. 9 EMOTA itself covers only the in-house development or further development of software and is not relevant to any other open source considerations -- digital sovereignty and other factors apply instead. However, restrictions under Art. 9 EMOTA on individual development components may have repercussions for the overall project where proprietary or additional developments are foreseeable. Collaboration can then be used to exploit synergy effects and, where possible, reduce costs across the Federal Administration as a whole. - -## Publication requirement for software procurement - -Where requirements indicate a need to adapt software, or a potential need for later adaptation, Art. 9 EMOTA is relevant and publication is mandatory for those parts, unless one of the two exceptions applies. When procuring an open source solution, such publication would already be addressed through a contribution to the open source project. Even where procurement involves only the licensing of standard software or ICT procurement falling under an exemption, any additional developments must in principle be published, and this must be reflected in the procurement documents and draft contract. - -**The publication requirement under Art. 9 EMOTA is therefore relevant to any procurement where in-house development or further development is likely** (see also *\[KBB-MB\]*). - -# **Creation: Tenders for software and services involving Article 9 EMOTA** - -This section addresses the implications of Art. 9 EMOTA for tenders for software and services that may involve the creation or modification of software. - -It applies to both centralised and decentralised Federal Administration. Exceptions to this requirement are set out in the Digitalisation Ordinance *\[DigiO\]*. - -## **Relevance of Article 9 EMOTA for software creation** - -A transaction falls within the scope of Art. 9 EMOTA if it falls within the relevant category of Table 1. The make-or-buy decision remains central to procurement. Analysis of the various use cases shows that, in principle, Art. 9 EMOTA is relevant in principle in all cases, except where pre-existing software is being procured (e.g. pure licences). Section II.4 of the *Open Source in Procurement Guidelines \[BBL-WL\]* sets out the strategic approach, and Annex VII.A describes in detail what constitutes software. A detailed breakdown of the strategic decision is provided in Table 1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Use case - - Make or buy - - Publication obligation under Art. 9 para. 1 EMOTA -
- Developing software within the Federal Administration - - Make - - Yes, publication obligation -
- Having software developed by third parties - - Buy as IT service contract - - Yes, publication obligation -
- Procuring existing software - - Buy - -

- Generally no, -

but check whether publication requirements apply to any parts being developed. Handling of third-party rights is particularly relevant (see [Em002-3 OSS Licensing Guidelines](./em002-3.md)). -
- Acquiring software from other public bodies - - Make or buy - -

- – Within the Federal Administration: publication obligation for the transferring administrative unit. -

- – Others: Examine on a case-by-case basis whether adaptations by the Federal Administration give rise to a publication obligation, at least for those parts. -
- Procuring development resources - - Make - - Yes, publication obligation (contracts must allow for publication) -
- Collaborating with other public bodies on software development - - Make - - Yes, publication obligation (contracts must allow for publication), particularly where there are substantial development contributions by or for the Confederation -
- -Table 1 Classification of publication requirement and make-or-buy decision (based on a table by Rika Koch, BFH) - -NB: Art. 9 EMOTA must also be taken into account for existing software and SaaS where the software is to be further developed or adapted for the federal government. Even where the likelihood of this is low, it should be addressed in the procurement process. - -Where clarification is needed, the recommended reference is [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md). The checklists should be **completed provisionally as early as possible** for potentially relevant projects. The *Checklist for Art. 9 EMOTA Blanket Exception \[BBL-CL\]* may also be used for this purpose. - -## **Preparing a procurement under Article 9 EMOTA** - -In addition to the usual preparatory steps, the following two documents should be consulted whenever a procurement involves software components: - -- *Information sheet on software procurement and Art. 9 EMOTA \[KBB-MB\] and* - -- *Open Source in Procurement Guidelines \[BBL-WL\]*. - -Where Art. 9 EMOTA is clearly relevant, the administrative unit should have: - -- provisionally completed the checklists [Em002-2.1 OSS Preliminary Assessment Checklist](Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) through to [Em002-2.3 OSS Release and Publication Checklist](Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication.odt); - -- taken a basic decision on whether to use a copyleft or permissive licence;[^21] - -- searched for possible open source alternatives (or potential base projects for contributions/collaboration) in accordance with [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md), using the tools specified therein for market research/market analysis;[^22] - -- clarified the structure of any relevant community ([Em002-4 OSS Community Guidelines](em002-4.md) and [Em002-4.1 OSS Community Checklist](Em002-4.1%20Checklist%20OSS%20Community.odt)). - -Where an existing OSS project is to be used, supported or built upon through collaboration, Sections 5, 0, 8 and 9 of this document must be read. - -## **Creation via existing service contracts** - -Where creation is handled via existing partner agreements, OSS publication must be ensured at the mini-tender stage, unless one of the two exceptions applies. - -New service tenders should always include a requirement for publication in accordance with Art. 9 EMOTA (see *\[BBL-WL\] and* *\[KBB-MB\])*. - -## **Building a community** - -Building and maintaining a community maximises the benefits of open source software, but also involves considerable effort. - -Where a community and collaboration make sense, this has implications for procurement from the outset. [Em002-4.1 OSS Community ](Em002-4.1%20%20OSS%20Community.odt) should therefore be completed on the basis of the [Em002-4 OSS Community Guidelines](em002-4.md). - -Where the federal authority is to take on a significant role in the community (e.g. a governance role) or where collaboration is planned (see Section 8), it may be necessary to procure additional services: community building, consolidation of requirements, management of further development. - -## **Sample criteria and contract elements for IT procurement** - -The CCPP maintains a template of possible procurement criteria and a framework agreement chapter template for software-related tenders *\[KBB-KV\]*. - -The CCPP has published two template documents on Perimap.admin.ch showing how the minimum requirements for a procurement-compliant acquisition under Art. 9 EMOTA can be met. \[KBB-KV\] - -1\. [Sample criteria -- Procurement EMOTA and Open Source](https://perimap.admin.ch/goto_perimap_file_47064_download.html) -2\. [Sample contract texts -- Software development](https://perimap.admin.ch/goto_perimap_file_47059_download.html) - -# **Consumption: Software procurement: Equal treatment of open source software** - -This section addresses the procurement and use (consumption) of open source software, highlighting key strategic aspects. -Reference is also made to *\[BBL-WL\] and* *\[KBB-MB*\]. - -**There is currently no legally prescribed preference for open source software in procurement.** - -When tendering for IT applications, all licence types and business models are considered. To meet the stated requirements, providers may offer software solutions based on unmodified open source, closed source or proprietary software, or on combinations of licence models and value-added services or subscriptions. - -The following points[^23] should be taken into account by federal authorities: - -- Regardless of its solution and licensing model, the service provider must specify in its tender **which licence conditions the service procurer must comply with when using the service**. - -- The service provider is **free to choose the solution** with which it intends to meet the advertised requirements and the form of remuneration it wishes to receive (licence, maintenance or subscription fees), provided this is technically feasible and economically reasonable. - -- The full **lifecycle** should be taken into account in the specifications and pricing. - -This enables the Federal Administration to assert its interests regarding intellectual property, warranty and liability -- independently of the software or licence model -- at the level of the applicable general terms and conditions, and to enshrine these in the contract. - -Where **software adaptations** are made on behalf of or in fulfilment of a contract with the federal authority, Art. 9 EMOTA applies. -As a precaution, publication approval should be requested in the tender, since experience shows that adaptations are usually required sooner or later, even if not foreseeable at the time of tendering. - -Where the service procurer procures **value-added services** from a provider in addition to the software, OSS suppliers often offer a subscription model that provides a local contact with warranty and liability commitments, alongside the direct relationship with the intellectual property holders of the OSS components (who are often based abroad and sometimes unknown). - -## **OSS as a strategic procurement criterion** - -Where a federal authority wishes to procure open source software for strategic reasons, several scenarios are possible: - -- Functional invitation to tender without OSS-specific criteria. - As this involves no restrictions, no special justification is required. - -- Functional invitation to tender with eligibility criterion, technical criteria and award criteria requiring open source, full access to source code, or demonstrable experience in open source publication. - - **Any preference for open source is permissible under procurement law where it allows the specific needs of the awarding office to be (better) met**.[^24] - - A further reason for favouring OSS -- beyond digital sovereignty -- is that where the administration requires significant software adaptations, these must be published under Art. 9 EMOTA. - Publication is most straightforward when the entire product has always been open source, and adaptations can in some cases be made directly within the product. Otherwise, an exception must be defined and, where necessary, parts of the code must be isolated and still released. - -## The use of OSS without payment is not subject to procurement law. - -OSS can often be downloaded and used directly. Procurement law applies only where services are obtained from third parties in return for payment (including non-monetary consideration). - -Downloading and using OSS free of charge does not in itself constitute procurement. - -It is also possible to procure the necessary services for downloaded OSS at a later stage, provided this is not done abusively.[^25] - -Maintenance, support and further development services for the product are then tendered separately in accordance with procurement law. - -There are already examples of OSS being used free of charge on the Federal Administration\'s standard workstations and therefore not procured.[^26] - -## Coordinating requirements with other stakeholders - -A specialised application always requires a requirement owner (usually a federal office). It generally makes sense for the body with the need to harmonise its requirements with those of other government agencies --- either internally or through collaboration (see Section 8) --- to the extent that an available market product or a collaborative development is conducive to development and rollout. - -Where many stakeholders have the same or similar requirements, it may be worth meeting those needs on a common basis. This applies to all forms of software. - -Two aspects should be noted: where adaptations are subsequently made by a federal authority at the request of third parties, Art. 9 EMOTA applies again -- though this is unproblematic where open source software is used. - -With OSS, requirements may need to be aligned more actively by the federal authority, since there may be no driving force such as a commercial vendor seeking to steer and develop its own product. - -## Considering other potential public actors in procurement - -The ZenDiS[^27] example shows that it can be both feasible and worthwhile to issue a tender covering all federal levels simultaneously. - -**Fair competition must always be maintained.** When issuing tenders, consideration should always be given to whether the solution might usefully be procured for other bodies as well. - -Where this is the case, those potential additional clients should be contacted and their needs reflected in the tender documents, particularly the requirements. A degree of flexibility in the requirements is important in such cases. - -Example: eOperations Switzerland Ltd ([www.eoperations.ch](http://www.eoperations.ch)) can be used for such collaborations. eOperations consolidates requirements from various agencies and conducts procurement itself, without necessarily using the product itself. This may also be a useful model for OSS procurement. - -# **Consumption: Procurement of support and maintenance for OSS** - -Public administration can use open source software in various ways, from simple download and installation through to formal procurement (see Section 6.2). - -Where OSS is deployed in critical areas, consistently high standards of security,[^28] maintenance and further development are required. In regular software procurement, this is usually covered by the tender. The requirements apply to both the software itself and to the relevant libraries and frameworks used. Support and maintenance warrant particular attention, since further development is often covered under the same contract and in any case constitutes creation and therefore falls within the scope of Art. 9 EMOTA. - -These labour-intensive services almost always exceed the threshold value under the Public Procurement Act (PPA) when calculated over the application lifecycle. Where they are purchased from third parties, procurement law must be complied with. Exceptions may apply, such as in-state procurement from another public contracting authority,[^29] or in exceptional cases direct procurement of specialist services.[^30] - -The following table sets out the case distinctions for the procurement of services such as support. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BackgroundResults
Lifecycle costs
→ WTO threshold?[^31]		In-state?[^32]WTO tender required?[^33]Comments
NoNoNo [^34] - Rarely a complete software package with support – mostly minor support and individual features. -
NoYesNo
YesNoYesOnly the volume to third parties is relevant.
YesYesNoThe tender was issued by the other public body.
- -Table 2 Case distinction -- procurement of support - -## Support and maintenance are always part of software - -Support and maintenance are essential for the sustainable operation of software in a public authority environment. In a world of zero-day exploits,[^35] rapid and professional patch deployment is critical. This \'infrastructure\' must be funded -- particularly since the administration has higher requirements than a private consumer. - -**The question is therefore not IF support and maintenance will be required, but HOW they are to be provided.** - -The federal authority must determine what level of support, maintenance, warranty and liability it requires based on its quality of service requirements. - -It is important that any service provider for maintenance and support can demonstrate sufficient experience with the product or the relevant open source community -- only then will it be able to fulfil these tasks effectively (see also *\[KBB-MB\]*, II.5).[^36] - -Support and maintenance must also be funded at the product level. Where no one contributes (the free-rider[^37] problem), the project\'s future is jeopardised, and with it its use within the Federal Administration. Given its scale, the Federal Administration can reasonably be expected to contribute to the costs of software it deploys strategically. - -## Organisations that can provide support - -The quality of support has a direct impact on end-user satisfaction and productivity. A structured support system with fast response times and genuine technical expertise ensures that users and administrators receive effective solutions to their issues, saving the contracting authority\'s working time and promoting acceptance of the software solution. - -To meet contractually agreed response times under service level agreements (SLAs), the provider must have qualified staff with the necessary expertise. - -Possible sources of support include: - -**In-house**: -- Federal offices -- Service providers - -**In-state**: -- Other public contracting authorities in Switzerland -- Services procured by other public contracting authorities in Switzerland - -**Third parties**: -- Procured service - -## Further development for specific features - -Where a federal authority requires only a limited number of specific enhancements to a piece of open source software, this can be done using internal resources or procured services. - -Such further developments should aim to be offered back to and integrated into the original project. This not only benefits the project ecosystem but ensures the enhancements are maintained within the project going forward. Without this, each new release of the original project may require the bespoke development to be updated manually (see also Section 8). - -## Subscription - -Many companies and projects in the open source environment offer free support within certain limits, provided voluntarily by any user, mainly through open channels such as forums and public ticket systems. This free offering is not designed for professional users with specific SLA requirements. - -For professional users such as federal authorities, OSS subscriptions that include warranty, maintenance and support are often available. - -Some providers also offer special \'enterprise versions\' that no longer meet the OSI\'s open source criteria. - -Examples of subscriptions: OpenShift from Red Hat, openDesk from ZenDiS - -## Certifications in the open source sector and OpenChain - -As with proprietary software, various certifications exist in the open source sector. It may be worthwhile for the administration to check for potentially relevant certifications in the area covered by the tender before issuing it. - -**OpenChain** is an ISO standard addressing open source development and licence compatibility (see below). - -Where relevant certifications exist and are pertinent to the service, they should be taken into account in the assessment of providers. It is important that the certification itself is considered meaningful, and that providers can demonstrate they are able to deliver the service even without certification. - -Given the complexity involved, requiring certifications as an eligibility criterion is inadvisable. As an award criterion -- with the possibility of demonstrating compliance with certification content through references -- they may be appropriate depending on the OSS product, provided it is permissible to use references to demonstrate that certification criteria are being met.[^38] - -Self-certification under OpenChain may at best serve as a substitute where no other certification exists. References addressing the relevant criteria can also stand in for missing certifications. - -**Certification of partner companies** - -Some open source developers and projects[^39] certify partner companies with which they collaborate. Such certifications can demonstrate an existing relationship between the provider and the software developer. Note that many OSS projects do not offer such certifications. Proven collaboration in reference projects is an equally valid -- and less restrictive -- indicator of the desired quality. - -**Certification of employees** - -Some open source manufacturers or communities[^40] certify individuals with specialist expertise in the relevant software. Where a service provider employs certified staff, this can demonstrate expertise in upstream publication of adaptations and patches, and in providing high-quality third-level support -- particularly where several staff members work with the product. This also depends on the structure of the OSS project\'s ecosystem. - -As an alternative to certifications, demonstrable project experience in references relating to the procurement subject can also serve as a differentiating criterion. - -**OpenChain standard** - -The OpenChain standard represents both best practice in licence compatibility and a certification of interest to procuring authorities. - -ISO/IEC 5230 \'OpenChain\' focuses on software supply chains, streamlined procurement and licence compliance. The OpenChain standard can be awarded by an accredited certification body or obtained through self-certification. This certification is suitable for demonstrating in general terms that a provider has already dealt extensively with open source licence requirements and the specifics of the open source ecosystem. -Since the creation of a Software Bill of Materials (SBOM) is part of the standard, this certification also evidences a supplier\'s commitment to supply chain security through support of foundational components. - -## Further options for procuring maintenance, support or further development services - -It makes sense to handle further development services under the same contract as support and maintenance, since the distinction is not always straightforward and is often not practical in the context of open source software. Further developments funded by a federal authority fall within the scope of Art. 9 EMOTA. - -The following options are currently available[^41] for procuring support, maintenance and/or further development services for OSS: - -- In-house, with competence building: Deploy own development resources - -- Procurement: According to volume and in compliance with the PPA. This may also be done via service contracts already put out to tender. To ensure that strategic partners can provide experienced core developers for OSS projects central to the Federal Administration, it may be worth permitting subcontracting or requiring the relevant expertise in certain tenders. - -- Cooperation agreements with third parties for maintenance, support or further development: unproblematic as long as each party bears its own costs. - -- Federal participation in organisations: unproblematic as long as each party bears its own costs. - -# **Collaboration: Procurement law aspects of collaborative creation, maintenance and support of OSS** - -The costs of open source software decrease when it is developed collaboratively, whether informally or through a structured arrangement. [Em002-4 OSS Community Guidelines](em002-4.md) sets out the relevant approaches. - -Collaboration with other public contracting authorities or third parties is unproblematic under procurement law as long as each party bears its own costs. Difficulties arise where the collaboration does not result in OSS, since the Federal Administration is bound by Art. 9 EMOTA. - -Such cooperation is permitted under Art. 4 EMOTA. - -The question of how to handle overheads or a centralised structure must be addressed: the structure needs sufficient funding to sustain the project through difficult periods. An alternative is a single managing partner (e.g. if one participant is large enough to take on the coordination role). Where the federal authority assumes this role, the relevant services must be provided in-house or tendered in the normal way if third parties are to be engaged. - -At the contractual level, the following applies to collaborations: - -- Where no money changes hands and no formal obligations are required, a Memorandum of Understanding at the level of the federal office or Federal Chancellery is possible. - -- The establishment of a joint structure -- such as an association or public-law corporation -- is possible in principle but must be assessed on a case-by-case basis. Where the joint structure is itself to procure services from third parties, the application of procurement law must be regulated. - -Membership may in some cases be exercised through other organisations such as eOperations or eCH. - -**Cooperation with foreign countries** - -Cooperation with foreign authorities is unproblematic as long as no money changes hands and no obligations of any kind are entered into. - -Cooperation agreements at the appropriate level are possible in principle but must be assessed case by case. -International treaties should be avoided given the high hurdles involved, though they would in principle also be possible. - -Two special cases[^42] exist where collaboration would already be covered: - -- Contracts awarded under an international agreement for the joint implementation of a project by signatory states. - -- Contracts awarded in accordance with the special procedures or conditions of an international organisation. - -# **Contribution: Contributing to OSS projects** - -Most of the characteristics and legal considerations relating to contributions are covered in [Em002-4 OSS Community Guidelines](em002-4.md). - -From a procurement law perspective, contributions are generally unproblematic, since the services are provided to develop code for a project that is either of direct relevance to the authority or has already been addressed from a procurement law standpoint. - -**Contributions from third parties to OSS projects run by federal authorities are also unproblematic under procurement law, as long as no money changes hands.** - -Note: Since the federal authority is obliged to publish software it develops, it must also ensure that it remains published. If an OSS project is taken down by its operators, the federal authority may in the worst case need to republish it independently. In practice, the source code typically remains available (e.g. as an archive), the project continues as a fork, or the project -- and with it the source code -- has simply become irrelevant. - -# Annex A: References: - -A significant portion of the references are *already mentioned in Em002 Strategic Guidelines for Open Source Software in the Federal Administration*. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- [A029] - - Product standard for office automation (OA) client software -Intranet: https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/standards/a029-bab_client_software.html -
- [BBL2015] - - Information sheet: Software tenders: Ensuring broad competition; 2015; no longer in force -
- [BITKOM2024] - - Open Source Software 2.0 Guidelines. Berlin: Bitkom e. V. Bundes-verband Informationswirtschaft, Telekommunikation und neue Medien e. V. BIT-KOM. 2024. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html -
- [BöB] - - Federal Act on Public Procurement (PPA) https://www.fedlex.admin.ch/eli/oc/2020/126/de -
- [DigiV] - - Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) -SR 172.019.1 – Ordinance of 2 April 2025 | Fedlex -
- [BBL-WL] - - Open Source in Procurement Guidelines: Software purchasing in accordance with Art. 9 EMOTA; FOBL; on the intranet: https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html -
- [BBL-CL] - - for Art. 9 EMOTA Blanket Exception, FOBL, on the intranet: https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html -
- [KKB-MB] - Information sheet: Procurement of software and Art. 9 EMOTA of the Competence Centre for Federal Public Procurement: https://perimap.admin.ch/goto_perimap_file_46835_download.html -
- [KBB-KV] - Sample criteria – Procurement and EMOTA. https://perimap.admin.ch/goto_perimap_file_47064_download.html
-Sample contractual texts – Software development https://perimap.admin.ch/goto_perimap_file_47059_download.html -
- [KBB-Perimap] - - CCPP learning and template platform -
- [OSBA-VK] - - Award criteria for sustainable procurement of open source software | OSBA – Open Source Business Alliance -
- [Sto2024] - - Certificate of competency 3 on Procurement-related criteria in relation to the new Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) based on Art. 9 (open source software) by Reto Stoll, 2024 -
- [Stü2015] - - Open source business model: Added value of the subscription offer, Matthias Stürmer, 2015 -
- [Stü2024] - - Technological Perspective on Digital Sovereignty, Matthias Stürmer, 2024, https://arbor.bfh.ch/entities/publication/b77d2f8b-4148-4325-82cd-405fa077a28a -
- [SIK] - - SIK for procuring open source software: https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/, 2015 -
- [W012] - - W012 – Directives for Digital Sovereignty in the Federal Administration, V1.0 2025 -
- - -# Annex B: Glossary - -This glossary covers specific terms related to procurement topics. - -The general glossary for the Em002 document set can be found in Em002-6 OSS-FAQ. - -Further terms can be found in the terminology database TERMDAT [terminology database of the Federal Administration](https://www.bk.admin.ch/bk/en/home/dokumentation/languages/termdat.html). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Application area - - This refers to the office automation (OA) software categories according to [A029] and other classifications. -
- Branch - - A development branch of an OSS. -
- CCPP - - Competence Centre for Federal Public Procurement -
- Collaboration - - The term collaboration derives from the Latin word 'collaborare' and means 'to work together'. -It describes a way of working in which several people or teams work together towards a common goal, contributing their skills and resources. The focus is on mutual exchange, transparency and the sharing of knowledge.
According to the Gabler Business Dictionary, collaboration also refers to 'cooperation between a company and its customers and suppliers, using modern information technologies to integrate internal and cross-company business processes.' -
- Committer - - A committer is a person who enters a change to data in a version control system. -
- Contribution - - OSS contribution refers to the contribution to the development and improvement of open source software (OSS). This can take the form of providing code, documentation, tests, feedback or other types of contributions. (Google AI) -
- Contributor Licence Agreement (CLA) - - A Contributor Licence Agreement (CLA), also known as a Contributor Agreement, is a document that sets out the terms under which intellectual property may be contributed to a project or initiative. This usually refers to a software project under an open-source licence (Wikipedia). -
- DTI - - Digital Transformation and ICT Steering Sector. Part of the Federal Chancellery FCh -
- eOperations - - eOperations Switzerland enables joint digital public services for the federal government, cantons and communes. www.eoperation.ch -
- FITSU - - Federal IT Steering Unit. Predecessor of FCh-DTI -
- FOBL - - Federal Office for Buildings and Logistics -
- Life cycle - - A software life cycle describes the process of software development with the aim of providing software to the customer. As a rule, the cycle begins with a problem identified by the customer and its analysis, and ends on the customer side with the replacement of the software by a successor. -
- Lock-in - - The lock-in effect refers to close customer loyalty to products/services or a provider or vendor, which makes it difficult for the customer to switch products or providers due to the costs and other barriers involved in switching. -
- Market analysis - - A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations);market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html ).
Possible sources of OSS software can be found in [Em002-1 Practical Guidelines for OSS](em002-1.md) in Section 7. -
- Product - - Used here as a synonym for ‘application’.
-The term originates from ITIL. In ITIL (Information Technology Infrastructure Library), a product is a configuration of resources designed to deliver value to a customer or organisation. Unlike a service, which is typically an ongoing, interactive process, a product is a static entity.
-Products can be software, hardware, data or other resources provided by the organisation. (Google AI) -
- Product standardisation - - In this document, standardisation primarily refers to SD120, the ICT standard service for office automation, and other standardisations by DTI. -
- SBOM - - A Software Bill of Materials (SBOM) is an inventory list of all components and software dependencies that are part of the development and deployment of a piece of software. -
- Subscription - - When subscribing to software, a subscription is taken out. This means that the software is not purchased.
-In most cases, this involves not only permission to use the software, but also includes all relevant services and support. -
- Upstream project - - Upstream is a term used in distributed software development (often open source) and refers to the direction of a patch to its origin (upstream), i.e. to the original developers or maintainers of the software, or to the original project. These can also be software libraries. -
- ZenDiS - - ZenDiS is a publicly owned limited liability company (GmbH) in Germany. It supports the federal government, states, and municipalities in implementing digital sovereignty. With opdencode.de and container.gov.de, it offers a platform for secure open-source development. (www.zendis.de ) -
- Zero-day exploit - - A zero-day exploit refers to the exploitation of a security vulnerability for which no patch is yet available from the component manufacturer. -
- -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: Online: - https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html - -[^3]: - -[^4]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^5]: See footnote 1 - -[^6]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^7]: The Competence Centre for Federal Public Procurement (CCPP) - advises procurement and requesting offices on matters relating to - procurement law in accordance with Art. 37 OPPO. Central email - address for enquiries:  - -[^8]: The Federal Office for Buildings and Logistics (FOBL) is the - central procurement office of the Swiss Confederation (Arts 5--7 - OPPO). It carries out procurement within its area of responsibility, - consolidates where appropriate and may conclude framework - agreements. - -[^9]: - -[^10]: - -[^11]: For example, open standards such as eCH, ODF; see also [Open - standard -- Wikipedia](https://en.wikipedia.org/wiki/Open_standard) - -[^12]: [www.ech.ch](https://www.ech.ch/) - -[^13]: [An index for digital sovereignty \| OSBA -- Open Source Business - Alliance](https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet) - -[^14]: [dsi.nextcloud.com](https://dsi.nextcloud.com/) - -[^15]: [commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en?filename=Cloud-Sovereignty-Framework.pdf](https://commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en?filename=Cloud-Sovereignty-Framework.pdf) - -[^16]: [[https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html](https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html)](https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html) - -[^17]: W012 - Directives for Digital Sovereignty in the Federal - Administration - -[^18]: - -[^19]: Not only among managers, project managers and ICT architects, but - across all staff. - -[^20]: E.g. via eCH - -[^21]: A more detailed analysis can be carried out later using *Em002-3 - OSS Licensing Guidelines* if needed). - -[^22]: See also [Em002-1 Practical Guidelines for Open Source Software in the Federal Administration](em002-1.md), Section 7. - -[^23]: The primary procurement reference documents are those published - by the FOBL and CCPP on the relevant platforms. - -[^24]: See \[BBL-WL\], \[BBL-CL\], \[KKB-MB\], \[KBB-KV\] - -[^25]: Analogy: A commune may use its own timber and commission - construction of a maintenance depot using that timber -- it is not - required to procure the timber itself. - -[^26]: Examples of OSS with standardisation potential: Gimp, FileZilla, - VLC Media Player and 7-zip as Shell 2 products (according to - *\[A029\]*), which can be used because installation is free of - charge. - - In 2024, BIT designated Red Hat OpenShift as a strategic product for - certain application areas on the basis of its unique technical - features. OpenShift is currently the strategic platform for - containers and operating systems. - -[^27]: [https://www.zendis.de/](https://www.zendis.de/en) ZenDiS\'s - stated mission is to enable the administration to break free from - critical dependencies on individual technology providers. - -[^28]: See also [Em002-6 FAQ-OSS](em002-6.md), Section 5.3 - -[^29]: Art. 10 para. 3 let. b PPA. - -[^30]: Art. 21 para. 2 let. c PPA. - -[^31]: Internal costs may be excluded. Full life cycle must be - considered. - -[^32]: In-state procurement is not subject to tendering: state - sponsorship required, no market participation. Applies only within - the Swiss public sector. - -[^33]: Federal procurement guidelines always apply where any payment is - made. - -[^34]: Software with support generally exceeds the PPA threshold; \'no\' - will only apply in rare cases (e.g. financing a single feature for - an existing OSS project). - -[^35]: A zero-day exploit refers to the exploitation of a security - vulnerability for which no patch is yet available from the component - developer. - -[^36]: The service contract may also need to cover the potential - transfer of knowledge to a successor organisation. - -[^37]: - -[^38]: NB: Requiring a certification that is excessive or ill-suited to - the subject of the tender will inevitably produce less competitive - bids. - -[^39]: such as Nextcloud or Univention - -[^40]: such as LibreOffice or RedHat - -[^41]: Other, more niche options may also exist. - -[^42]: diff --git a/docs/en/em002.adoc b/docs/en/em002.adoc new file mode 100644 index 0000000..20ba61b --- /dev/null +++ b/docs/en/em002.adoc @@ -0,0 +1,423 @@ += Em002 Strategic Guidelines for Open Source Software in the Federal Administration +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main link:https://github.com/swiss/opensource-guidelines/tree/main[README]. + +''' + +== Introduction + +=== Objective and purpose + +Under Article 9 paragraph 1 of the Federal Act of 17 March 2023footnote:[SR 172.019] on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), public authorities must disclose the source code of software they develop or commission to perform their duties, unless third-party rights or security-relevant reasons preclude or restrict this. This eliminates legal uncertainty regarding the publication of software by federal authorities. + +In recent years, it has become clear that the importance of open source software (OSS) in the Federal Administration has generally continued to increase. + +These strategic guidelines describe the fundamentals of open source software and how this is handled in the Federal Administration. The document sets out six objectives and proposes nine measures to fulfil these. + +It also gives references to other relevant public sector strategies regarding open source. + +=== Background + +In 2005, the Federal IT Strategy Unit (FITSU) published the first version of an OSS strategy for the Federal Administration. At that time, the most important principle was defined as the equal treatment of OSS with closed source software in procurement. + +Since publication in 2005, the prevalence of open source software has steadily increased. Today, according to the Open Source Study Switzerland 2024 report, a clear majority of companies and authorities use open source software in many different areas. In the software industry, very few companies do not work with open source tools and components. + +On 1 February 2019, these Strategic Guidelines for Open Source Software in the Federal Administration and the practical guidelines came into force as Version 1.0. With the enactment of EMOTA and the new obligations under Article 9, it became necessary to align both sets of guidelines with the new status and create additional tools for the federal authorities. + +=== Procedure + +The federal offices are responsible for implementing EMOTA themselves. However, given the growing importance of open source, it was decided to revise the practical guidelines _link:em002-1.adoc[Em002-1]_ together with all stakeholders. Furthermore, additional tools for implementing EMOTA were added. + +The practical guidelines define the necessary concepts, set out the constellations for using open source software, where and how alternatives to existing commercial software can be found, how open source should be procured, what business models exist for open source and what support models are possible when using open source. The other tools provide answers to frequently asked questions and guidance on releasing open source software in accordance with EMOTA. They explore all issues surrounding OSS licences and show how a community can be built around software. Several checklists for guidance and documentation are also made available to federal authorities. + +Documents relating to procurement were also amended, and an additional information sheet [KBB-MB], set of guidelines [BBL-WL] and a checklist [BBL-CL] were drawn up. + +Existing uncertainties are resolved as far as possible with these strategic guidelines, the accompanying practical guidelines and recommendations for action, as well as the additional tools. + +== Reference to other strategies + +These Strategic Guidelines for Open Source Software in the Federal Administration are aligned with four current public sector strategies and EMOTA.footnote:[SR 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/de] These contain a direct or indirect reference to the topic of open source software and IT collaboration among public institutions: + +The *Digital Federal Administration Strategy* [SB001] sets out eight principles and four priorities. By using open source software, the Federal Administration contributes to priority 4, 'Strengthening digital sovereignty'. An open source solution can be reused any number of times and adapted to the individual needs of the Federal Administration due to its open source code. + +The concept of digital sustainability and digital sovereignty also comes up in the *Digital Public Services Switzerland Strategy 2024–2027*footnote:[Digital Public Services Switzerland Strategy 2024–2027: https://www.digital-public-services-switzerland.ch/strategy]. The Confederation and cantons will create appropriate conditions for this multiple use. Basic modules for expanding eGovernment will be 'implemented once and used jointly'. Opting for open source software makes it easier to reuse IT solutions. + +According to the *Digital Switzerland Strategy*footnote:[https://digital.swiss/en/] it is crucial for Switzerland's success in the digital space to strengthen the networking of federal levels. Particular attention should therefore be paid to coordination between the Confederation, cantons and communes as well as cooperation between organisations active in the field of digitalisation throughout Switzerland. The Federal Council also attached particular importance to Switzerland's digital sovereignty as a focus topic for 2023.footnote:[https://digital.swiss/en/strategy/focus-topics/digital-sovereignty] + +In the *Open Government Data Strategy Switzerland (2019–2023)*footnote:[Open Government Data Strategy 2019 – 2023] the Federal Council states that data from the Federal Administration that is not personal and not security-critical should be published according to the Open by Default principle. The Federal Administration has launched the opendata.swiss portal for this purpose.footnote:[https://opendata.swiss/en] Federal offices, cantons, cities and other public organisations have currently published over 11,700 datasets there. + +The Open Government Data Master Plan 2024–2027footnote:[https://www.bfs.admin.ch/asset/en/28425806] implements the Open by Default principle. + +== Governance and tools + +When talking about open source software, a distinction has to be made between *consuming* (using), *contributing* (adding to existing code) and *creating* (i.e. new projects). + +image::./assets/em002/media/image1.png[The 4 Cs in the context of OSS] + +Figure 1: The 4 Cs in the context of OSS + +*Collaboration* is also always conceivable in the background. In the case of creation, it must be initiated by the Federal Administration; in the case of contribution, it already exists; and it can also be helpful in the case of consumption (e.g. user group). + +When *consuming* open source software, it should be treated and evaluated as equivalent to proprietary software. + +When *developing* software, open source release is generally mandatory, subject to the exceptions set out in Art. 9 EMOTA (third-party rights and security-relevant reasons). + +These exceptions are addressed in link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]. + +The federal authorities, i.e. the administrative units of the Federal Administration, are themselves responsible for correct compliance; there is no centralised responsibility. + +*Publication* brings added value especially when a *community* of interested parties emerges and works together on the software. If the community collaborates on a project and the Federal Administration allows these contributions, economic benefits and synergy effects are created.footnote:[https://test.bitkom.org/sites/main/files/2023-03/BitkomLeitfadenOpenSourceSoftware31.pdf, Section 4 (in German)] + +In practice, release often consists of not only the source code, but also all other aspects (documentation, governance, build instructions, etc.). + +In principle, the Federal Administration has no obligation to build communities; the legal mandate only requires it to publish the source code. The Federal Administration should prioritise investing in communities where the benefit for the Confederation and third parties is great and the effort is as low as possible. + +Currently, there is no common federal platform for *developing and publishing source code*. Each public authority must therefore select a platform (repository) for publication itself. The practical guidelines in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and the associated checklists define how to work with a platform and which properties it must fulfil. + +The *choice of licence* is dealt with in the OSS Licensing Guidelines link:em002-3.adoc[Em002-3]), which presents a selection of standard licences and explains their uses. The Federal Administration should only use its own licence texts in justified cases according to Art. 9 para. 4 EMOTA. + +When using and developing OSS, *support*footnote:[At least during the lifecycle by way of contracts or a community.] must always be regulated (even if it is waived). The responsible administrative unit regulates this during the release process or when defining the community. EMOTA does not make any provisions here, and no additional financing or personnel will be made available for support. It may make sense to include support and joint further development where the benefit for Swiss authorities or the Swiss economy is considered sufficiently large (ecosystem costs) and/or cost-sharing or cooperation is sought. If the supplier takes this on, its support costs can be covered by the users. + +The *procurement of OSS* is done via the Federal Administration's regular procurement process. The FOBL provides the relevant documents and tools. + +In addition, a _Software procurement and Art. 9 EMOTA information sheet_ is availablefootnote:[Available here (in German): https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html and https://perimap.admin.ch/goto_perimap_file_46835_download.html] _[KBB-MB]_ (see Figure 2). + +Legal and practical considerations mean that under certain circumstances the obligation to release OSS may be transferred to a supplier (during the tender or in operation). The procurement tools and the release process determine how this is to be approached with the supplier. Most of this is achieved by supplementing existing processes, contract drafts and tools. + +The organisational procedure is regulated in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and the associated tools. + +*OSS is treated equally to proprietary software under procurement law.* Since no licence fees are incurred for OSS according to the definition of the Open Source Initiative (OSI), software can be downloaded and used in principle without a tender. Only the services to be provided by companies (e.g. support, engineering) are then subject to procurement law and must be put out to tender. + +Where necessary, the relevant aspects from the tools are integrated into the Confederation's project management processes (i.e. HERMES). + +Open development (direct open development on an openly accessible repository) and participation in existing projects (contribution) are also covered in the explanations in link:em002-4.adoc[Em002-4 OSS Community Guidelines]. + +=== Overview of OSS documents + +The following diagram gives an overview of the documents relevant to OSS in the Federal Administration. + +image::./assets/em002/media/image2.png[Documents related to Art. 9 EMOTA] + +Figure 2: Documents related to Art. 9 EMOTA + +== Objectives + +The following overarching, long-term objectives show how the Federal Administration taps into the potential of open source software and addresses the risks and challenges: + +A) Compliance with legal requirements (i.e. EMOTA):: The release of open source software is governed by Article 9 EMOTA. Compliance with this legal requirement is a key aspect of these guidelines and the associated documents. Federal authorities should comply with this article and maximise the benefits for the Federal Administration and Switzerland. The organisational units themselves are responsible for implementation. + +B) Increase innovation and efficiency:: Open source software serves as the basis of modern IT today. Building on the millions of freely available components and solutions, independent applications can be rapidly developed and operated. The associated time and resource savings and the architectural principles associated with open source software, such as interoperability, agility and microservices, increase the capacity for innovation and efficiency of software development. This in turn accelerates the digitalisation of the Federal Administration. By releasing open source software, the adoption of digital solutions can be accelerated in the federal environment and synergy effects can be utilised. + +C) Promote a culture of collaboration:: Open source software promotes a culture of collaboration in IT through the sharing of source code, open communication and practices for joint further development. These principles can be applied to increase collaboration in IT within the Federal Administration, with the cantons and with other public institutions. This strengthens digital sovereignty and reduces dependencies on software vendors. + +D) Create clarity and minimise risks:: Information on frequently used open source licences should enable the Federal Administration to select the right licences. This minimises legal risks. Technical and legal recommendations enable the Federal Administration to use and release open source software. + +E) Create an overview to utilise synergies:: Open source software is currently used in numerous places within the Federal Administration in different ways. A lot of knowledge and experience is available, but the synergies cannot yet be utilised as there is no overview of the open source solutions in use. Such an overview and the joint procurement of services will make it possible to better exploit the potential of open source software, which saves resources and creates synergies. + +F) Increase attractiveness as an IT employer:: Open source software is popular with many highly qualified IT professionals. The use of modern open source technologies and the application of open source development methods motivate many employees and increase the attractiveness of the Federal Administration as an employer. To use open source software, the Confederation needs specialists with knowledge and experience of open source software, so efforts should be made when recruiting specialists to expand internal open source know-how. + +== Measures + +The following measures are intended to help achieve the objectives outlined above. The measures will be supplemented or replaced in due course and adapted to changed circumstances. + +The following table illustrates how the objectives are linked to the corresponding measures. These support implementation of the respective objectives but they may also have an impact on other objectives. + +[options="header",cols="30,70"] +|=== +|Objectives |Measures + +|*A) Compliance with legal requirements (EMOTA)* +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +2) Implement the _Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2]_ and the tools derived from that. + +3) Procurement authorities build up open source know-how and thus support the Federal Administration. + +|*B) Increase innovation and efficiency* +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +3) The procurement authorities can deal with open source and optimally support Art. 9 EMOTA. + +8) Promote community building + +|*C) Promote a culture of collaboration* +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +4) Promote knowledge and experience exchange + +8) Promote community building + +9) Examine the possibility of establishing own publication platform; promote Open Development + +|*D) Create clarity and minimise risks* +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +2) Implement the _Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2]_ and the tools derived from that. + +|*E) Create an overview to utilise synergies* +a|6) Implement joint procurement of services + +7) Create an overview of open source software used, released and co-developed + +8) Promote community building + +|*F) Increase attractiveness as an IT employer* +a|5) Promote and communicate an open source culture + +8) Promote community building +|=== + +=== Description of the measures + +[cols="20,80"] +|=== +|*Measure 1:* |*Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_.* + +2+a| +Although the term open source software is already over 20 years old, the steady spread of open source software and the continuous development of application scenarios constantly lead to new practices and questions. New and further developments of open source solutions are also increasingly forming full-fledged alternatives to proprietary software. With EMOTA, the obligation to publish in-house developments is added. + +The _Practical Guidelines for Open Source Software in the Federal Administration_ give an overview and introduction to the topic, outlines the advantages and disadvantages of open source software and explains all other tools. It also contains best practices, proven alternatives and practical recommendations on how the Federal Administration should handle open source software. + +These practical guidelines and the other tools should be used and implemented by the federal authorities when dealing with open source software and releases. + +As a brief introduction to the topic, an _information sheet on the application of Art. 9 EMOTA_ and link:em002-6.adoc[EM002-6 FAQ about Publishing OSS (OSS-FAQ)] are available. + +|*Measure 2:* |*Implement the Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2] and the tools derived from that.* + +2+a| +The efficient use of OSS in software development often requires contributions in the form of bug fixes and functional enhancements. With EMOTA, there is also an obligation to release self-created software. The necessary guidance is available with various tools. + +The checklists are part of the instructions for publishing OSS. They should be used as a supplement to the corresponding guidelines of the administrative units before and during development. + +The handling of legacy code under Art. 9 EMOTA is also discussed. The aim is to find and implement pragmatic solutions. + +Licences are particularly important in the OSS environment. When releasing, procuring and using software, licences must be aligned with what is legally feasible and the desired effect. The necessary knowledge and corresponding decisions should be documented. In this context, the necessary additional documents such as the Contributor Licence Agreement (CLA) are also provided. + +To facilitate the application of Art. 9 EMOTA, additions will be made to the Confederation's project management method (HERMES). Administrative units should find the necessary tools in the regular process. + +|*Measure 3:* |*Procurement authorities build up open source know-how and thus support the Federal Administration.* + +2+a| +The new link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] was created to address procurement aspects. + +To ensure broad competition, procurement requires that open and closed source software be treated equally. The increased requirements in connection with Art. 9 EMOTA regarding the resources to be procured for software publication must be taken into account. + +The Competence Centre for Federal Public Procurement (CCPP) has published an information sheet on software procurement and Art. 9 EMOTA [KBB-MB] at the following link link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html]. + +Further assistance is available on the FOBL intranet (accessible only from the federal network) with the link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[Open Source in Procurement Guidelines] [BBL-WL] and the link:https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx[Checklist for Art. 9 EMOTA Blanket Exception] [BBL-CL]. + +|*Measure 4:* |*Promote knowledge and experience exchange* + +2+a| +Creating and using open source software requires in-depth, specialised know-how. At the same time, open source solutions are constantly evolving and new open source projects are being launched. It is therefore a challenge to maintain a comprehensive overview of current trends and technologies. + +To promote the professional use of open source and facilitate the exchange of knowledge and experience, information should be shared within an extended community of interest, and employees within the Federal Administration should be competently supported. + +|*Measure 5:* |*Promote and communicate an open source culture* + +2+a| +Advancing digitalisation has further exacerbated the shortage of skilled workers in IT. This also makes it difficult for the Federal Administration's service providers to recruit qualified IT staff. The use of open source software and the associated developer culture is known to be an argument for professionals to apply for such positions. + +In order to be perceived by the public as an 'open source-friendly' employer, the various measures and the open source solutions used should be actively communicated in the form of a technology radar.footnote:[Technology radars should be used as widely as possible. This means, if possible, at the level of the federal authorities or even the Federal Administration.] For employer attractiveness, it is also important to allow federal employees to contribute to existing open source software. + +|*Measure 6:* |*Implement joint procurement of services* + +2+a| +Maintenance and support of open source software is currently provided by internal employees of the Federal Administration, while external suppliers offer services for certain open source solutions. These services are often procured independently by the respective offices, which can lead to duplication and the associated financial losses. + +The joint procurement of services for open source software should increase the reliability of maintenance and support in operation and simplify the use of open source solutions. Based on the technology radar (see Measure 5), services for the most widespread open source systems and technologies should be centrally procured. These services can then be obtained by all offices as needed.footnote:[This concerns support for the software in use. Third party support for software released under EMOTA is possible and may be charged for. This is covered in link:em002-4.adoc[Em002-4 OSS Community Guidelines.]] + +|*Measure 7:* |*Create an overview of open source software used, released and co-developed.* + +2+a| +Since no licences need to be purchased when using open source software, the time-consuming procurement process is often eliminated. + +This makes it difficult to track where the Federal Administration uses which open source software. As a result, the potential of open source software – such as the use of synergies, the formation of communities for the experience exchange, etc. – cannot be fully utilised. + +A technology radar within the Federal Administration should provide an overview of where which open source software is being used and who has what know-how. + +|*Measure 8:* |*Promote community building* + +2+a| +Building and participating in communities for project development is very important for OSS. A significant number of synergies result from this. It may be that the project already exists and the Confederation only participates, or the Confederation may lead the project, or indeed it may be a collaboration. Omitting a community is also an important decision. Direct development on an open repository14 (without subsequent release) can bring further efficiency gains and promote joint development. Em002-4 provides guidance and motivation for community building by the federal authorities. + +|*Measure 9:* |*Examine the possibility of establishing own publication platform; promote Open Development* + +2+a| +The establishment and operation of an internal or Swiss publication platform will be examined and implemented after such a decision has been taken. + +The aim of an independent platform for the Federal Administration is to preserve digital sovereignty and independence. Collaboration is simplified and at the same time it creates an overview of activities. + +Federal cooperation across all authorities in Switzerland (similar to opencode.de) is being examined (e.g. DPSS or eOperations Switzerland). +|=== + +== Annexes + +=== Changes from previous version + +* Minor editorial changes and improvements. +* Factsheet Em002-5 has been replaced by the OSS tools information sheet'. +* A new addition is the document '`link:em002-7.adoc[Em002-7 Procurement and OSS]`'. +* New diagram depicting the 4 Cs in the context of OSS (addition of 'collaboration'). +* New FOBL and CCPP references. + +=== References for OSS tools + +The following reference table lists the documents relating to the document set for link:em002.adoc[Em002 Tools for Open Source Software] in the Federal Administration. + +[cols="1"] +|=== +|Source note: The tools and especially the checklists are partly based on the *OSS documents of the Canton of Bern*, which are released under a BSD3 licence (link:https://github.com/kanton-bern/oss[https://github.com/kanton-bern/oss]). +|=== + +The current Em002 documents are published on the OSS resources page of the Federal Chancellery. https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html. + +The English version is also published as markdown on GitHub. Feedback can also be given there. https://github.com/swiss/opensource-guidelines + +[cols="20,80"] +|=== +|[Em002] |Em002 Strategic Guidelines for Open Source Software in the Federal Administration, version 2.0, 2025 + +|[Em002-1] |Em002-1 Practical Guidelines for Open Source Software in the Federal Administration, version 2.0, 2025 + +|[Em002-2] |Em002-2 Instructions for Publishing Open Source Software, version 2.0, 2025 + +|[Em002-2.1] |Em002-2.1 OSS Preliminary Assessment Checklist, version 2.0, 2025 + +|[Em002-2.2] |Em002-2.2 OSS Analysis and Preparation Checklist, version 2.0, 2025 + +|[Em002-2.3] |Em002-2.3 OSS Release and Publication Checklist, version 2, 2025 + +|[Em002-3] |Em002-3 OSS Licensing Guidelines, version 2.0, 2025 + +|[Em002-4] |Em002-4 OSS Community Guidelines, version 2.0, 2025 + +|[Em002-4.1] |Em002-4.1 OSS Community Checklist, version 2.0, 2025 + +|[Em002-5] |Em002-5 OSS Tools information sheet, Version 2.0, 2025 + +|[Em002-6] |Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS), version 2.0. 2025 + +|[Em002-7] |Em002-7 Strategic Aspects of Procurement and Open Source Software, version 2.0, 2025 + +|[BBL-WZK] +a|Information sheets for the FOBL requesting offices can be found in the corresponding toolbox (in German): link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] + +|[BBL-AGB] |GTCs of the Confederation. link:https://www.bkb.admin.ch/bkb/de/home/themen/agb.html[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] + +|[BBL-WL] +a|link:https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf.download.pdf/Wegleitung%20Open%20Source%20in%20der%20Beschaffung.pdf[Open Source in Procurement guidelines], FOBL; 2025 + +Decision-making aid for purchasers in projects with possible OSS relevance. Contains information on correct implementation in tenders and contracts. (PDF) + +Only accessible to federal agencies on the federal intranet + +|[BBL-CL] +a|link:https://intranet.bbl.admin.ch/dam/bbl_kp/de/dokumente/informatik/Werkzeugkiste/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx.download.docx/Checkliste%20Integral-Ausnahme%20Art.%209%20EMBAG.docx[Checklist for Art. 9 EMOTA Blanket Exception], FOBL, 2025, + +Assists in reviewing and documenting whether, in individual cases, the publication of developed software can be waived. (DOCX) + +Only accessible to federal agencies on the federal intranet + +|[KBB-MB] +a|Information sheet: Software procurement and Art. 9 EMOTA, Competence Centre for Federal Public Procurement: + +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html] + +|[KBB-KV] +a|Musterkriterien Kriterien – Beschaffung und EMBAG link:https://perimap.admin.ch/goto_perimap_file_47064_download.html[https://perimap.admin.ch/goto_perimap_file_47064_download.html] + +Mustertexte Vertrag – Software-Entwicklung + +link:https://perimap.admin.ch/goto_perimap_file_47059_download.html[https://perimap.admin.ch/goto_perimap_file_47059_download.html] + +|[KBB-Perimap] |link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[Lern und Vorlagenplattform KBB] (Registration is required) +|=== + +Visual overview of OSS tools: + +image::./assets/em002/media/image2.png[Documents in connection with Art. 9 EMOTA] + +Figure 3: Documents in connection with Art. 9 EMOTA + +=== General references + +All references to the Em002 document set can be found here *in Em002 Strategic Guidelines [Em002*]. + +[cols="20,80"] +|=== +|[A029] +a|Product standard for office automation (OA) client software +Intranet: link:https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/standards/a029-bab_client_software.html[https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/standards/a029-bab_client_software.html] + +|[BITKOM2023] |Leitfaden Open-Source-Software 2.0. Berlin: Bitkom e. V. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. BIT-KOM. 2023. link:https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html[https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html] + +|[BöB] |Federal Act on Public Procurement (PPA) link:https://www.fedlex.admin.ch/eli/oc/2020/126/de[https://www.fedlex.admin.ch/eli/oc/2020/126/de] + +|[DigiV] |Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) link:https://www.fedlex.admin.ch/eli/cc/2025/235/de[SR 172.019.1 \– Ordinance of 2 April 2025 \| Fedlex] + +|[EY2011] |Open Source Software im geschäftskritischen Einsatz. Ernst & Young. 2011. link:https://www.yumpu.com/de/document/read/23276493/open-source-software-ernst-young[https://www.yumpu.com/de/document/read/23276493/open-source-software-ernst-young]. + +|[EMBAG2023] |172.019 Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) link:https://www.fedlex.admin.ch/eli/cc/2023/682/de[https://www.fedlex.admin.ch/eli/cc/2023/682/de] + +|[Fr2012] |Fröhlich-Bleuler, Gianni. Open Source Compliance. Jusletter 12 November 2012. + +|[Ga2021] |Gartner for Application and Software Engineering Leaders Tool: Open Source Software Governance Policy Template. Gartner, March 2021 + +|[GoAy2022] |Goldstein, Ayala. Top 10 Open Source Licenses in 2022: Trends and Predictions. 2022. link:https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions[https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions] + +|[Gu2024] |Günter, Matthias. Selection criteria for enterprise-ready Open Source software. 2024. link:https://gnostx.com/wp_gnostx/blog/2024/05/31/selection-criteria-for-enterprise-ready-open-source-software/[https://gnostx.com/wp_gnostx/blog/2024/05/31/selection-criteria-for-enterprise-ready-open-source-software/] + +|[IZqCab2023] |Izquierdo, Javier Luis, Canovas and Cabot, Jordi; For a more transparent governance of open source; Communications of the ACM; August 2023 + +|[JaAx2016] |Jaeger, Till, and Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4th ed. Munich: C.H.Beck. 2016 + +|[KuWiSa2008] |Kuhn, Bradley M., Williamson, Aaron; and Sandler, Karen M. A Practical Guide to GPL Compliance. Software Freedom Law Center. 2008. link:https://softwarefreedom.org/resources/2008/compliance-guide.html[https://softwarefreedom.org/resources/2008/compliance-guide.html] + +|[LaOp2023] |Lambach, D. and Oppermann, K.. Narratives of digital sovereignty in German political discourse', Governance, 36(3), pp. 693–709. 2023. Available at: link:https://doi.org/10.1111/gove.12690[https://doi.org/10.1111/gove.12690] + +|[LaWu2022] |Laux, Christian and Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Version 1.0. July 2022 + +|[Le2023] |Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Presentation from 18 September 2023 + +|[OSI2024] |Open Source Initiative. Open Source Licenses by Name. 2024. link:https://opensource.org/licenses/alphabetical[https://opensource.org/licenses/alphabetical] + +|[OSS2024] |Open Source Studie 2024; link:https://www.oss-studie.ch/[https://www.oss-studie.ch/] + +|[Pe1999] |Perens, Bruce. The Open Source Definition. In Open Sources: Voices from the Open Source Revolution.1999. link:https://www.oreilly.com/openbook/opensources/book/perens.html[https://www.oreilly.com/openbook/opensources/book/perens.html]. + +|[SB001] |link:https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/strategien-teilstrategien/strategie-digitale-bundesverwaltung.html[Digital Federal Administration Strategy] and Transformation Plan. + +|[Sc2024] |Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 + +|[ScScPo2017] |Schlauri, Simon, Schweizer, Samuel, and Poledna, Thomas. 2017. Rechtliche Voraussetzungen Der Nutzung von Open-Source-Software in Der Öffentlichen Verwaltung, Insbesondere des Kantons Bern. Carl Grossmann Verlag. link:http://www.oapen.org/search?identifier=632680[http://www.oapen.org/search?identifier=632680] (26 August 2019). + +|[St2011] |Straub, Wolfgang. Softwareschutz: Urheberrecht, Patentrecht, Open Source. Zurich: 2011. Dike. link:https://www.it-recht.ch/wp-content/uploads/2014/11/Straub-Softwareschutz-Open-Source-Software-Zurich-2011.pdf[https://www.it-recht.ch/wp-content/uploads/2014/11/Straub-Softwareschutz-Open-Source-Software-Zurich-2011.pdf]. + +|[St2024] |Stürmer, Matthias. Technological Perspective on Digital Sovereignty, report for the FDFA. 2024 link:https://arxiv.org/abs/2406.03266[[2406.03266\] Technological Perspective on Digital Sovereignty (arxiv.org)] + +|[StGa2018] |Stürmer, Matthias, and Gauch, Carole. Open Source Studie Schweiz 2018. Forschungsstelle Digitale Nachhaltigkeit der Universität Bern. 2018. link:https://www.oss-studie.ch/open-source-studie-2018.pdf[https://www.oss-studie.ch/open-source-studie-2018.pdf]. + +|[StNu2021] |Stürmer, Matthias and Nussbaumer, Jasmin. Open Source Studie Schweiz 2021. Forschungsstelle Digitale Nachhaltigkeit der Universität Bern. 2021. link:https://www.ch-open.ch/open-source-studie-schweiz-2021/[https://www.ch-open.ch/open-source-studie-schweiz-2021/] + +|[Whe2007] |Wheeler, David A. The Free-Libre / Open Source Software (FLOSS) License Slide. 2007. link:https://dwheeler.com/essays/floss-license-slide.pdf[https://dwheeler.com/essays/floss-license-slide.pdf] +|=== + +=== Abbreviations + +This list of abbreviations contains all the abbreviations used in the OSS Em002 document set. A glossary can be found in link:em002-6.adoc[Em002-6 FAQ about Publishing OSS]. + +[options="header",cols="20,80"] +|=== +|Abbreviation |Meaning +|AI |Artificial intelligence +|AO |aApplication owner +|CCPP |Competence Centre for Federal Public Procurement +|CLA |Contributor Licence Agreement +|DCO |Developer Certificate of Origin +|DPSS |Digital Public Services Switzerland (www.digital-public-services-switzerland.ch/strategy) +|EMOTA |Federal Act on the Use of Electronic Means to Carry Out Official Tasks +|FITSU |Federal IT Steering Unit (until 2021) +|FOBL |Federal Office for Buildings and Logistics +|FoIA |Freedom of Information Act +|FSF |Free Software Foundation +|HERMES |Handbuch der Elektronischen Rechenzentren des Bundes, a method for system development (www.hermes.admin.ch) +|OSI |Open Source Initiative +|OSPO |Open Source Programme Office +|OSS |Open source software +|OSSD |Open source software development +|OU |Organisational unit (usually an office) +|SPc |Service procurer +|SPDX |Software Package Data Exchange +|SPv |Service provider +|=== diff --git a/docs/en/em002.md b/docs/en/em002.md deleted file mode 100644 index b8343bc..0000000 --- a/docs/en/em002.md +++ /dev/null @@ -1,797 +0,0 @@ -**Disclaimer:** This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main [README](https://github.com/swiss/opensource-guidelines/tree/main). - ---- - -# Introduction - -## Objective and purpose - -Under Article 9 paragraph 1 of the Federal Act of 17 March 2023[^5] on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), public authorities must disclose the source code of software they develop or commission to perform their duties, unless third-party rights or security-relevant reasons preclude or restrict this. This eliminates legal uncertainty regarding the publication of software by federal authorities. - -In recent years, it has become clear that the importance of open source software (OSS) in the Federal Administration has generally continued to increase. - -These strategic guidelines describe the fundamentals of open source software and how this is handled in the Federal Administration. The document sets out six objectives and proposes nine measures to fulfil these. - -It also gives references to other relevant public sector strategies regarding open source. - -## Background - -In 2005, the Federal IT Strategy Unit (FITSU) published the first version of an OSS strategy for the Federal Administration. At that time, the most important principle was defined as the equal treatment of OSS with closed source software in procurement. - -Since publication in 2005, the prevalence of open source software has steadily increased. Today, according to the Open Source Study Switzerland 2024 report, a clear majority of companies and authorities use open source software in many different areas. In the software industry, very few companies do not work with open source tools and components. - -On 1 February 2019, these Strategic Guidelines for Open Source Software in the Federal Administration and the practical guidelines came into force as Version 1.0. With the enactment of EMOTA and the new obligations under Article 9, it became necessary to align both sets of guidelines with the new status and create additional tools for the federal authorities. - -## Procedure -The federal offices are responsible for implementing EMOTA themselves. However, given the growing importance of open source, it was decided to revise the practical guidelines *[Em002-1](em002-1.md)* together with all stakeholders. Furthermore, additional tools for implementing EMOTA were added. - -The practical guidelines define the necessary concepts, set out the constellations for using open source software, where and how alternatives to existing commercial software can be found, how open source should be procured, what business models exist for open source and what support models are possible when using open source. The other tools provide answers to frequently asked questions and guidance on releasing open source software in accordance with EMOTA. They explore all issues surrounding OSS licences and show how a community can be built around software. Several checklists for guidance and documentation are also made available to federal authorities. - -Documents relating to procurement were also amended, and an additional information sheet [KBB-MB], set of guidelines [BBL-WL] and a checklist [BBL-CL] were drawn up. - -Existing uncertainties are resolved as far as possible with these strategic guidelines, the accompanying practical guidelines and recommendations for action, as well as the additional tools. - -# Reference to other strategies - -These Strategic Guidelines for Open Source Software in the Federal Administration are aligned with four current public sector strategies and EMOTA.[^6] These contain a direct or indirect reference to the topic of open source software and IT collaboration among public institutions: - -The **Digital Federal Administration Strategy** [SB001] sets out eight principles and four priorities. By using open source software, the Federal Administration contributes to priority 4, 'Strengthening digital sovereignty'. An open source solution can be reused any number of times and adapted to the individual needs of the Federal Administration due to its open source code. - -The concept of digital sustainability and digital sovereignty also comes up in the **Digital Public Services Switzerland Strategy 2024–2027**[^7]. The Confederation and cantons will create appropriate conditions for this multiple use. Basic modules for expanding eGovernment will be 'implemented once and used jointly'. Opting for open source software makes it easier to reuse IT solutions. - -According to the **Digital Switzerland Strategy**[^8] it is crucial for Switzerland's success in the digital space to strengthen the networking of federal levels. Particular attention should therefore be paid to coordination between the Confederation, cantons and communes as well as cooperation between organisations active in the field of digitalisation throughout Switzerland. The Federal Council also attached particular importance to Switzerland's digital sovereignty as a focus topic for 2023.[^9] - -In the **Open Government Data Strategy Switzerland (2019–2023)**[^10] the Federal Council states that data from the Federal Administration that is not personal and not security-critical should be published according to the Open by Default principle. The Federal Administration has launched the opendata.swiss portal for this purpose.[^11] Federal offices, cantons, cities and other public organisations have currently published over 11,700 datasets there. - -The Open Government Data Master Plan 2024–2027[^12] implements the Open by Default principle. - -# Governance and tools - -When talking about open source software, a distinction has to be made between **consuming** (using), **contributing** (adding to existing code) and **creating** (i.e. new projects). - -![](./assets/em002/media/image1.png) -Figure 1: The 4 Cs in the context of OSS - -**Collaboration** is also always conceivable in the background. In the case of creation, it must be initiated by the Federal Administration; in the case of contribution, it already exists; and it can also be helpful in the case of consumption (e.g. user group). - -When **consuming** open source software, it should be treated and evaluated as equivalent to proprietary software. - -When **developing** software, open source release is generally mandatory, subject to the exceptions set out in Art. 9 EMOTA (third-party rights and security-relevant reasons). - -These exceptions are addressed in [Em002-2 Instructions for Publishing OSS](em002-2.md). - -The federal authorities, i.e. the administrative units of the Federal Administration, are themselves responsible for correct compliance; there is no centralised responsibility. - -**Publication** brings added value especially when a **community** of interested parties emerges and works together on the software. If the community collaborates on a project and the Federal Administration allows these contributions, economic benefits and synergy effects are created.[^13] - -In practice, release often consists of not only the source code, but also all other aspects (documentation, governance, build instructions, etc.). - -In principle, the Federal Administration has no obligation to build communities; the legal mandate only requires it to publish the source code. The Federal Administration should prioritise investing in communities where the benefit for the Confederation and third parties is great and the effort is as low as possible. - -Currently, there is no common federal platform for **developing and publishing source code**. Each public authority must therefore select a platform (repository) for publication itself. The practical guidelines in [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md) and the associated checklists define how to work with a platform and which properties it must fulfil. - -The **choice of licence** is dealt with in the OSS Licensing Guidelines [Em002-3](em002-3.md)), which presents a selection of standard licences and explains their uses. The Federal Administration should only use its own licence texts in justified cases according to Art. 9 para. 4 EMOTA. - -When using and developing OSS, **support**[^14] must always be regulated (even if it is waived). The responsible administrative unit regulates this during the release process or when defining the community. EMOTA does not make any provisions here, and no additional financing or personnel will be made available for support. It may make sense to include support and joint further development where the benefit for Swiss authorities or the Swiss economy is considered sufficiently large (ecosystem costs) and/or cost-sharing or cooperation is sought. If the supplier takes this on, its support costs can be covered by the users. - -The **procurement of OSS** is done via the Federal Administration's regular procurement process. The FOBL provides the relevant documents and tools. - -In addition, a *Software procurement and Art. 9 EMOTA information sheet* is available[^15] *[KBB-MB]* (see Figure 2). - -Legal and practical considerations mean that under certain circumstances the obligation to release OSS may be transferred to a supplier (during the tender or in operation). The procurement tools and the release process determine how this is to be approached with the supplier. Most of this is achieved by supplementing existing processes, contract drafts and tools. - -The organisational procedure is regulated in [Em002-2 Instructions for Publishing Open Source Software ](em002-2.md) and the associated tools. - -**OSS is treated equally to proprietary software under procurement law.** Since no licence fees are incurred for OSS according to the definition of the Open Source Initiative (OSI), software can be downloaded and used in principle without a tender. Only the services to be provided by companies (e.g. support, engineering) are then subject to procurement law and must be put out to tender. - -Where necessary, the relevant aspects from the tools are integrated into the Confederation's project management processes (i.e. HERMES). - -Open development (direct open development on an openly accessible repository) and participation in existing projects (contribution) are also covered in the explanations in [Em002-4 OSS Community Guidelines](em002-4.md). - -## Overview of OSS documents -The following diagram gives an overview of the documents relevant to OSS in the Federal Administration. - -![](./assets/em002/media/image2.png) -Figure 2: Documents related to Art. 9 EMOTA - -# Objectives - -The following overarching, long-term objectives show how the Federal Administration taps into the potential of open source software and addresses the risks and challenges: - -
-
- A) Compliance with legal requirements (i.e. EMOTA) -
-
- The release of open source software is governed by Article 9 EMOTA. Compliance with this legal requirement is a key aspect of these guidelines and the associated documents. Federal authorities should comply with this article and maximise the benefits for the Federal Administration and Switzerland. The organisational units themselves are responsible for implementation. -
-
-
-
- B) Increase innovation and efficiency -
-
- Open source software serves as the basis of modern IT today. Building on the millions of freely available components and solutions, independent applications can be rapidly developed and operated. The associated time and resource savings and the architectural principles associated with open source software, such as interoperability, agility and microservices, increase the capacity for innovation and efficiency of software development. This in turn accelerates the digitalisation of the Federal Administration. By releasing open source software, the adoption of digital solutions can be accelerated in the federal environment and synergy effects can be utilised. -
-
-
-
-C) Promote a culture of collaboration -
-
- Open source software promotes a culture of collaboration in IT through the sharing of source code, open communication and practices for joint further development. These principles can be applied to increase collaboration in IT within the Federal Administration, with the cantons and with other public institutions. This strengthens digital sovereignty and reduces dependencies on software vendors. -
-
-
-
- D) Create clarity and minimise risks -
-
- Information on frequently used open source licences should enable the Federal Administration to select the right licences. This minimises legal risks. Technical and legal recommendations enable the Federal Administration to use and release open source software. -
-
-
-
- E) Create an overview to utilise synergies -
-
- Open source software is currently used in numerous places within the Federal Administration in different ways. A lot of knowledge and experience is available, but the synergies cannot yet be utilised as there is no overview of the open source solutions in use. Such an overview and the joint procurement of services will make it possible to better exploit the potential of open source software, which saves resources and creates synergies. -
-
-
-
- F) Increase attractiveness as an IT employer -
-
- Open source software is popular with many highly qualified IT professionals. The use of modern open source technologies and the application of open source development methods motivate many employees and increase the attractiveness of the Federal Administration as an employer. To use open source software, the Confederation needs specialists with knowledge and experience of open source software, so efforts should be made when recruiting specialists to expand internal open source know-how. -
-
- -# Measures - -The following measures are intended to help achieve the objectives outlined above. The measures will be supplemented or replaced in due course and adapted to changed circumstances. - -The following table illustrates how the objectives are linked to the corresponding measures. These support implementation of the respective objectives but they may also have an impact on other objectives. -|Objectives | Measures| -|:--| :--| -|**A) Compliance with legal requirements (EMOTA)**|1) Implement the *Practical Guidelines for Open Source Software in the Federal Administration [Em002-1](em002-1.md)*
2) Implement the *Instructions for Publishing Open Source Software [Em002-2](em002-2.md)* and the tools derived from that.
3) Procurement authorities build up open source know-how and thus support the Federal Administration.| -|**B) Increase innovation and efficiency** | 1) Implement the *Practical Guidelines for Open Source Software in the Federal Administration [Em002-1](em002-1.md)*
3) The procurement authorities can deal with open source and optimally support Art. 9 EMOTA.
8) Promote community building | -|**C) Promote a culture of collaboration** | 1) Implement the *Practical Guidelines for Open Source Software in the Federal Administration [Em002-1](em002-1.md)*
4) Promote knowledge and experience exchange
8) Promote community building
9) Examine the possibility of establishing own publication platform; promote Open Development| -|**D) Create clarity and minimise risks** |1) Implement the *Practical Guidelines for Open Source Software in the Federal Administration [Em002-1](em002-1.md)*
2) Implement the *Instructions for Publishing Open Source Software [Em002-2](em002-2.md)* and the tools derived from that.| -|**E) Create an overview to utilise synergies**|6) Implement joint procurement of services
7) Create an overview of open source software used, released and co-developed
8) Promote community building | -|**F) Increase attractiveness as an IT employer** | 5) Promote and communicate an open source culture
8) Promote community building | - -## Description of the measures - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Measure 1: - - Implement the Practical Guidelines for Open Source Software in the Federal Administration [Em002-1](em002-1.md). -
- Although the term open source software is already over 20 years old, the steady spread of open source software and the continuous development of application scenarios constantly lead to new practices and questions. New and further developments of open source solutions are also increasingly forming full-fledged alternatives to proprietary software. With EMOTA, the obligation to publish in-house developments is added. -
- The Practical Guidelines for Open Source Software in the Federal Administration give an overview and introduction to the topic, outlines the advantages and disadvantages of open source software and explains all other tools. It also contains best practices, proven alternatives and practical recommendations on how the Federal Administration should handle open source software. -
- These practical guidelines and the other tools should be used and implemented by the federal authorities when dealing with open source software and releases. -
- As a brief introduction to the topic, an information sheet on the application of Art. 9 EMOTA and [EM002-6 FAQ about Publishing OSS (OSS-FAQ)](em002-6.md) are available. -
- Measure 2: - - Implement the Instructions for Publishing Open Source Software [Em002-2](em002-2.md) and the tools derived from that. -
- The efficient use of OSS in software development often requires contributions in the form of bug fixes and functional enhancements. With EMOTA, there is also an obligation to release self-created software. The necessary guidance is available with various tools.
-The checklists are part of the instructions for publishing OSS. They should be used as a supplement to the corresponding guidelines of the administrative units before and during development.
-The handling of legacy code under Art. 9 EMOTA is also discussed. The aim is to find and implement pragmatic solutions.
-Licences are particularly important in the OSS environment. When releasing, procuring and using software, licences must be aligned with what is legally feasible and the desired effect. The necessary knowledge and corresponding decisions should be documented. In this context, the necessary additional documents such as the Contributor Licence Agreement (CLA) are also provided.
-To facilitate the application of Art. 9 EMOTA, additions will be made to the Confederation's project management method (HERMES). Administrative units should find the necessary tools in the regular process. -
- Measure 3: - - Procurement authorities build up open source know-how and thus support the Federal Administration. -
- The new [Em002-7 Strategic Aspects of Procurement and OSS](em002-7.md) was created to address procurement aspects.
-To ensure broad competition, procurement requires that open and closed source software be treated equally. -The increased requirements in connection with Art. 9 EMOTA regarding the resources to be procured for software publication must be taken into account.
-The Competence Centre for Federal Public Procurement (CCPP) has published an information sheet on software procurement and Art. 9 EMOTA [KBB-MB] at the following link https://perimap.admin.ch/goto_perimap_file_46835_download.html.
-Further assistance is available on the FOBL intranet (accessible only from the federal network) with the Open Source in Procurement Guidelines [BBL-WL] and the Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL]. -
- Measure 4: - - Promote knowledge and experience exchange -
- Creating and using open source software requires in-depth, specialised know-how. At the same time, open source solutions are constantly evolving and new open source projects are being launched. It is therefore a challenge to maintain a comprehensive overview of current trends and technologies.
-To promote the professional use of open source and facilitate the exchange of knowledge and experience, information should be shared within an extended community of interest, and employees within the Federal Administration should be competently supported. -
- Measure 5: - - Promote and communicate an open source culture -
- Advancing digitalisation has further exacerbated the shortage of skilled workers in IT. This also makes it difficult for the Federal Administration's service providers to recruit qualified IT staff. The use of open source software and the associated developer culture is known to be an argument for professionals to apply for such positions.
-In order to be perceived by the public as an 'open source-friendly' employer, the various measures and the open source solutions used should be actively communicated in the form of a technology radar.[^16] For employer attractiveness, it is also important to allow federal employees to contribute to existing open source software. -
- Measure 6: - - Implement joint procurement of services -
- Maintenance and support of open source software is currently provided by internal employees of the Federal Administration, while external suppliers offer services for certain open source solutions. These services are often procured independently by the respective offices, which can lead to duplication and the associated financial losses.
-The joint procurement of services for open source software should increase the reliability of maintenance and support in operation and simplify the use of open source solutions. Based on the technology radar (see Measure 5), services for the most widespread open source systems and technologies should be centrally procured. These services can then be obtained by all offices as needed.[^17] -
- Measure 7: - - Create an overview of open source software used, released and co-developed. -
- Since no licences need to be purchased when using open source software, the time-consuming procurement process is often eliminated.
-This makes it difficult to track where the Federal Administration uses which open source software. As a result, the potential of open source software – such as the use of synergies, the formation of communities for the experience exchange, etc. – cannot be fully utilised.
-A technology radar within the Federal Administration should provide an overview of where which open source software is being used and who has what know-how. -
- Measure 8: - - Promote community building -
- Building and participating in communities for project development is very important for OSS. A significant number of synergies result from this. It may be that the project already exists and the Confederation only participates, or the Confederation may lead the project, or indeed it may be a collaboration. Omitting a community is also an important decision. Direct development on an open repository14 (without subsequent release) can bring further efficiency gains and promote joint development. Em002-4 provides guidance and motivation for community building by the federal authorities. -
- Measure 9: - - Examine the possibility of establishing own publication platform; promote Open Development -
-The establishment and operation of an internal or Swiss publication platform will be examined and implemented after such a decision has been taken.
-The aim of an independent platform for the Federal Administration is to preserve digital sovereignty and independence. Collaboration is simplified and at the same time it creates an overview of activities.
-Federal cooperation across all authorities in Switzerland (similar to opencode.de) is being examined (e.g. DPSS or eOperations Switzerland). -
- -# Annexes - -## Changes from previous version - -* Minor editorial changes and improvements. -* Factsheet Em002-5 has been replaced by the OSS tools information sheet'. -* A new addition is the document '[Em002-7 Procurement and OSS](./em002-7.md)'. -* New diagram depicting the 4 Cs in the context of OSS (addition of 'collaboration'). -* New FOBL and CCPP references. - -## References for OSS tools - -The following reference table lists the documents relating to the document set for [Em002 Tools for Open Source Software](./em002.md) in the Federal Administration. - - - - - -
- Source note: The tools and especially the checklists are partly based on the OSS documents of the Canton of Bern , which are released under a BSD3 licence (https://github.com/kanton-bern/oss). -
- -The current Em002 documents are published on the OSS resources page of the Federal Chancellery. https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html). - -The English version is also published as markdown on GitHub. Feedback can also be given there. https://github.com/swiss/opensource-guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- [Em002] - - Em002 Strategic Guidelines for Open Source Software in the Federal Administration, version 2.0, 2025 -
- [Em002-1] - - Em002-1 Practical Guidelines for Open Source Software in the Federal Administration, version 2.0, 2025 -
- [Em002-2] - - Em002-2 Instructions for Publishing Open Source Software, version 2.0, 2025 -
- [Em002-2.1] - - Em002-2.1 OSS Preliminary Assessment Checklist, version 2.0, 2025 -
- [Em002-2.2] - - Em002-2.2 OSS Analysis and Preparation Checklist, version 2.0, 2025 -
- [Em002-2.3] - - Em002-2.3 OSS Release and Publication Checklist, version 2, 2025 -
- [Em002-3] - - Em002-3 OSS Licensing Guidelines, version 2.0, 2025 -
- [Em002-4] - - Em002-4 OSS Community Guidelines, version 2.0, 2025 -
- [Em002-4.1] - - Em002-4.1 OSS Community Checklist, version 2.0, 2025 -
- [Em002-5] - - Em002-5 OSS Tools information sheet, Version 2.0, 2025 -
- [Em002-6] - - Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS), version 2.0. 2025 -
- [Em002-7] - - Em002-7 Strategic Aspects of Procurement and Open Source Software, version 2.0, 2025 -
- [BBL-WZK] - - Information sheets for the FOBL requesting offices can be found in the corresponding toolbox (in German):https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html -
- [BBL-AGB] - - GTCs of the Confederation. https://www.bkb.admin.ch/bkb/de/home/themen/agb.html -
- [BBL-WL] - - Open Source in Procurement guidelines, FOBL; 2025
-Decision-making aid for purchasers in projects with possible OSS relevance. Contains information on correct implementation in tenders and contracts. (PDF)
- Only accessible to federal agencies on the federal intranet -
- [BBL-CL] - - Checklist for Art. 9 EMOTA Blanket Exception, FOBL, 2025,
-Assists in reviewing and documenting whether, in individual cases, the publication of developed software can be waived. (DOCX)
- Only accessible to federal agencies on the federal intranet -
- [KBB-MB] - - Information sheet: Software procurement and Art. 9 EMOTA, Competence Centre for Federal Public Procurement:
-https://perimap.admin.ch/goto_perimap_file_46835_download.html -
- [KBB-KV] - - Musterkriterien Kriterien – Beschaffung und EMBAG https://perimap.admin.ch/goto_perimap_file_47064_download.html
-Mustertexte Vertrag – Software-Entwicklung
-https://perimap.admin.ch/goto_perimap_file_47059_download.html -
- [KBB-Perimap] - - Lern und Vorlagenplattform KBB (Registration is required) -
- -Visual overview of OSS tools: -![](./assets/em002/media/image2.png) - -Figure 3: Documents in connection with Art. 9 EMOTA - -## General references -All references to the Em002 document set can be found here *in Em002 Strategic Guidelines [Em002*]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- [A029] - - Product standard for office automation (OA) client software -Intranet: https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/standards/a029-bab_client_software.html -
- [BITKOM2023] - - Leitfaden Open-Source-Software 2.0. Berlin: Bitkom e. V. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. BIT-KOM. 2023. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html -
- [BöB] - - Federal Act on Public Procurement (PPA) https://www.fedlex.admin.ch/eli/oc/2020/126/de -
- [DigiV] - - Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) - SR 172.019.1 – Ordinance of 2 April 2025 | Fedlex -
- [EY2011] - - Open Source Software im geschäftskritischen Einsatz. Ernst & Young. 2011. https://www.yumpu.com/de/document/read/23276493/open-source-software-ernst-young. -
- [EMBAG2023] - - 172.019 Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA) https://www.fedlex.admin.ch/eli/cc/2023/682/de -
- [Fr2012] - - Fröhlich-Bleuler, Gianni. Open Source Compliance. Jusletter 12 November 2012. -
- [Ga2021] - - Gartner for Application and Software Engineering Leaders Tool: Open Source Software Governance Policy Template. Gartner, March 2021 -
- [GoAy2022] - - Goldstein, Ayala. Top 10 Open Source Licenses in 2022: Trends and Predictions. 2022. https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions -
- [Gu2024] - - Günter, Matthias. Selection criteria for enterprise-ready Open Source software. 2024. https://gnostx.com/wp_gnostx/blog/2024/05/31/selection-criteria-for-enterprise-ready-open-source-software/ -
- [IZqCab2023] - - Izquierdo, Javier Luis, Canovas and Cabot, Jordi; For a more transparent governance of open source; Communications of the ACM; August 2023 -
- [JaAx2016] - - Jaeger, Till, and Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4th ed. Munich: C.H.Beck. 2016 -
- [KuWiSa2008] - - Kuhn, Bradley M., Williamson, Aaron; and Sandler, Karen M. A Practical Guide to GPL Compliance. Software Freedom Law Center. 2008. https://softwarefreedom.org/resources/2008/compliance-guide.html -
- [LaOp2023] - - Lambach, D. and Oppermann, K.. Narratives of digital sovereignty in German political discourse’, Governance, 36(3), pp. 693–709. 2023. Available at: https://doi.org/10.1111/gove.12690 -
- [LaWu2022] - - Laux, Christian and Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Version 1.0. July 2022 -
- [Le2023] - - Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Presentation from 18 September 2023 -
- [OSI2024] - - Open Source Initiative. Open Source Licenses by Name. 2024. https://opensource.org/licenses/alphabetical -
- [OSS2024] - - Open Source Studie 2024; https://www.oss-studie.ch/ -
- [Pe1999] - - Perens, Bruce. The Open Source Definition. In Open Sources: Voices from the Open Source Revolution.1999. https://www.oreilly.com/openbook/opensources/book/perens.html. -
- [SB001] - - Digital Federal Administration Strategy and Transformation Plan. -
- [Sc2024] - - Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 -
- [ScScPo2017] - - Schlauri, Simon, Schweizer, Samuel, and Poledna, Thomas. 2017. Rechtliche Voraussetzungen Der Nutzung von Open-Source-Software in Der Öffentlichen Verwaltung, Insbesondere des Kantons Bern. Carl Grossmann Verlag. http://www.oapen.org/search?identifier=632680 (26 August 2019). -
- [St2011] - - Straub, Wolfgang. Softwareschutz: Urheberrecht, Patentrecht, Open Source. Zurich: 2011. Dike. https://www.it-recht.ch/wp-content/uploads/2014/11/Straub-Softwareschutz-Open-Source-Software-Zurich-2011.pdf. -
- [St2024] - - Stürmer, Matthias. Technological Perspective on Digital Sovereignty, report for the FDFA. 2024 [2406.03266] Technological Perspective on Digital Sovereignty (arxiv.org) -
- [StGa2018] - - Stürmer, Matthias, and Gauch, Carole. Open Source Studie Schweiz 2018. Forschungsstelle Digitale Nachhaltigkeit der Universität Bern. 2018. https://www.oss-studie.ch/open-source-studie-2018.pdf. -
- [StNu2021] - - Stürmer, Matthias and Nussbaumer, Jasmin. Open Source Studie Schweiz 2021. Forschungsstelle Digitale Nachhaltigkeit der Universität Bern. 2021. https://www.ch-open.ch/open-source-studie-schweiz-2021/ -
- [Whe2007] - - Wheeler, David A. The Free-Libre / Open Source Software (FLOSS) License Slide. 2007. https://dwheeler.com/essays/floss-license-slide.pdf -
- -## Abbreviations - -This list of abbreviations contains all the abbreviations used in the OSS Em002 document set. A glossary can be found in [Em002-6 FAQ about Publishing OSS](em002-6.md). - -|Abbreviation|Meaning| -|:--|:--| -|AI|Artificial intelligence| -|AO|aApplication owner| -|CCPP|Competence Centre for Federal Public Procurement| -|CLA|Contributor Licence Agreement| -|DCO|Developer Certificate of Origin| -|DPSS|Digital Public Services Switzerland (www.digital-public-services-switzerland.ch/strategy)| -|EMOTA|Federal Act on the Use of Electronic Means to Carry Out Official Tasks| -|FITSU|Federal IT Steering Unit (until 2021)| -|FOBL|Federal Office for Buildings and Logistics| -|FoIA|Freedom of Information Act| -|FSF|Free Software Foundation| -|HERMES|Handbuch der Elektronischen Rechenzentren des Bundes, a method for system development (www.hermes.admin.ch)| -|OSI|Open Source Initiative| -|OSPO|Open Source Programme Office| -|OSS|Open source software| -|OSSD|Open source software development| -|OU|Organisational unit (usually an office)| -|SPc|Service procurer| -|SPDX|Software Package Data Exchange| -|SPv|Service provider| - -[^1]: Recommendation for Federal Administration IT in accordance with - \[P035\] *Section 4.6* - -[^2]: For definitions of the INTERNAL and CONFIDENTIAL classifications, - see the *Ordinance of 8 November 2023 on Information Security in the - Federal Administration and Armed Forces (InfoSecO; SR 128.1)* - -[^3]: See footnote 1 - -[^4]: Planning areas in accordance with the *Federal Administration IT - Strategy 2020--2023 of 3 April 2020 (SB000)* - -[^5]: SR 172.019 - -[^6]: SR 172.019: - -[^7]: Digital Public Services Switzerland Strategy 2024--2027: - - -[^8]: - -[^9]: https://digital.swiss/en/strategy/focus-topics/digital-sovereignty - -[^10]: Open Government Data Strategy 2019 -- 2023 - -[^11]: https://opendata.swiss/en - -[^12]: https://www.bfs.admin.ch/asset/en/28425806 - -[^13]: , - Section 4 (in German) - -[^14]: At least during the lifecycle by way of contracts or a community. - -[^15]: Available here (in German): and - -[^16]: Technology radars should be used as widely as possible. This means, if possible, at the level of the federal authorities or even the Federal Administration. - -[^17]: This concerns support for the software in use. Third party support for software released under EMOTA is possible and may be charged for. This is covered in [Em002-4 OSS Community Guidelines.](./em002-4.md) - -[^18]: https://en.wikipedia.org/wiki/Software_repository \ No newline at end of file diff --git a/docs/index_en.adoc b/docs/index_en.adoc new file mode 100644 index 0000000..4ce752e --- /dev/null +++ b/docs/index_en.adoc @@ -0,0 +1,55 @@ += Tools for Publishing Open Source Software +:lang: en +:toc: +:sectnums: +:toclevels: 3 +:sectnumlevels: 3 +:experimental: +:revnumber: 1.0 +:revdate: 14.09.2026 + +Federal agencies are required to disclose the source code of software they develop or have developed to fulfill their duties. They must allow anyone to use, further develop, and distribute the software without charging licensing fees. This requirement is outlined in Article 9 of the Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA). Responsibility for implementation lies with the individual agencies. The Federal Chancellery provides suitable tools to assist federal agencies in meeting this requirement. + +== What is it about? + +When publishing open-source software, questions regarding legal matters, licenses, security, organization, and costs need to be addressed. Depending on the specific use case, there are variations and limitations to consider. The level of knowledge required to implement the legal requirement varies within the federal administration based on experience. For this reason, the Federal Chancellery has created tools and checklists to provide support and guidance for decision-making. + +== Who is responsible? + +The individual agencies are responsible for implementation. The Federal Chancellery provides suitable tools to assist federal agencies in this process. + +== What tools are available? + +The following tools are available in the form of guidelines, instructions, checklists, fact sheets, and FAQs: + +link:en/em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] (05.05.2026) + +link:en/em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] (05.05.2026) + +link:en/em002-2.adoc[Em002-2 Instructions for Publishing OSS] (05.05.2026) + +link:en/em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 Preliminary Assessment Checklist] (ODT, 05.05.2026) + +link:en/em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist] (ODT, 92 kB, 05.05.2026) + +link:en/em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 Release and Publication Checklist] (ODT, 93 kB, 05.05.2026) + +link:en/em002-3.adoc[Em002-3 OSS Licensing Guidelines] (05.05.2026) + +link:en/em002-4.adoc[Em002-4 OSS Community Guidelines] (05.05.2026) + +link:en/em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] (ODT, 94 kB, 05.05.2026) + +link:en/em002-5.adoc[Em002-5 EMOTA and OSS Factsheet] (06.05.2026) + +link:en/em002-6.adoc[Em002-6 FAQ on OSS and Art. 9 EMOTA] (05.05.2026) + +link:en/em002-7.adoc[Em002-7 OSS Guideline: Applying Article 9 of Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA)] (05.05.2026) + +https://www.bk.admin.ch/dam/bk/de/dokumente/dti/OSS/oss_merkblatt_kbb_beschaffung_artikel9_embag.pdf.download.pdf/Merkblatt_KBB_Beschaffung-Software-Art9-EMBAG_de.pdf[Merkblatt KBB Beschaffung Software Artikel 9 EMBAG] (PDF, 177 kB, 13.08.2025) only available in German, French and Italian + +== Further information + +https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html[Federal Act on the Use of Electronic Means to Carry Out Official Tasks EMOTA] only available in German + +http://www.opensource.admin.ch/[OSS Catalogue] diff --git a/docs/index_en.md b/docs/index_en.md deleted file mode 100644 index c48f19f..0000000 --- a/docs/index_en.md +++ /dev/null @@ -1,48 +0,0 @@ -# Tools for Publishing Open Source Software - -Federal agencies are required to disclose the source code of software they develop or have developed to fulfill their duties. They must allow anyone to use, further develop, and distribute the software without charging licensing fees. This requirement is outlined in Article 9 of the Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA). Responsibility for implementation lies with the individual agencies. The Federal Chancellery provides suitable tools to assist federal agencies in meeting this requirement. - -## What is it about? - -When publishing open-source software, questions regarding legal matters, licenses, security, organization, and costs need to be addressed. Depending on the specific use case, there are variations and limitations to consider. The level of knowledge required to implement the legal requirement varies within the federal administration based on experience. For this reason, the Federal Chancellery has created tools and checklists to provide support and guidance for decision-making. - -## Who is responsible? - -The individual agencies are responsible for implementation. The Federal Chancellery provides suitable tools to assist federal agencies in this process. - -## What tools are available? - -The following tools are available in the form of guidelines, instructions, checklists, fact sheets, and FAQs: - -[Em002 Strategic Guidelines for Open Source Software in the Federal Administration](en/em002.md) (05.05.2026) - -[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration](en/em002-1.md) (05.05.2026) - -[Em002-2 Instructions for Publishing OSS](en/em002-2.md) (05.05.2026) - -[Em002-2.1 Preliminary Assessment Checklist](/en/Em002-2.1%20Checklist%20OSS%20Preliminary%20Assessment.odt) (ODT, 05.05.2026) - -[Em002-2.2 Analysis and Preparation Checklist](en/Em002-2.2%20Checklist%20OSS%20Analysis%20and%20Preparation.odt) (ODT, 92 kB, 05.05.2026) - -[Em002-2.3 Release and Publication Checklist](en/Em002-2.3%20Checklist%20OSS%20Release%20and%20Publication%20.odt) (ODT, 93 kB, 05.05.2026) - -[Em002-3 OSS Licensing Guidelines](en/em002-3.md) (05.05.2026) - -[Em002-4 OSS Community Guidelines](en/em002-4.md) (05.05.2026) - -[Em002-4.1 OSS Community Checklist](en/Em002-4.1%20Checklist%20OSS%20Community.odt) (ODT, 94 kB, 05.05.2026) - -[Em002-5 EMOTA and OSS Factsheet](en/em002-5.md) (06.05.2026) - -[Em002-6 FAQ on OSS and Art. 9 EMOTA](en/em002-6.md) (05.05.2026) - -[Em002-7 OSS Guideline: Applying Article 9 of Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA)](en/em002-7.md) (05.05.2026) - -[Merkblatt KBB Beschaffung Software Artikel 9 EMBAG](https://www.bk.admin.ch/dam/bk/de/dokumente/dti/OSS/oss_merkblatt_kbb_beschaffung_artikel9_embag.pdf.download.pdf/Merkblatt_KBB_Beschaffung-Software-Art9-EMBAG_de.pdf) (PDF, 177 kB, 13.08.2025) only available in German, French and Italian - -## Further information - -[Federal Act on the Use of Electronic Means to Carry Out Official Tasks EMOTA](https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html) only available in German - -[OSS Catalogue](http://www.opensource.admin.ch/) - From b321927777bd665cdaf83477e98cca6e16bf5105 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Mon, 14 Sep 2026 16:19:20 +0200 Subject: [PATCH 02/58] Add devenv for local docs rendering via open-govpress Adds a devenv.nix/.envrc setup providing git, gh, asciidoctor, pandoc, and an open-govpress wrapper (FHS-wrapped since the packaged Electron binary can't run natively on NixOS) plus a render-docs script that renders every tracked .adoc file to PDF. The open-govpress build is downloaded on demand from a GitHub Release and verified against a pinned sha256 rather than committed to the repo: at ~112MiB it clears GitHub's 100MB hard limit on regular git objects, and this repo is a fork, which GitHub's LFS policy blocks from uploading new LFS objects at all. Also expands each generated .adoc document's header with the full set of open-govpress front-block attributes (govpress-style, classification, title-logo-*, url-repo) that the render CLI reads directly from the document. Verified: devenv shell -- render-docs renders all 15 tracked .adoc files to valid PDFs with zero errors. --- .envrc | 8 + .gitignore | 11 ++ README.adoc | 11 ++ devenv.lock | 65 +++++++ devenv.nix | 168 ++++++++++++++++++ devenv.yaml | 4 + .../en/assets/em002-2/md/README_template.adoc | 11 ++ docs/en/em002-1.adoc | 11 ++ ...-checklist-oss-preliminary-assessment.adoc | 11 ++ ...hecklist-oss-analysis-and-preparation.adoc | 11 ++ ...checklist-oss-release-and-publication.adoc | 11 ++ docs/en/em002-2.adoc | 11 ++ docs/en/em002-3.adoc | 11 ++ .../en/em002-4-1-checklist-oss-community.adoc | 11 ++ docs/en/em002-4.adoc | 11 ++ docs/en/em002-5.adoc | 11 ++ docs/en/em002-6.adoc | 11 ++ docs/en/em002-7.adoc | 11 ++ docs/en/em002.adoc | 11 ++ docs/index_en.adoc | 11 ++ 20 files changed, 421 insertions(+) create mode 100644 .envrc create mode 100644 .gitignore create mode 100644 devenv.lock create mode 100644 devenv.nix create mode 100644 devenv.yaml diff --git a/.envrc b/.envrc new file mode 100644 index 0000000..e7a7433 --- /dev/null +++ b/.envrc @@ -0,0 +1,8 @@ +#!/usr/bin/env bash +# shellcheck disable=all # https://devenv.sh/integrations/direnv/#configure-shell-activation + +eval "$(devenv direnvrc)" + +# You can pass flags to the devenv command +# For example: use devenv --impure --option services.postgres.enable:bool true +use devenv diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..01dbd08 --- /dev/null +++ b/.gitignore @@ -0,0 +1,11 @@ +# devenv / direnv +.devenv* +.direnv/ + +# open-govpress: downloaded from a GitHub Release and extracted on demand, +# see devenv.nix +/open-govpress/.cache/ +/open-govpress/.extracted/ + +# rendered output (build artifacts, not source) +*.pdf diff --git a/README.adoc b/README.adoc index 9a3147f..1592cb0 100644 --- a/README.adoc +++ b/README.adoc @@ -1,5 +1,15 @@ = Guidelines to open source software (according to Article 9 EMOTA) :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main This repository contains *evolving drafts* of guidelines and tools to support the Federal Administration in publishing open source code. The *official and binding versions* are available in all official languages on the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Swiss Federal Chancellery website]. diff --git a/devenv.lock b/devenv.lock new file mode 100644 index 0000000..3f8b812 --- /dev/null +++ b/devenv.lock @@ -0,0 +1,65 @@ +{ + "nodes": { + "devenv": { + "locked": { + "dir": "src/modules", + "lastModified": 1789340509, + "narHash": "sha256-It2AD16uFwiAe9GvuLbk+j+qTDrQxT3XPclL71ZnJ3I=", + "owner": "cachix", + "repo": "devenv", + "rev": "6e830506b517d6a373f2dec6ee8c7f4683908856", + "type": "github" + }, + "original": { + "dir": "src/modules", + "owner": "cachix", + "repo": "devenv", + "type": "github" + } + }, + "nixpkgs": { + "inputs": { + "nixpkgs-src": "nixpkgs-src" + }, + "locked": { + "lastModified": 1787753358, + "narHash": "sha256-Tl77VbWyAKrOfRNQhL6JbQtb/MLzbYa/1RG1gWWfICk=", + "owner": "cachix", + "repo": "devenv-nixpkgs", + "rev": "256551e45f6303e142ab4a98be1bf243feb77dc0", + "type": "github" + }, + "original": { + "owner": "cachix", + "ref": "rolling", + "repo": "devenv-nixpkgs", + "type": "github" + } + }, + "nixpkgs-src": { + "flake": false, + "locked": { + "lastModified": 1787394516, + "narHash": "sha256-pRGOQSClnXNI2iLUG6DYpsGvYcuw0drOutVZFTJNw90=", + "owner": "NixOS", + "repo": "nixpkgs", + "rev": "c8f90650c15282fa8656a041bfbbd2403997a9a7", + "type": "github" + }, + "original": { + "owner": "NixOS", + "ref": "nixpkgs-unstable", + "repo": "nixpkgs", + "type": "github" + } + }, + "root": { + "inputs": { + "devenv": "devenv", + "nixpkgs": "nixpkgs" + } + } + }, + "root": "root", + "version": 7 +} \ No newline at end of file diff --git a/devenv.nix b/devenv.nix new file mode 100644 index 0000000..0ae3b00 --- /dev/null +++ b/devenv.nix @@ -0,0 +1,168 @@ +{ + pkgs, + lib, + config, + ... +}: + +let + # open-govpress (https://github.com/swiss-armed-forces/cyber-command/cea/open-govpress) + # is the CLI used to render these .adoc documents to PDF. It ships as a + # generic dynamically-linked Linux binary (electron-builder's tar.gz + # target), which cannot execute directly on NixOS -- there is no + # /lib64/ld-linux-x86-64.so.2 and no FHS layout for it to find its shared + # libraries in. Wrapping it in an FHS environment (the same trick nixpkgs + # itself uses for Chrome/Electron/AppImage binaries) lets the unmodified + # upstream tarball run as-is, with no patchelf/rebuild step. + # + # The build is fetched from a GitHub Release rather than committed to the + # repo: at ~112MiB it clears GitHub's 100MB hard limit on regular git + # objects, and this repo is a fork, which GitHub's LFS policy blocks from + # uploading *new* LFS objects at all -- release assets hit neither limit. + govpressVersion = "0.0.7"; + govpressUrl = "https://github.com/736-c41-2c1-e464fc974/opensource-guidelines/releases/download/open-govpress-v${govpressVersion}/open-govpress-${govpressVersion}-linux-x64.tar.gz"; + govpressSha256 = "3766f1da1137208a438abe06b4ad8427734e1de782aac33ff1d47df3e975ecdf"; + + govpressFHS = pkgs.buildFHSEnv { + name = "open-govpress-fhs"; + targetPkgs = + pkgs: with pkgs; [ + glib + nss + nspr + atk + at-spi2-atk + at-spi2-core + cups + dbus + libdrm + gtk3 + pango + cairo + xorg.libX11 + xorg.libXcomposite + xorg.libXdamage + xorg.libXext + xorg.libXfixes + xorg.libXrandr + xorg.libxcb + xorg.libxshmfence + libxkbcommon + mesa + libGL + alsa-lib + expat + libgbm + systemd + ]; + }; +in +{ + env = { + DO_NOT_TRACK = 1; + }; + + dotenv = { + enable = true; + disableHint = true; + }; + + # https://devenv.sh/packages/ + packages = with pkgs; [ + git + gh + curl + + # document creation / verification + # + # Used ad hoc throughout this repo's Markdown -> AsciiDoc migration to + # render and sanity-check every converted .adoc file; kept here so that + # workflow doesn't depend on remembering `nix-shell -p asciidoctor`. + asciidoctor-with-extensions # asciidoctor-pdf, asciidoctor-reducer, asciidoctor-diagram + pandoc + + # headless rendering + xvfb-run + ]; + + enterShell = '' + ( + set -euo pipefail + cd '${config.devenv.root}' + + if tty -s; then + devenv-help + fi + ) + ''; + + scripts.devenv-help = { + description = "Print this help"; + exec = '' + set -euo pipefail + cd '${config.devenv.root}' + + echo + echo "Helper scripts provided by the devenv:" + echo + sed -e 's| |XXXXXX|g' -e 's|=| |' <... -o out.pdf`. + # + # Always run under xvfb-run: Electron has no headless mode and the packaged + # binary refuses to render without a display (exit code 5). xvfb-run makes + # this work the same way whether or not the calling shell has a real + # display, which keeps local dev and CI identical. + # + # Downloads and extracts the release tarball on first use rather than at + # `enterShell` time, so entering the shell stays fast when nobody needs to + # render anything, and caches both under open-govpress/ (gitignored) so + # repeat invocations don't re-fetch or re-extract. + scripts.open-govpress = { + description = "Render .adoc documents (open-govpress render ... -o out.pdf)"; + exec = '' + set -euo pipefail + cd '${config.devenv.root}' + + govpress_cache_dir="$(pwd)/open-govpress/.cache" + govpress_archive="''${govpress_cache_dir}/open-govpress-${govpressVersion}-linux-x64.tar.gz" + govpress_extract_dir="$(pwd)/open-govpress/.extracted" + govpress_bin="''${govpress_extract_dir}/open-govpress-${govpressVersion}/open-govpress" + + if [ ! -x "''${govpress_bin}" ]; then + mkdir -p "''${govpress_cache_dir}" "''${govpress_extract_dir}" + + if [ ! -f "''${govpress_archive}" ]; then + ${lib.getExe pkgs.curl} -fL --retry 3 -o "''${govpress_archive}.part" '${govpressUrl}' + mv "''${govpress_archive}.part" "''${govpress_archive}" + fi + + echo '${govpressSha256} '"''${govpress_archive}" | ${pkgs.coreutils}/bin/sha256sum -c - + tar xzf "''${govpress_archive}" -C "''${govpress_extract_dir}" + fi + + exec ${lib.getExe govpressFHS} ${lib.getExe pkgs.xvfb-run} -a "''${govpress_bin}" --no-sandbox "''${@}" + ''; + }; + + # Renders every tracked .adoc file in the repo to PDF, next to its source + # -- a quick way to sanity-check the whole corpus still renders after an + # edit, mirroring the check every converting agent ran individually during + # the Markdown -> AsciiDoc migration. + scripts.render-docs = { + description = "Render every .adoc document in the repo to PDF"; + exec = '' + set -euo pipefail + cd '${config.devenv.root}' + + mapfile -t docs < <(git ls-files '*.adoc') + echo "Rendering ''${#docs[@]} documents..." + open-govpress render "''${docs[@]}" + ''; + }; +} diff --git a/devenv.yaml b/devenv.yaml new file mode 100644 index 0000000..bbbefa7 --- /dev/null +++ b/devenv.yaml @@ -0,0 +1,4 @@ +inputs: + nixpkgs: + url: github:cachix/devenv-nixpkgs/rolling +allowUnfree: true diff --git a/docs/en/assets/em002-2/md/README_template.adoc b/docs/en/assets/em002-2/md/README_template.adoc index 6b85c07..026a50d 100644 --- a/docs/en/assets/em002-2/md/README_template.adoc +++ b/docs/en/assets/em002-2/md/README_template.adoc @@ -1,5 +1,15 @@ = README Template :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main == Project Title diff --git a/docs/en/em002-1.adoc b/docs/en/em002-1.adoc index 1a27c12..541b8ca 100644 --- a/docs/en/em002-1.adoc +++ b/docs/en/em002-1.adoc @@ -1,5 +1,15 @@ = Em002-1 Practical Guidelines for Open Source Software in the Federal Administration :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc index a234ca2..5603d69 100644 --- a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc +++ b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc @@ -1,5 +1,15 @@ = Em002-2.1 OSS Preliminary Assessment Checklist :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main This checklist is part of the document _Em002-2 Instructions for Publishing Open Source Software_. It should be completed at the start of a project or when clarifying whether software does not need to be published. diff --git a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc index 0ff664f..bb85af8 100644 --- a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc +++ b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc @@ -1,5 +1,15 @@ = Em002-2.2 OSS Analysis and Preparation Checklist :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main This checklist is part of _Em002-2 Instructions for Publishing Open Source Software_ and is intended for ICT professionals. + It serves to review the documentation and source code of a project. In doing so, it helps ensure that the quality level of the documentation is sufficient to publish an application as open source. It can also be used to verify that the source code and all third-party components used by the project do not pose any legal risks. These measures minimise security risks. + diff --git a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc index 83e52bd..fa6b88b 100644 --- a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc +++ b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc @@ -1,5 +1,15 @@ = Em002-2.3 OSS Release and Publication Checklist :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main This checklist is part of the document 'Em002-2 Instructions for Publishing Open Source Software'. diff --git a/docs/en/em002-2.adoc b/docs/en/em002-2.adoc index 2db5c38..e4cb846 100644 --- a/docs/en/em002-2.adoc +++ b/docs/en/em002-2.adoc @@ -1,5 +1,15 @@ = Em002-2 Instructions for Publishing OSS :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main *Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code.footnote:[Recommendation for Federal Administration IT in accordance with ++[++P035++]++ _Section 4.6_]footnote:[For definitions of the INTERNAL and CONFIDENTIAL classifications, see the _Ordinance of 8 November 2023 on Information Security in the Federal Administration and Armed Forces (InfoSecO; SR 128.1)_]footnote:[See footnote 1]footnote:[Planning areas in accordance with the _Federal Administration IT Strategy 2020-2023 of 3 April 2020 (SB000)_] For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002-3.adoc b/docs/en/em002-3.adoc index 53cd480..3a9585f 100644 --- a/docs/en/em002-3.adoc +++ b/docs/en/em002-3.adoc @@ -1,5 +1,15 @@ = Em002-3 OSS Licensing Guidelines :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main *Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002-4-1-checklist-oss-community.adoc b/docs/en/em002-4-1-checklist-oss-community.adoc index 7c59f6d..805e046 100644 --- a/docs/en/em002-4-1-checklist-oss-community.adoc +++ b/docs/en/em002-4-1-checklist-oss-community.adoc @@ -1,5 +1,15 @@ = Em002-4.1 OSS Community Checklist :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main This checklist goes together with _Em002-2 Instructions for Publishing Open Source Software_ and _Em002-4 OSS Community Guidelines_. + It must be filled in at the start of a project or at the start of the clarifications for release and subsequently completed. + diff --git a/docs/en/em002-4.adoc b/docs/en/em002-4.adoc index 66cb3ef..3dc5d77 100644 --- a/docs/en/em002-4.adoc +++ b/docs/en/em002-4.adoc @@ -1,5 +1,15 @@ = Em002-4 OSS Community Guidelines :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002-5.adoc b/docs/en/em002-5.adoc index 945da98..a65ecad 100644 --- a/docs/en/em002-5.adoc +++ b/docs/en/em002-5.adoc @@ -1,5 +1,15 @@ = Em002-5 EMOTA and OSS Factsheet :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main [IMPORTANT] ==== diff --git a/docs/en/em002-6.adoc b/docs/en/em002-6.adoc index 69ada27..9175538 100644 --- a/docs/en/em002-6.adoc +++ b/docs/en/em002-6.adoc @@ -1,5 +1,15 @@ = Em002-6 FAQ on OSS and Art. 9 EMOTA :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002-7.adoc b/docs/en/em002-7.adoc index 6341ece..6334e80 100644 --- a/docs/en/em002-7.adoc +++ b/docs/en/em002-7.adoc @@ -1,5 +1,15 @@ = Em002-7 OSS Guideline: Applying Article 9 EMOTA :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main *Disclaimer:* This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/en/em002.adoc b/docs/en/em002.adoc index 20ba61b..4eed241 100644 --- a/docs/en/em002.adoc +++ b/docs/en/em002.adoc @@ -1,5 +1,15 @@ = Em002 Strategic Guidelines for Open Source Software in the Federal Administration :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main NOTE: This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main link:https://github.com/swiss/opensource-guidelines/tree/main[README]. diff --git a/docs/index_en.adoc b/docs/index_en.adoc index 4ce752e..b097618 100644 --- a/docs/index_en.adoc +++ b/docs/index_en.adoc @@ -1,5 +1,15 @@ = Tools for Publishing Open Source Software :lang: en +:govpress-style: report +:govpress-front-block: report +:classification: +:title-logo: logo-ch-black.svg +:title-logo-base: black +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Office +:title-logo-line3: +:title-page: +:pdf-theme: basic :toc: :sectnums: :toclevels: 3 @@ -7,6 +17,7 @@ :experimental: :revnumber: 1.0 :revdate: 14.09.2026 +:url-repo: https://github.com/swiss/opensource-guidelines/tree/main Federal agencies are required to disclose the source code of software they develop or have developed to fulfill their duties. They must allow anyone to use, further develop, and distribute the software without charging licensing fees. This requirement is outlined in Article 9 of the Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA). Responsibility for implementation lies with the individual agencies. The Federal Chancellery provides suitable tools to assist federal agencies in meeting this requirement. From 9e5192d94496e5ad83a76ce2e48612f6a839eb8a Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Mon, 14 Sep 2026 16:19:27 +0200 Subject: [PATCH 03/58] Add CI workflow to render docs and publish to GitHub Pages Renders every tracked .adoc file to PDF via open-govpress, downloaded from the same GitHub Release referenced in devenv.nix and verified against the same pinned sha256, under Xvfb (Electron has no headless mode). Runs on every push to main and on pull requests; PDFs are always uploaded as a build artifact, and on push to main they're also published to GitHub Pages with a generated index page. The download is cached across runs by its checksum. Requires a one-time manual step: enable Pages in repo Settings with source set to "GitHub Actions". --- .github/workflows/render-docs.yml | 98 +++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 .github/workflows/render-docs.yml diff --git a/.github/workflows/render-docs.yml b/.github/workflows/render-docs.yml new file mode 100644 index 0000000..7e0650d --- /dev/null +++ b/.github/workflows/render-docs.yml @@ -0,0 +1,98 @@ +name: Render docs + +on: + push: + branches: [main] + pull_request: + +permissions: + contents: read + +concurrency: + group: pages + cancel-in-progress: false + +env: + # Keep in sync with devenv.nix's govpressVersion/govpressUrl/govpressSha256. + # Fetched from a GitHub Release rather than committed to the repo: at + # ~112MiB it clears GitHub's 100MB hard limit on regular git objects, and + # this repo is a fork, which GitHub's LFS policy blocks from uploading + # *new* LFS objects at all -- release assets hit neither limit. + GOVPRESS_VERSION: "0.0.7" + GOVPRESS_URL: https://github.com/736-c41-2c1-e464fc974/opensource-guidelines/releases/download/open-govpress-v0.0.7/open-govpress-0.0.7-linux-x64.tar.gz + GOVPRESS_SHA256: 3766f1da1137208a438abe06b4ad8427734e1de782aac33ff1d47df3e975ecdf + +jobs: + render: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Cache open-govpress download + uses: actions/cache@v4 + with: + path: /tmp/open-govpress.tar.gz + key: open-govpress-${{ env.GOVPRESS_SHA256 }} + + - name: Install Xvfb + run: sudo apt-get update && sudo apt-get install -y xvfb + + - name: Download and extract open-govpress + run: | + if [ ! -f /tmp/open-govpress.tar.gz ]; then + curl -fL --retry 3 -o /tmp/open-govpress.tar.gz "$GOVPRESS_URL" + fi + echo "$GOVPRESS_SHA256 /tmp/open-govpress.tar.gz" | sha256sum -c - + mkdir -p /tmp/open-govpress + tar xzf /tmp/open-govpress.tar.gz -C /tmp/open-govpress + bin=$(find /tmp/open-govpress -maxdepth 2 -name open-govpress -type f) + echo "OGP_BIN=$bin" >> "$GITHUB_ENV" + + - name: Render all documents + run: | + mkdir -p pdfs + mapfile -t docs < <(git ls-files '*.adoc') + xvfb-run -a "$OGP_BIN" render --no-sandbox -o pdfs "${docs[@]}" + + - name: Generate index page + run: | + { + echo '' + echo '' + echo 'opensource-guidelines — rendered PDFs' + echo '

opensource-guidelines — rendered documents

' + echo '

Auto-rendered from the .adoc sources in this repository by GitHub Actions.

' + echo '
    ' + for f in pdfs/*.pdf; do + name=$(basename "$f") + echo "
  • $name
    • " + done + echo '
' + } > pdfs/index.html + + - name: Upload build artifact + uses: actions/upload-artifact@v4 + with: + name: rendered-pdfs + path: pdfs/ + + - name: Upload Pages artifact + if: github.event_name == 'push' && github.ref == 'refs/heads/main' + uses: actions/upload-pages-artifact@v3 + with: + path: pdfs/ + + deploy: + if: github.event_name == 'push' && github.ref == 'refs/heads/main' + needs: render + runs-on: ubuntu-latest + permissions: + pages: write + id-token: write + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 From 1321ff47b167fe43696466f0ffad0e2e01ac4431 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Mon, 14 Sep 2026 16:32:42 +0200 Subject: [PATCH 04/58] Make checklist checkboxes interactive MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Converts all 87 checkbox glyphs (☐) across the four OSS checklist documents into AsciiDoc's [%interactive] checklist syntax. This renders as real, clickable elements in HTML, and open-govpress carries that through to genuine fillable PDF AcroForm widgets (/Widget /Btn annotations with /TU tooltips matching each label) rather than a static glyph. Where a checkbox and its label lived in separate table columns (the original ODT layout), merged them into a single list item so the checkbox has real label text to attach to -- AsciiDoc's checklist syntax doesn't register a bare "* [ ]" with no following text as a checklist item at all. Verified: checkbox counts match the original glyph counts exactly per file (25/14/9/39), all four files render with zero errors, and the actual PDF output via open-govpress contains real AcroForm checkbox widgets, not just visual squares. --- ...-checklist-oss-preliminary-assessment.adoc | 81 +++++------ ...hecklist-oss-analysis-and-preparation.adoc | 75 ++++++---- ...checklist-oss-release-and-publication.adoc | 47 ++++--- .../en/em002-4-1-checklist-oss-community.adoc | 128 ++++++++---------- 4 files changed, 168 insertions(+), 163 deletions(-) diff --git a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc index 5603d69..014bfb8 100644 --- a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc +++ b/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc @@ -71,13 +71,11 @@ a| Is this new software or an existing project (see [Em002-2] Section 3.1). -☐ Legacy (further development) - -☐ New software - -☐ Legacyfootnote:[Not required by EMOTA, but it is also possible to release existing software.] or further development of legacy software - -☐ Existing third-party project ( Complete _Em002-4.1 OSS Community Checklist_) +[%interactive] +* [ ] Legacy (further development) +* [ ] New software +* [ ] Legacyfootnote:[Not required by EMOTA, but it is also possible to release existing software.] or further development of legacy software +* [ ] Existing third-party project ( Complete _Em002-4.1 OSS Community Checklist_) | a| @@ -85,15 +83,12 @@ Life cycle In what stage of the life cycle is the software currently (see [Em002-2] Section 3.1).footnote:[Replacement of existing software should be noted here as 'planned'.] -☐ Planned - -☐ In development - -☐ In operation - -☐ End of life - -☐ Archive +[%interactive] +* [ ] Planned +* [ ] In development +* [ ] In operation +* [ ] End of life +* [ ] Archive | a| @@ -101,11 +96,10 @@ Users Are there potential or known individuals or organisations using the software? Are there potential customers for the software? Possible and known users can be named in the textbox. -☐ None conceivable - -☐ Potential users - -☐ Known users +[%interactive] +* [ ] None conceivable +* [ ] Potential users +* [ ] Known users | a| @@ -115,23 +109,20 @@ What is the basic structure? Is this an in-house development by the Confederatio The structure of co-development and third-party project can be listed in the textbox + (see [Em002-2] Section 3.1). -☐ In-house development - -☐ Joint development (_Em002-4.1 OSS Community Checklist_ to be completed) - -☐ Third-party project (_Em002-4.1 OSS Community Checklist_ to be completed) +[%interactive] +* [ ] In-house development +* [ ] Joint development (_Em002-4.1 OSS Community Checklist_ to be completed) +* [ ] Third-party project (_Em002-4.1 OSS Community Checklist_ to be completed) | a| Who is publishing the software? -☐ Federal authority - -☐ Service provider - -☐ Supplier - -☐ Third party +[%interactive] +* [ ] Federal authority +* [ ] Service provider +* [ ] Supplier +* [ ] Third party | a| @@ -139,27 +130,29 @@ Depth of release Outcome from _Em002-4.1 OSS Community Checklist_. -☐ Minimal publication: Publication of the source code and other artefacts - -☐ Issue tracking: Errors can be reported and will be handled. +[%interactive] +* [ ] Minimal publication: Publication of the source code and other artefacts +* [ ] Issue tracking: Errors can be reported and will be handled. +* [ ] Community -☐ Community - -|☐ +| a| -There is no violation of third-party rights (e.g. patent rights, intellectual property, trademark or design protection). +[%interactive] +* [ ] There is no violation of third-party rights (e.g. patent rights, intellectual property, trademark or design protection). Reviews according to [Em002-2] Section 3.2 have been carried out. The ownership of the software lies with the Confederation, or it is being developed by employees of the Confederation (internal or external). Justification must be given, especially if this is not the case. It must also be explained why the rights do not lie with the Confederation and what checks were made regarding proprietary parts, as well as what was done regarding possible obstacles (e.g. patent protection), or how far investigations went. -|☐ +| a| -There are no security-relevant reasons preventing publication. +[%interactive] +* [ ] There are no security-relevant reasons preventing publication. Reviews according to [Em002-2] Section 3.3 have been carried out. -|☐ +| a| -There is agreement in principle and feasibility exists for publishing the application as open source. +[%interactive] +* [ ] There is agreement in principle and feasibility exists for publishing the application as open source. Reference to minutes or decision-making body with date. diff --git a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc index bb85af8..6df9af5 100644 --- a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc +++ b/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc @@ -51,12 +51,15 @@ a| [cols="1,6"] |=== -|☐ -|_Em002-2.1 OSS Preliminary Assessment Checklist_ has been completed and no problematic points were identified. +| +a| +[%interactive] +* [ ] _Em002-2.1 OSS Preliminary Assessment Checklist_ has been completed and no problematic points were identified. -|☐ +| a| -The source code to be published has been analysed. +[%interactive] +* [ ] The source code to be published has been analysed. * Review how the existing code quality and guidelines have been implemented. * Ensure no sensitive (test) data is included, e.g. data based on real people or cases. @@ -67,9 +70,10 @@ The source code to be published has been analysed. * Review all libraries used to ensure licences are present and corresponding lists (attributions) have been created. * Description of the deployment (CI/CD pipelinefootnote:[https://en.wikipedia.org/wiki/CI/CD]) and possibly setup of a demo instance. -|☐ +| a| -Licence selection +[%interactive] +* [ ] Licence selection * Check for any dependencies on existing licences. * For third-party code, check terms of use for compatibility with intended licence and replace code if necessary. @@ -77,56 +81,71 @@ Licence selection Selected licence and justification -|☐ +| a| -The documentation is stored with the source code (see [Em002-2] Annex D.1.) +[%interactive] +* [ ] The documentation is stored with the source code (see [Em002-2] Annex D.1.) Justification/storage location -|☐ +| a| -The documentation addresses both end users and technical professionals. +[%interactive] +* [ ] The documentation addresses both end users and technical professionals. List of the central documentation -|☐ +| a| -Detailed documentation of the source code (OSS specific) +[%interactive] +* [ ] Detailed documentation of the source code (OSS specific) Important standard documentation (README, LICENSE, CONTRIBUTING, etc.) is available. -|☐ +| a| -The source code, including history, contains no sensitive, protected or confidential personal data. Or the history has been completely deleted. (see [Em002-2] Annex E.2.) +[%interactive] +* [ ] The source code, including history, contains no sensitive, protected or confidential personal data. Or the history has been completely deleted. (see [Em002-2] Annex E.2.) Explanation of review (if not filed as separate document) -|☐ +| a| -It has been clarified with the supplier and all involved developers within the Federal Administration whether author information (names, email addresses) may be published. + +[%interactive] +* [ ] It has been clarified with the supplier and all involved developers within the Federal Administration whether author information (names, email addresses) may be published. + Alternatively, the source code including history has been cleaned/anonymised. -|☐ +| a| -The libraries used by the project are compatible with the project's licence. +[%interactive] +* [ ] The libraries used by the project are compatible with the project's licence. Explanation of review (if not filed as separate document) -|☐ -|The project uses a package manager to manage its dependencies. +| +a| +[%interactive] +* [ ] The project uses a package manager to manage its dependencies. -|☐ -|The project declares its licence in the corresponding descriptor of the package manager. Creation of a Software Bill of Materials (SBOM), which lists all open source components used. +| +a| +[%interactive] +* [ ] The project declares its licence in the corresponding descriptor of the package manager. Creation of a Software Bill of Materials (SBOM), which lists all open source components used. -|☐ +| a| -The source code contains a _THIRD-PARTY-LICENSES.md_ file listing for each library used: the project name of the library, the homepage of the library, the SPDX identifier of the library's licence, and a link to the library's licence. +[%interactive] +* [ ] The source code contains a _THIRD-PARTY-LICENSES.md_ file listing for each library used: the project name of the library, the homepage of the library, the SPDX identifier of the library's licence, and a link to the library's licence. -|☐ -|For applications, an 'About' dialogue is available that references the _THIRD-PARTY-LICENSES.md_ file. +| +a| +[%interactive] +* [ ] For applications, an 'About' dialogue is available that references the _THIRD-PARTY-LICENSES.md_ file. -|☐ -|As part of the code review process, it is ensured that the _THIRD-PARTY-LICENSES.md_ file is updated with every change to the libraries. +| +a| +[%interactive] +* [ ] As part of the code review process, it is ensured that the _THIRD-PARTY-LICENSES.md_ file is updated with every change to the libraries. |=== diff --git a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc index fa6b88b..9b2d2b6 100644 --- a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc +++ b/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc @@ -69,25 +69,31 @@ The checklist is to be completed before actual publication. [cols="1,6,1"] |=== -|☐ -|'Em002-2.1 OSS Preliminary Assessment Checklist' has been completed and no problematic points were identified. +| +a| +[%interactive] +* [ ] 'Em002-2.1 OSS Preliminary Assessment Checklist' has been completed and no problematic points were identified. | -|☐ -|'Em002-2.2 OSS Analysis and Preparation Checklist' has been completed and no problematic points were identified. +| +a| +[%interactive] +* [ ] 'Em002-2.2 OSS Analysis and Preparation Checklist' has been completed and no problematic points were identified. | -|☐ +| a| -Licence has been selected. +[%interactive] +* [ ] Licence has been selected. Selected licence and justification | -|☐ +| a| -ISDS concept has been created. +[%interactive] +* [ ] ISDS concept has been created. The relevant reviews have been carried out. Refer to documents/reviews. It is defined how security-relevant reports by third parties will be handled. + If applicable, the software will be subject to a bug bounty programme. + @@ -96,25 +102,28 @@ The relevant configuration is described and the person responsible is named. | -|☐ +| a| -Community and support is regulated (via 'Em002-4.1 OSS Community Checklist') +[%interactive] +* [ ] Community and support is regulated (via 'Em002-4.1 OSS Community Checklist') The checklist is attached. The key points are included here. | -|☐ +| a| -Level and method of support have been clarified. +[%interactive] +* [ ] Level and method of support have been clarified. Indication of how this has been regulated. | -|☐ +| a| -A *publiccode.yml* was created for the publication. +[%interactive] +* [ ] A *publiccode.yml* was created for the publication. The metadata standard https://yml.publiccode.tools/ describes the software. The defined format makes the publication easier to find and reuse. + This must be saved in the main directory of the repository. + @@ -122,17 +131,19 @@ If a new repository or organisation is created, this can be reported via opensou | -|☐ +| a| -Transferred responsibilities +[%interactive] +* [ ] Transferred responsibilities Indication of whether responsibility for release was transferred to a third party (supplier, support, association) during procurement or subsequently. | -|☐ +| a| -Green light for open sourcing from the application and budget managers +[%interactive] +* [ ] Green light for open sourcing from the application and budget managers Names and date diff --git a/docs/en/em002-4-1-checklist-oss-community.adoc b/docs/en/em002-4-1-checklist-oss-community.adoc index 805e046..51cb9e8 100644 --- a/docs/en/em002-4-1-checklist-oss-community.adoc +++ b/docs/en/em002-4-1-checklist-oss-community.adoc @@ -55,13 +55,11 @@ Type of community The community may already exist, which greatly simplifies the task. -☐ Exists (third party may have the lead) - -☐ The Confederation has the lead - -☐ Equal partners (Confederation and partners/suppliers) - -☐ Other +[%interactive] +* [ ] Exists (third party may have the lead) +* [ ] The Confederation has the lead +* [ ] Equal partners (Confederation and partners/suppliers) +* [ ] Other | a| @@ -69,13 +67,11 @@ Library or entire software? There is usually no community concept for libraries. An add-on can only be used together with a commercial product. -☐ Entire software - -☐ Library - -☐ Add-on - -☐ Other +[%interactive] +* [ ] Entire software +* [ ] Library +* [ ] Add-on +* [ ] Other | a| @@ -83,12 +79,11 @@ What type of community is planned? The choice of community type should be justified in two to three sentences. -☐ None, only publication (as-is) (minimum release) + +[%interactive] +* [ ] None, only publication (as-is) (minimum release) + Note: email must be available, publicode.yaml must be filled in - -☐ Releases/issue tracker (minimum support, allow third-party support if necessary) - -☐ Community +* [ ] Releases/issue tracker (minimum support, allow third-party support if necessary) +* [ ] Community | a| @@ -96,15 +91,15 @@ Are there potential or actual co-users of the software? Are there potential customers for the software? Possible and known users can be listed in the text box (see _Em002-2 Instructions for Publishing Open Source Software,_ Section 3.1.1). -☐ None conceivable +[%interactive] +* [ ] None conceivable +* [ ] Potential users (are conceivable) +* [ ] Known users (have already contacted us) -☐ Potential users (are conceivable) - -☐ Known users (have already contacted us) - -|☐ +| a| -Stakeholders (already defined/known members of the community) +[%interactive] +* [ ] Stakeholders (already defined/known members of the community) List of relevant jobs/companies. + This gives an idea of how relevant the software is for third parties. @@ -115,15 +110,12 @@ Who takes charge of product management? Product management is primarily responsible for further development of the product. Especially if this role is assumed by third parties, the companies/organisations should be named if possible. -☐ Federal office - -☐ Service provider - -☐ Supplier(s) / third parties - -☐ Joint organisation - -☐ Open +[%interactive] +* [ ] Federal office +* [ ] Service provider +* [ ] Supplier(s) / third parties +* [ ] Joint organisation +* [ ] Open | a| @@ -131,13 +123,11 @@ Integration of suppliers How are the suppliers involved? -☐ Contractor - -☐ Partner - -☐ Responsible body - -☐ Other +[%interactive] +* [ ] Contractor +* [ ] Partner +* [ ] Responsible body +* [ ] Other | | @@ -148,13 +138,11 @@ Type of organisation What organisational form does the community take? This should be explained in detail, especially if 'Other' is selected. On account of the effort this entails, a new association should only be set up if there is a very good reason for doing so. -☐ Public sector only - -☐ Simple partnership - -☐ New or existing association - -☐ Other (e.g. a foundation, existing or not) +[%interactive] +* [ ] Public sector only +* [ ] Simple partnership +* [ ] New or existing association +* [ ] Other (e.g. a foundation, existing or not) | a| @@ -164,40 +152,34 @@ This should be set out in the community concept. Section 5.5 of _Em002-4 OSS Com What means and resources are required? The cost distribution considerations should be briefly stated. -☐ The Confederation pays - -☐ Each party covers its own costs - -☐ Originator pays principle - -☐ The Confederation does not assume any costs from the community +[%interactive] +* [ ] The Confederation pays +* [ ] Each party covers its own costs +* [ ] Originator pays principle +* [ ] The Confederation does not assume any costs from the community +* [ ] Cost sharing (e.g. by way of an association) +* [ ] Release, partially assumed by third parties (e.g. because software was created before 1 January 2024 and they absolutely want to use the software) -☐ Cost sharing (e.g. by way of an association) - -☐ Release, partially assumed by third parties (e.g. because software was created before 1 January 2024 and they absolutely want to use the software) - -|☐ +| a| -If additional services are offered in accordance with Art. 9 paras 5 and 6 EMOTA, is this set out in the community concept? + +[%interactive] +* [ ] If additional services are offered in accordance with Art. 9 paras 5 and 6 EMOTA, is this set out in the community concept? + The community concept contains the relevant information. -|☐ +| a| -Has the community concept been created? +[%interactive] +* [ ] Has the community concept been created? The community concept has been created or an existing one is being adopted? + (please insert link) +| a| -☐ + -☐ + -☐ -a| -Are the necessary contracts in place? - -Contributor Licence Agreement (CLA)footnote:[See also _Em002-3 OSS Licensing Guidelines_. Alternatively, Developer Certificates of Origin (DCO) can also be used.] created or adopted - -Association founded, if necessary. +[%interactive] +* [ ] Are the necessary contracts in place? +* [ ] Contributor Licence Agreement (CLA)footnote:[See also _Em002-3 OSS Licensing Guidelines_. Alternatively, Developer Certificates of Origin (DCO) can also be used.] created or adopted +* [ ] Association founded, if necessary. | | From af405bbc38343417bb24d7c14f71e27b87a31e61 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Mon, 14 Sep 2026 16:40:39 +0200 Subject: [PATCH 05/58] Fix footnotes embedded in heading text and a stray escape MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per the AsciiDoc documentation, footnotes are not officially supported in heading text and can produce incorrect/duplicate numbering. This was confirmed in practice: three headings had a footnote macro appended directly to the title (em002-4.adoc x2, em002-6.adoc x1), which caused Asciidoctor to emit duplicate `id="_footnoteref_N"` attributes (footnote 1 and 2 in em002-4.adoc were assigned twice) and leaked a stray "[N]" into the auto-generated table-of-contents entry for those sections. Relocated each footnote to the first natural mention of the same term in the following body text, which resolves to a clean, unique, sequential footnote numbering with no ID collisions and no TOC leakage. Also fixed a stray literal backslash before an en-dash in em002.adoc (`\–`) that was rendering verbatim instead of being silently dropped, since backslash-escaping only has meaning before AsciiDoc markup characters (confirmed correct usage of the two neighboring `\|` escapes, which legitimately escape a literal pipe inside a table cell -- left those as-is). --- docs/en/em002-4.adoc | 8 ++++---- docs/en/em002-6.adoc | 4 ++-- docs/en/em002.adoc | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/en/em002-4.adoc b/docs/en/em002-4.adoc index 3dc5d77..868ec7a 100644 --- a/docs/en/em002-4.adoc +++ b/docs/en/em002-4.adoc @@ -878,9 +878,9 @@ NB: The commune register GERES is not open source, but many aspects of the organ The following examples illustrate how collaborations have been structured. -=== Collaboration: ZenDiSfootnote:[https://www.zendis.de/en[ZenDiS home page: Co-creating Digital Sovereignty]] in Germany +=== Collaboration: ZenDiS in Germany -ZenDiS is an organisation whose aim is to reduce dependency in public administration (primarily in Germany) by promoting open source software. +ZenDiSfootnote:[https://www.zendis.de/en[ZenDiS home page: Co-creating Digital Sovereignty]] is an organisation whose aim is to reduce dependency in public administration (primarily in Germany) by promoting open source software. image::assets/em002-4/media/image2.png[Goals and approaches to strengthening digital sovereignty (ZenDiS)] @@ -898,9 +898,9 @@ NB: ZenDiS is subject to EU/German procurement law. There are significant differ Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] is an open source travel planning application. It is organised as a project of the Software Freedom Conservancy in New York. Individual developers are employed by transport companies and suppliers. A notable feature is that a public sector actor -- specifically ENTURfootnote:[https://entur.no/] -- has taken on one of the leading roles. ENTUR develops primarily for its own needs but also has a collaborative focus, particularly for the Nordic countries. ENTUR is organised as a company owned by the Norwegian Ministry of Transport and Communications. As the largest actor, ENTUR also absorbs a significant share of the coordination costs. Anyone can submit feature requests; these are discussed in coordination meetings and developed if someone funds them. Funding is provided primarily on a per-feature basis by the interested party or parties. In essence, each party bears its own costs. Support services would also need to be put out to tender separately in Switzerland. -=== New collaboration initiated by the Confederation: Swiss Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] +=== New collaboration initiated by the Confederation: Swiss Trust Broker -The Trust Broker is a piece of Confederation software for eIAM, available as open source. Development is carried out by the Confederation. Several cantons have decided to deploy it either directly as SaaS or with their own instances. As it is available under the AGPL licence, any extensions made will benefit the Confederation in turn. Given its security-critical nature, development for the Federal Administration is carried out exclusively by the Confederation. Other organisations may submit requirements, which will be implemented if the project team considers them appropriate. +The Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] is a piece of Confederation software for eIAM, available as open source. Development is carried out by the Confederation. Several cantons have decided to deploy it either directly as SaaS or with their own instances. As it is available under the AGPL licence, any extensions made will benefit the Confederation in turn. Given its security-critical nature, development for the Federal Administration is carried out exclusively by the Confederation. Other organisations may submit requirements, which will be implemented if the project team considers them appropriate. === New collaboration initiated by the cantons: inosca diff --git a/docs/en/em002-6.adoc b/docs/en/em002-6.adoc index 9175538..31adb34 100644 --- a/docs/en/em002-6.adoc +++ b/docs/en/em002-6.adoc @@ -103,14 +103,14 @@ Furthermore, the operators of AI systems may reserve the right in their terms an It is recommended to examine and approve the use of AI tools individually. Unapproved tools may not be used, but employees can apply for approval of a tool. Often it makes sense to resolve such issues by contract with the supplier, or some suppliers may offer special subscriptions by which they respect third-party rights, e.g. DeepL. |=== -=== Legal basis in EMOTAfootnote:[SR 172.019] +=== Legal basis in EMOTA [cols="1,9",options="header"] |=== |Q |*What is the legal basis for the publication of OSS?* a|A -a|According to Art. 9 EMOTA, federal authorities of the central Federal Administration must disclose the source code of software they develop or commission. Any person is allowed to use, further develop or modify the software without being charged fees of any kind. +a|According to Art. 9 EMOTAfootnote:[SR 172.019], federal authorities of the central Federal Administration must disclose the source code of software they develop or commission. Any person is allowed to use, further develop or modify the software without being charged fees of any kind. Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. diff --git a/docs/en/em002.adoc b/docs/en/em002.adoc index 4eed241..ff9c428 100644 --- a/docs/en/em002.adoc +++ b/docs/en/em002.adoc @@ -355,7 +355,7 @@ Intranet: link:https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/stan |[BöB] |Federal Act on Public Procurement (PPA) link:https://www.fedlex.admin.ch/eli/oc/2020/126/de[https://www.fedlex.admin.ch/eli/oc/2020/126/de] -|[DigiV] |Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) link:https://www.fedlex.admin.ch/eli/cc/2025/235/de[SR 172.019.1 \– Ordinance of 2 April 2025 \| Fedlex] +|[DigiV] |Ordinance on Digital Services and the Digital Transformation in the Federal Administration, DigiO) link:https://www.fedlex.admin.ch/eli/cc/2025/235/de[SR 172.019.1 – Ordinance of 2 April 2025 \| Fedlex] |[EY2011] |Open Source Software im geschäftskritischen Einsatz. Ernst & Young. 2011. link:https://www.yumpu.com/de/document/read/23276493/open-source-software-ernst-young[https://www.yumpu.com/de/document/read/23276493/open-source-software-ernst-young]. From 2a6ddf0ce44c864cb7b0f6faa60a9a71a3a52d87 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Tue, 15 Sep 2026 13:16:08 +0200 Subject: [PATCH 06/58] Flatten docs/en/ to docs/ ahead of localisation Every document is about to carry all five languages in one file, so a per-language directory has nothing left to name. Assets move with the documents, which keeps every `image::./assets/...` macro valid without touching a single one. Intra-repo `link:` targets switch from .adoc to .pdf: these links are read inside the rendered PDFs, sitting next to their siblings in the published per-language directory, where an .adoc target resolves to nothing. README.adoc keeps its .adoc target, being read on GitHub. publiccode.yml gains rm-CH, and its screenshot follows the new layout on main rather than a path pinned to a commit that predates the move. Co-Authored-By: Claude Opus 5 (1M context) --- .gitignore | 4 + README.adoc | 2 +- docs/{en => }/assets/em002-1/media/image1.png | Bin docs/{en => }/assets/em002-1/media/image2.png | Bin .../assets/em002-2/md/README_template.adoc | 0 docs/{en => }/assets/em002-2/media/image1.png | Bin docs/{en => }/assets/em002-2/media/image2.png | Bin docs/{en => }/assets/em002-2/media/image3.png | Bin docs/{en => }/assets/em002-2/media/image4.png | Bin docs/{en => }/assets/em002-3/media/image1.png | Bin docs/{en => }/assets/em002-3/media/image2.png | Bin docs/{en => }/assets/em002-3/media/image3.png | Bin docs/{en => }/assets/em002-3/media/image4.png | Bin docs/{en => }/assets/em002-4/media/image1.png | Bin docs/{en => }/assets/em002-4/media/image2.png | Bin docs/{en => }/assets/em002-5/media/image1.png | Bin docs/{en => }/assets/em002-5/media/image2.png | Bin docs/{en => }/assets/em002-7/media/image1.png | Bin docs/{en => }/assets/em002-7/media/image2.png | Bin docs/{en => }/assets/em002-7/media/image3.png | Bin docs/{en => }/assets/em002-7/media/image4.png | Bin docs/{en => }/assets/em002-7/media/image5.png | Bin docs/{en => }/assets/em002/media/image1.png | Bin docs/{en => }/assets/em002/media/image2.png | Bin docs/{en => }/em002-1.adoc | 90 +++++++++--------- ...-checklist-oss-preliminary-assessment.adoc | 0 ...hecklist-oss-analysis-and-preparation.adoc | 0 ...checklist-oss-release-and-publication.adoc | 0 docs/{en => }/em002-2.adoc | 44 ++++----- docs/{en => }/em002-3.adoc | 24 ++--- .../em002-4-1-checklist-oss-community.adoc | 0 docs/{en => }/em002-4.adoc | 24 ++--- docs/{en => }/em002-5.adoc | 14 +-- docs/{en => }/em002-6.adoc | 70 +++++++------- docs/{en => }/em002-7.adoc | 24 ++--- docs/{en => }/em002.adoc | 40 ++++---- docs/{index_en.adoc => index.adoc} | 24 ++--- publiccode.yml | 3 +- 38 files changed, 184 insertions(+), 179 deletions(-) rename docs/{en => }/assets/em002-1/media/image1.png (100%) rename docs/{en => }/assets/em002-1/media/image2.png (100%) rename docs/{en => }/assets/em002-2/md/README_template.adoc (100%) rename docs/{en => }/assets/em002-2/media/image1.png (100%) rename docs/{en => }/assets/em002-2/media/image2.png (100%) rename docs/{en => }/assets/em002-2/media/image3.png (100%) rename docs/{en => }/assets/em002-2/media/image4.png (100%) rename docs/{en => }/assets/em002-3/media/image1.png (100%) rename docs/{en => }/assets/em002-3/media/image2.png (100%) rename docs/{en => }/assets/em002-3/media/image3.png (100%) rename docs/{en => }/assets/em002-3/media/image4.png (100%) rename docs/{en => }/assets/em002-4/media/image1.png (100%) rename docs/{en => }/assets/em002-4/media/image2.png (100%) rename docs/{en => }/assets/em002-5/media/image1.png (100%) rename docs/{en => }/assets/em002-5/media/image2.png (100%) rename docs/{en => }/assets/em002-7/media/image1.png (100%) rename docs/{en => }/assets/em002-7/media/image2.png (100%) rename docs/{en => }/assets/em002-7/media/image3.png (100%) rename docs/{en => }/assets/em002-7/media/image4.png (100%) rename docs/{en => }/assets/em002-7/media/image5.png (100%) rename docs/{en => }/assets/em002/media/image1.png (100%) rename docs/{en => }/assets/em002/media/image2.png (100%) rename docs/{en => }/em002-1.adoc (88%) rename docs/{en => }/em002-2-1-checklist-oss-preliminary-assessment.adoc (100%) rename docs/{en => }/em002-2-2-checklist-oss-analysis-and-preparation.adoc (100%) rename docs/{en => }/em002-2-3-checklist-oss-release-and-publication.adoc (100%) rename docs/{en => }/em002-2.adoc (94%) rename docs/{en => }/em002-3.adoc (96%) rename docs/{en => }/em002-4-1-checklist-oss-community.adoc (100%) rename docs/{en => }/em002-4.adoc (97%) rename docs/{en => }/em002-5.adoc (89%) rename docs/{en => }/em002-6.adoc (90%) rename docs/{en => }/em002-7.adoc (96%) rename docs/{en => }/em002.adoc (94%) rename docs/{index_en.adoc => index.adoc} (67%) diff --git a/.gitignore b/.gitignore index 01dbd08..c9b73ba 100644 --- a/.gitignore +++ b/.gitignore @@ -9,3 +9,7 @@ # rendered output (build artifacts, not source) *.pdf + +# the per-language site built by `render-docs` locally and by CI +/build/ +/site/ diff --git a/README.adoc b/README.adoc index 1592cb0..781fb36 100644 --- a/README.adoc +++ b/README.adoc @@ -21,7 +21,7 @@ This repository contains *evolving drafts* of guidelines and tools to support the Federal Administration in publishing open source code. The *official and binding versions* are available in all official languages on the https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Swiss Federal Chancellery website]. -For a complete list of documents, see: link:docs/index_en.adoc[Tools for Publishing Open Source Software] +For a complete list of documents, see: link:docs/index.adoc[Tools for Publishing Open Source Software] == Legal obligations and responsibility diff --git a/docs/en/assets/em002-1/media/image1.png b/docs/assets/em002-1/media/image1.png similarity index 100% rename from docs/en/assets/em002-1/media/image1.png rename to docs/assets/em002-1/media/image1.png diff --git a/docs/en/assets/em002-1/media/image2.png b/docs/assets/em002-1/media/image2.png similarity index 100% rename from docs/en/assets/em002-1/media/image2.png rename to docs/assets/em002-1/media/image2.png diff --git a/docs/en/assets/em002-2/md/README_template.adoc b/docs/assets/em002-2/md/README_template.adoc similarity index 100% rename from docs/en/assets/em002-2/md/README_template.adoc rename to docs/assets/em002-2/md/README_template.adoc diff --git a/docs/en/assets/em002-2/media/image1.png b/docs/assets/em002-2/media/image1.png similarity index 100% rename from docs/en/assets/em002-2/media/image1.png rename to docs/assets/em002-2/media/image1.png diff --git a/docs/en/assets/em002-2/media/image2.png b/docs/assets/em002-2/media/image2.png similarity index 100% rename from docs/en/assets/em002-2/media/image2.png rename to docs/assets/em002-2/media/image2.png diff --git a/docs/en/assets/em002-2/media/image3.png b/docs/assets/em002-2/media/image3.png similarity index 100% rename from docs/en/assets/em002-2/media/image3.png rename to docs/assets/em002-2/media/image3.png diff --git a/docs/en/assets/em002-2/media/image4.png b/docs/assets/em002-2/media/image4.png similarity index 100% rename from docs/en/assets/em002-2/media/image4.png rename to docs/assets/em002-2/media/image4.png diff --git a/docs/en/assets/em002-3/media/image1.png b/docs/assets/em002-3/media/image1.png similarity index 100% rename from docs/en/assets/em002-3/media/image1.png rename to docs/assets/em002-3/media/image1.png diff --git a/docs/en/assets/em002-3/media/image2.png b/docs/assets/em002-3/media/image2.png similarity index 100% rename from docs/en/assets/em002-3/media/image2.png rename to docs/assets/em002-3/media/image2.png diff --git a/docs/en/assets/em002-3/media/image3.png b/docs/assets/em002-3/media/image3.png similarity index 100% rename from docs/en/assets/em002-3/media/image3.png rename to docs/assets/em002-3/media/image3.png diff --git a/docs/en/assets/em002-3/media/image4.png b/docs/assets/em002-3/media/image4.png similarity index 100% rename from docs/en/assets/em002-3/media/image4.png rename to docs/assets/em002-3/media/image4.png diff --git a/docs/en/assets/em002-4/media/image1.png b/docs/assets/em002-4/media/image1.png similarity index 100% rename from docs/en/assets/em002-4/media/image1.png rename to docs/assets/em002-4/media/image1.png diff --git a/docs/en/assets/em002-4/media/image2.png b/docs/assets/em002-4/media/image2.png similarity index 100% rename from docs/en/assets/em002-4/media/image2.png rename to docs/assets/em002-4/media/image2.png diff --git a/docs/en/assets/em002-5/media/image1.png b/docs/assets/em002-5/media/image1.png similarity index 100% rename from docs/en/assets/em002-5/media/image1.png rename to docs/assets/em002-5/media/image1.png diff --git a/docs/en/assets/em002-5/media/image2.png b/docs/assets/em002-5/media/image2.png similarity index 100% rename from docs/en/assets/em002-5/media/image2.png rename to docs/assets/em002-5/media/image2.png diff --git a/docs/en/assets/em002-7/media/image1.png b/docs/assets/em002-7/media/image1.png similarity index 100% rename from docs/en/assets/em002-7/media/image1.png rename to docs/assets/em002-7/media/image1.png diff --git a/docs/en/assets/em002-7/media/image2.png b/docs/assets/em002-7/media/image2.png similarity index 100% rename from docs/en/assets/em002-7/media/image2.png rename to docs/assets/em002-7/media/image2.png diff --git a/docs/en/assets/em002-7/media/image3.png b/docs/assets/em002-7/media/image3.png similarity index 100% rename from docs/en/assets/em002-7/media/image3.png rename to docs/assets/em002-7/media/image3.png diff --git a/docs/en/assets/em002-7/media/image4.png b/docs/assets/em002-7/media/image4.png similarity index 100% rename from docs/en/assets/em002-7/media/image4.png rename to docs/assets/em002-7/media/image4.png diff --git a/docs/en/assets/em002-7/media/image5.png b/docs/assets/em002-7/media/image5.png similarity index 100% rename from docs/en/assets/em002-7/media/image5.png rename to docs/assets/em002-7/media/image5.png diff --git a/docs/en/assets/em002/media/image1.png b/docs/assets/em002/media/image1.png similarity index 100% rename from docs/en/assets/em002/media/image1.png rename to docs/assets/em002/media/image1.png diff --git a/docs/en/assets/em002/media/image2.png b/docs/assets/em002/media/image2.png similarity index 100% rename from docs/en/assets/em002/media/image2.png rename to docs/assets/em002/media/image2.png diff --git a/docs/en/em002-1.adoc b/docs/em002-1.adoc similarity index 88% rename from docs/en/em002-1.adoc rename to docs/em002-1.adoc index 541b8ca..70e9ab5 100644 --- a/docs/en/em002-1.adoc +++ b/docs/em002-1.adoc @@ -36,20 +36,20 @@ General introduction to open source software * Section Definitions * Section Potential and challenges * Section Findability of OSS solutions -* link:em002-5.adoc[Em002-5 OSS Tools information sheet] -* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] -* link:em002-6.adoc[Em002-6 FAQ about OSS] +* link:em002-5.pdf[Em002-5 OSS Tools information sheet] +* link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] +* link:em002-6.pdf[Em002-6 FAQ about OSS] General introduction to EMOTA for decision-makers -* link:em002-5.adoc[Em002-5 OSS Tools information sheet] -* link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] +* link:em002-5.pdf[Em002-5 OSS Tools information sheet] +* link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] Procurement only of software to be used * Section Maturity levels for OSS in the Federal Administration * Section Use of unmodified open source software -* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] +* link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and OSS] * Software Procurement and Art. 9 EMOTA information sheet [KBB-MB] * OSS in Procurement guidelines [BBL-WL] @@ -57,45 +57,45 @@ New IT development and release * Section Development with open source components and release of source code * Section Collaboration in open projects (contribution) -* link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] -* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] -* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] -* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] -* link:em002-4.adoc[Em002-4 OSS Community Guidelines] -* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] +* link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4.pdf[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] Procurement of created software (service or work) * Section Maturity levels for OSS in the Federal Administration * Section Development with open source components and release of source code * Section Collaboration in open projects (contribution) -* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] +* link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and OSS] * FOBL toolbox, including the Open Source in Procurement guidelines * CCPP public administration learning and template platform (www.perimap.admin.ch) including Software Procurement and Art. 9 EMOTA [KBB-MB] * OSS in Procurement guidelines [BBL-WL] -* link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] -* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] -* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] -* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] -* link:em002-4.adoc[Em002-4 OSS Community Guidelines] -* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] +* link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4.pdf[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] Legal clarifications for release -* link:em002-6.adoc[Em002-6 Frequently Asked Questions about Publishing OSS (OSS-FAQ)] -* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] +* link:em002-6.pdf[Em002-6 Frequently Asked Questions about Publishing OSS (OSS-FAQ)] +* link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] Working principles for project managers * https://www.hermes.admin.ch/[HERMES documents] -* link:em002-5.adoc[Em002-5 OSS Tools information sheet] +* link:em002-5.pdf[Em002-5 OSS Tools information sheet] Contributions of software to third parties and collaborations -* link:em002-4.adoc[Em002-4 OSS Community Guidelines] -* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] -* link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] -* link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] +* link:em002-4.pdf[Em002-4 OSS Community Guidelines] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] +* link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and OSS] +* link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] The following diagram gives an overview of the documents relevant to OSS in the Federal Administration. @@ -125,13 +125,13 @@ Figure 1: Overview of OSS tools in relation to Art. 9 EMOTA |A licence is a document that contains binding guidelines for the use and distribution of software. In the case of open source, licences that comply with OSI are usually used. footnote:[See: https://opensource.org/] |Community -|A community in the context of open source software is broadly defined. It can be a loose ecosystem or a structure with governance that develops the software. The document link:em002-4.adoc[Em002-4 OSS Community Guidelines] covers this topic. Community members can jointly manage the product, develop, test, translate, provide feedback or simply use the software. +|A community in the context of open source software is broadly defined. It can be a loose ecosystem or a structure with governance that develops the software. The document link:em002-4.pdf[Em002-4 OSS Community Guidelines] covers this topic. Community members can jointly manage the product, develop, test, translate, provide feedback or simply use the software. |Third-party rights |Even with open source software, protective rights may exist (copyright, trademark law, patent law) and can be asserted by third parties, e.g. when using source code created by third parties. |Exceptions under EMOTA -|Exceptions according to Art. 9 para. 1 EMOTA include third-party rights and security-related reasons. Both are covered in Section 3 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|Exceptions according to Art. 9 para. 1 EMOTA include third-party rights and security-related reasons. Both are covered in Section 3 of link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |Source code |In computing, source code (or source text) is the human-readable text of a computer program written in a programming language. footnote:[See: https://en.wikipedia.org/wiki/Source_code] @@ -161,7 +161,7 @@ Figure 1: Overview of OSS tools in relation to Art. 9 EMOTA |Software Package Data Exchange (SPDX) footnote:[See: https://en.wikipedia.org/wiki/Software_Package_Data_Exchange] describes a standard format for Software Bill of Materials (SBOM) with the aim of facilitating the correct handling of free software or open source software. |Copyleft effect -|If software is under a licence with a copyleft provision, any modification or extension of the source code must be released again under the licence of the modified open source software (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). +|If software is under a licence with a copyleft provision, any modification or extension of the source code must be released again under the licence of the modified open source software (see also link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]). |=== == Potential and challenges @@ -245,7 +245,7 @@ The following describes the typical challenges encountered in practice with open |It is often difficult for outsiders of an open source community to recognise how the project will develop in the future. Therefore, it is important to be able to make a realistic assessment of the future development of an open source solution. In this regard, Section Fehler: Verweis nicht gefunden introduces the Open Hub platform, which allows an assessment of the activity and heterogeneity of the developer community. This makes it possible to better assess the future development of an open source project. |10. Legal uncertainties -|The multitudes of different open source licences and small number of court rulings on interpretation issues to date can sometimes lead to legal uncertainties with open source software. These practical guidelines are intended to provide an overview of the most important open source licences and their characteristics and compatibilities. Sources for in-depth answers to legal questions can be found in the documents link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and in link:em002-6.adoc[Em002-6 FAQ on OSS and Art. 9 EMOTA]. +|The multitudes of different open source licences and small number of court rulings on interpretation issues to date can sometimes lead to legal uncertainties with open source software. These practical guidelines are intended to provide an overview of the most important open source licences and their characteristics and compatibilities. Sources for in-depth answers to legal questions can be found in the documents link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and in link:em002-6.pdf[Em002-6 FAQ on OSS and Art. 9 EMOTA]. |11. Too extensive offering of open source software |The number of open source software products has increased dramatically in recent years. Potential users of open source software therefore complain about the multitude of existing open source solutions on the market. For this reason, the section 'Findability of...' introduces two platforms, alternativeTo and Open Hub, which enable a comparison of Open Source solutions. @@ -274,25 +274,25 @@ When using and developing OSS in the Federal Administration, there are various c |There is *no obligation* to share the source code. |The *completely new development* of software that is be published under an open source licence. -|*In this case, there is complete freedom regarding the licence under which the software is published.* The document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] should be used for the Confederation. The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. +|*In this case, there is complete freedom regarding the licence under which the software is published.* The document link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] should be used for the Confederation. The document link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must be observed. -|*Further development* (internal or external) with existing open source components (with or without copyleft effect footnote:[Explanation of the term 'copyleft' in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]]), as long as the software is used *exclusively within the same organisation* and not redistributed. -|The OSS components can be combined with third-party components as required. There is generally no publication obligation from the licence, as long as the software is used exclusively within the same organisation and not distributed (exception: AGPL). Since it is not legally conclusive how far the concept of 'distribution within the same organisation' extends, this scenario only applies in exceptional cases for OSS components with copyleft effects. In these cases, consult your organisation's legal department. See link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-6.adoc[Em002-6 FAQ about OSS and Art.9 EMOTA]. The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. *As there is a publication obligation under Art. 9 EMOTA, the changes must be re-released. The easiest way is as changes to the existing open source project.* +|*Further development* (internal or external) with existing open source components (with or without copyleft effect footnote:[Explanation of the term 'copyleft' in link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]]), as long as the software is used *exclusively within the same organisation* and not redistributed. +|The OSS components can be combined with third-party components as required. There is generally no publication obligation from the licence, as long as the software is used exclusively within the same organisation and not distributed (exception: AGPL). Since it is not legally conclusive how far the concept of 'distribution within the same organisation' extends, this scenario only applies in exceptional cases for OSS components with copyleft effects. In these cases, consult your organisation's legal department. See link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and link:em002-6.pdf[Em002-6 FAQ about OSS and Art.9 EMOTA]. The document link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must be observed. *As there is a publication obligation under Art. 9 EMOTA, the changes must be re-released. The easiest way is as changes to the existing open source project.* |*Further development* (internal or external) *exclusively with* existing open source *components without copyleft effect*, if the software is to be distributed externally (e.g. to cantons). -|The OSS components can be combined with third-party components at will, and there is no publication obligation from the licences (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). *However, release is mandatory within the framework of Art. 9 EMOTA. Ideally, the release should made be via the existing project (no fork).* The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. +|The OSS components can be combined with third-party components at will, and there is no publication obligation from the licences (see also link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]). *However, release is mandatory within the framework of Art. 9 EMOTA. Ideally, the release should made be via the existing project (no fork).* The document link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must be observed. |*Further development* (internally or externally) with existing open source components *with copyleft effect*, if the software is to be distributed externally (e.g. to cantons). -|*There is an obligation to publish* due to the copyleft licence (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] regarding the copyleft effect). The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. +|*There is an obligation to publish* due to the copyleft licence (see also link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] regarding the copyleft effect). The document link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must be observed. |*Contributing* to an existing open source project. -|*There is generally a publication obligation according to EMOTA. The governance and licence of the project are used.* The document link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must be observed. +|*There is generally a publication obligation according to EMOTA. The governance and licence of the project are used.* The document link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must be observed. |*Joint development* of a new or existing project with a community and cost sharing. -|*There is generally a publication obligation according to EMOTA.* The documents link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] are used *to set up the project and its governance.* +|*There is generally a publication obligation according to EMOTA.* The documents link:em002-2.pdf[Em002-2 Instructions for Publishing OSS], link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] are used *to set up the project and its governance.* |*All variants of development or further development* are carried out *via a supplier or commissioned third party.* -|*There is generally a publication obligation according to EMOTA.* Based on link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. If possible, the prerequisites for publication should be established during the procurement process and, if necessary, the requirements for software approval should be communicated to the supplier/third party. +|*There is generally a publication obligation according to EMOTA.* Based on link:em002-2.pdf[Em002-2 Instructions for Publishing OSS], link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and link:em002-4.pdf[Em002-4 OSS Community Guidelines]. If possible, the prerequisites for publication should be established during the procurement process and, if necessary, the requirements for software approval should be communicated to the supplier/third party. |=== === Use of unmodified open source software @@ -307,22 +307,22 @@ If an external service provider is commissioned for maintenance, support and oth === Development with open source components and release of source code -With the publication obligation according to Art. 9 EMOTA, the procedure described in -2 link:em002-2.adoc[Em002-2 Instructions for Publishing OSS] should be followed here. -The documents link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and link:em002-4.adoc[Em002-4 OSS Community Guidelines] must also be consulted if necessary. The goal is to release the project in a controlled manner using the three checklists _link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1], link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2], link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3]_. +With the publication obligation according to Art. 9 EMOTA, the procedure described in -2 link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] should be followed here. +The documents link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and link:em002-4.pdf[Em002-4 OSS Community Guidelines] must also be consulted if necessary. The goal is to release the project in a controlled manner using the three checklists _link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1], link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2], link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3]_. === Collaboration in open projects (contribution) Possible considerations for the Federal Administration's contribution to open, already existing projects are listed in the BITKOM guide _[BITCOM2024]_ Section 4.2. footnote:[See https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html in, Section 4.2.] Depending on the importance of the project for the Federal Administration, it should be examined how much responsibility the respective office wants to and can assume. -Collaboration in open projects and direct development in open projects can also take place using the documents for release. The focus is on link:em002-4.adoc[Em002-4 OSS Community Guidelines] and the associated checklist _link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]_. +Collaboration in open projects and direct development in open projects can also take place using the documents for release. The focus is on link:em002-4.pdf[Em002-4 OSS Community Guidelines] and the associated checklist _link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]_. == Properties and selection of open source licences -The properties and selection of open source licences are described in the document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +The properties and selection of open source licences are described in the document link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. == OSS procurement -Strategic issues relating to procurement and OSS are dealt with in link:em002-7.adoc[Em002-7 Strategic aspects of procurement and open source software]. +Strategic issues relating to procurement and OSS are dealt with in link:em002-7.pdf[Em002-7 Strategic aspects of procurement and open source software]. The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled _Software Procurement and Art. 9 EMOTA https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ as well as two documents 'Sample criteria -- EMOTA procurement and open source' and 'Sample contract texts -- software development'. @@ -540,12 +540,12 @@ General enquiries about the OSS tools in the Em002 document set can be directed === References -The references to the Em002 document set can be found in the link:em002.adoc[Em002 Strategic Guidelines]. +The references to the Em002 document set can be found in the link:em002.pdf[Em002 Strategic Guidelines]. === Abbreviations A list of abbreviations can be found in the main document Em002. -A glossary can be found in the document 'link:em002-6.adoc[Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS)]'. +A glossary can be found in the document 'link:em002-6.pdf[Em002-6 Frequently Asked Questions about Publishing OSS (FAQ-OSS)]'. === Business models with OSS diff --git a/docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc b/docs/em002-2-1-checklist-oss-preliminary-assessment.adoc similarity index 100% rename from docs/en/em002-2-1-checklist-oss-preliminary-assessment.adoc rename to docs/em002-2-1-checklist-oss-preliminary-assessment.adoc diff --git a/docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc b/docs/em002-2-2-checklist-oss-analysis-and-preparation.adoc similarity index 100% rename from docs/en/em002-2-2-checklist-oss-analysis-and-preparation.adoc rename to docs/em002-2-2-checklist-oss-analysis-and-preparation.adoc diff --git a/docs/en/em002-2-3-checklist-oss-release-and-publication.adoc b/docs/em002-2-3-checklist-oss-release-and-publication.adoc similarity index 100% rename from docs/en/em002-2-3-checklist-oss-release-and-publication.adoc rename to docs/em002-2-3-checklist-oss-release-and-publication.adoc diff --git a/docs/en/em002-2.adoc b/docs/em002-2.adoc similarity index 94% rename from docs/en/em002-2.adoc rename to docs/em002-2.adoc index e4cb846..090c09e 100644 --- a/docs/en/em002-2.adoc +++ b/docs/em002-2.adoc @@ -48,7 +48,7 @@ When releasing open source software, a distinction must be made between *contrib The former typically involves bug fixes and feature enhancements. Depending on the licence type and software deployment, the source code must or can be released under the existing licence of the open source project. A release agreement may have to be followed. -In the second case, starting a new open source project, governance and licence can generally be freely chosen. The only consideration is the licence under which any software elements integrated into the new project are published. Further details on licence selection can be found in the document link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. If value can be generated for the Federal Administration from a community or if the Federal Administration wants to create an ecosystem, link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] should also be completed according to link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +In the second case, starting a new open source project, governance and licence can generally be freely chosen. The only consideration is the licence under which any software elements integrated into the new project are published. Further details on licence selection can be found in the document link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. If value can be generated for the Federal Administration from a community or if the Federal Administration wants to create an ecosystem, link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] should also be completed according to link:em002-4.pdf[Em002-4 OSS Community Guidelines]. The release of open source software is more than just a technical measure. It also means establishing an appropriately open culture and getting people on board. A successful open source culture is a mixture of openness, technical excellence, strong social interaction and a shared commitment. @@ -60,7 +60,7 @@ Figure 1 – Decision tree for software release == Preliminary assessment process -*Objective:* Understand the advantages and possible consequences of publishing the software. Decide whether the software can be published and if so, whether building an active community is worthwhile. NB: link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed as early as possible in the project, as this can influence the way the software is developed. +*Objective:* Understand the advantages and possible consequences of publishing the software. Decide whether the software can be published and if so, whether building an active community is worthwhile. NB: link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed as early as possible in the project, as this can influence the way the software is developed. === Release under EMOTA @@ -68,7 +68,7 @@ According to Art. 9 of the Federal Act of 17 March 2023 ++[++EMOTA2023++]++ on t For custom software created on behalf of the Confederation, the General Terms and Conditions of the Confederation ++[++BBL-AGB++]++ generally apply. Under clause 25.1, these stipulate that ownership of source code and documentation transfers to the service procurer (the Confederation). If the software was procured jointly by several organisations or other institutions, it must be checked who has the rights to the code. For example, ownership may lie with an association founded for this purpose. -The mere use of standard software is not covered by Art. 9 EMOTA, and release would generally not be possible anyway, as the rights to standard software often remain with the vendor (GTC Confederation for Standard Software Procurement). However, custom extensions to standard software are certainly suitable for publication. Normally, these are owned by the Confederation. Mere configuration adjustments are less suitable for publication. The topic is dealt with in link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software] and the documents ++[++KKB-MB++]++ and ++[++BBL-WL++]++. In principle, extensions are always subject to Art. 9 EMOTA. +The mere use of standard software is not covered by Art. 9 EMOTA, and release would generally not be possible anyway, as the rights to standard software often remain with the vendor (GTC Confederation for Standard Software Procurement). However, custom extensions to standard software are certainly suitable for publication. Normally, these are owned by the Confederation. Mere configuration adjustments are less suitable for publication. The topic is dealt with in link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software] and the documents ++[++KKB-MB++]++ and ++[++BBL-WL++]++. In principle, extensions are always subject to Art. 9 EMOTA. ==== Software in relation to EMOTA @@ -96,11 +96,11 @@ In joint development, the Confederation creates the software with other organisa If the Confederation contributes directly to third-party software, this source code also falls under Art. 9 EMOTA. It must be ensured that this is done in accordance with federal authorities' interests, that participation meets the project requirements, and that the Federal Administration adheres to the governance. -This is done using link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. +This is done using link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist]. ==== Legacy code -For old software (*legacy software*), the retrospective effort for publication is higher than if release was planned from the beginning. For legacy software, it only makes sense to make this effort if a potential user wants to use the software. Regardless, link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed to document relevant decisions. +For old software (*legacy software*), the retrospective effort for publication is higher than if release was planned from the beginning. For legacy software, it only makes sense to make this effort if a potential user wants to use the software. Regardless, link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] should be completed to document relevant decisions. Applications which federal authorities began to develop on or after 1 January 2024 or which are being developed on behalf of the Confederation based on a contract concluded after 1 January 2024 are not considered legacy and in, any case, fall under the publication requirement according to Art. 9 para. 1 EMOTA. @@ -112,10 +112,10 @@ In some cases, the software may not be a standalone application but only parts t *Tasks:* -* Gather information from link:em002-5.adoc[Em002-5 OSS Tools information sheet]. This describes both general information about open source software and specific information about applying EMOTA. +* Gather information from link:em002-5.pdf[Em002-5 OSS Tools information sheet]. This describes both general information about open source software and specific information about applying EMOTA. * Check whether the requirements under EMOTA are met. -* Complete link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist]. As a rule, it makes sense to directly involve the contact persons from the software supplier/developer. -* If needed, complete link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. +* Complete link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist]. As a rule, it makes sense to directly involve the contact persons from the software supplier/developer. +* If needed, complete link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist]. *Decision:* Does the software have to be published and how should this be done? @@ -167,7 +167,7 @@ Here too, ++[++KKB-MB++]++ contains important information. image::./assets/em002-2/media/image3.png[Process for handling third-party rights exceptions] -Figure 2 - Exception: Third-party rights (always also take into account ++[++KKB-MB++]++ and link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]) +Figure 2 - Exception: Third-party rights (always also take into account ++[++KKB-MB++]++ and link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software]) *Tasks:* @@ -177,7 +177,7 @@ Figure 2 - Exception: Third-party rights (always also take into account ++[++KKB * Verify that the application contains no proprietary or protected parts. * Check that there are no obstacles due to patent protection (as far as possible and reasonable). * Check whether the release is to be carried out by a third party. -* Check whether development should be based on open source software development (using the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +* Check whether development should be based on open source software development (using the link:em002-4.pdf[Em002-4 OSS Community Guidelines]. *Decision:* Can the software be published without violating third-party rights? @@ -237,7 +237,7 @@ If the software was developed internally at the Confederation and the Confederat *Minimum release and support* -EMOTA does not specify any requirements regarding publication. A minimum release of the source code fulfils the legal requirement. No further activities are required. The question of whether and to what extent support is offered and how actively the project is maintained can be answered using link:em002-4.adoc[Em002-4 OSS Community Guidelines.] +EMOTA does not specify any requirements regarding publication. A minimum release of the source code fulfils the legal requirement. No further activities are required. The question of whether and to what extent support is offered and how actively the project is maintained can be answered using link:em002-4.pdf[Em002-4 OSS Community Guidelines.] *Open source software development (OSSD)* @@ -255,7 +255,7 @@ Basic agreement and feasibility for publishing the application as open source is === Minimising effort -The checklists and instructions are structured to minimise the effort required for releases. Consistent advance planning of the release at project start and development designed for release minimises effort. Some administrative effort and costs will inevitably arise ++[++Le2023++]++. These can potentially be recovered through communities with shared development costs (see link:em002-4.adoc[Em002-4 OSS Community Guidelines]). +The checklists and instructions are structured to minimise the effort required for releases. Consistent advance planning of the release at project start and development designed for release minimises effort. Some administrative effort and costs will inevitably arise ++[++Le2023++]++. These can potentially be recovered through communities with shared development costs (see link:em002-4.pdf[Em002-4 OSS Community Guidelines]). === Choice of publication language @@ -271,7 +271,7 @@ Public communication should primarily consider the target audience. It should al == Analysis and preparation -*Objective:* The work required for open source publication is completed. Decisions regarding licence and type of community have been made. This is done using link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist]. +*Objective:* The work required for open source publication is completed. Decisions regarding licence and type of community have been made. This is done using link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Analysis and Preparation Checklist]. === Source code analysis @@ -296,7 +296,7 @@ These activities are independent of publication but are prerequisites for good s === Licence selection -*Refer to link:em002-3.adoc[Em002-3 OSS Licensing Guidelines].* +*Refer to link:em002-3.pdf[Em002-3 OSS Licensing Guidelines].* Internationally established licence texts should be used where possible and appropriate. Liability claims by licensees should be excluded to the extent legally possible. @@ -348,7 +348,7 @@ Further technical details of these documents are described in the annex. == Publication and announcement -*Objective:* The application is published as open source and easily findable by third parties. All components are ready for publication and the community is built or established. This is done using link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. To a certain extent, it involves recapitulating decisions already made. +*Objective:* The application is published as open source and easily findable by third parties. All components are ready for publication and the community is built or established. This is done using link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist]. To a certain extent, it involves recapitulating decisions already made. === Choice of platform @@ -367,7 +367,7 @@ We currently recommend setting up an organisation on GitHub per federal authorit |GitLabfootnote:[https://about.gitlab.com/] |Online platform from the company of the same name GitLab, which is itself published under an open source licence. Offers many additional tools besides SCM. Can also be operated locally, thus providing a degree of sovereignty. Available in both Free and Enterprise versions (subscription). |Bitbucketfootnote:[https://bitbucket.org/product/en] |Atlassian’s online platform, specifically integrated into its ecosystem. Available in both Free and Enterprise versions (subscription). |Internal SCM system |If own SCM platform is provided, it can also publish and make certain repo/projects available. Operation must be ensured. -|Federal platform |There is currently no central federal platform for publishing software. A measure to this effect is proposed in link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. +|Federal platform |There is currently no central federal platform for publishing software. A measure to this effect is proposed in link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. |Website, public FTP server, etc. |EMOTA does not define how software should be published. A minimum releasefootnote:[A minimum publication only includes the publication of the source code and other minimal artefacts. This type of publication fulfils EMOTA requirements. However, no added value is achieved through the publication.] can also be done on a website or other publicly accessible resources. However, this is not suitable for sustainable collaboration in the sense of open source. |=== @@ -392,7 +392,7 @@ When the prerequisites are clarified, the software can be published. *Tasks* -* Check prerequisites against the link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. +* Check prerequisites against the link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist]. * Access to platform is available and governance clarified. * Publication of source code and documentation by the developer. @@ -415,7 +415,7 @@ When publishing software, a community can develop that can contribute to the sof *Tasks* * Clarify who potential users or interested parties are. -* Determine the appropriate form for the specific application using the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +* Determine the appropriate form for the specific application using the link:em002-4.pdf[Em002-4 OSS Community Guidelines]. * Build the community. * Community building activities. @@ -433,9 +433,9 @@ See _Em002 Strategic Guidelines for Open Source Software in the Federal Administ === Abbreviations -See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. +See link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.pdf[Em002-6 FAQ about OSS]. -=== Accompanying documentation link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] – Documentation +=== Accompanying documentation link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] – Documentation === Source code documentation @@ -521,7 +521,7 @@ While the Developer Guidelines describe the collaboration and social norms of th * An architecture sketch with a rough description of the architecture, preferably including context demarcation and rough component view.footnote:[Architecture framework MMB (Bund Modelling Method) or arc42. http://arc42.org/] * For applications: How the application can be started for development or debugging purposes and what infrastructure components are necessary for this. -== Accompanying documentation for link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] – Source code +== Accompanying documentation for link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] – Source code === Source code history @@ -556,7 +556,7 @@ Removing author information removes attribution, traceability, and contact infor Virtually every project uses third-party libraries (software libraries, dependencies) to access commonly used functions without having to code them. These libraries usually depend on other libraries, resulting in multi-level dependencies (transitive dependencies). Depending on the programming language, even small projects can have hundreds of dependencies. -The results of this clarification must be considered when choosing a licence in accordance with link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] and in link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. +The results of this clarification must be considered when choosing a licence in accordance with link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] and in link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist]. For each of these dependencies, ensure that its licence is compatible with the project licence. Dependencies that are not under an open source licence or which have not declared a licence or use a viral licence that does not match the project licence are particularly problematic. Some libraries are licensed under more than one licence and allow the user to choose one. diff --git a/docs/en/em002-3.adoc b/docs/em002-3.adoc similarity index 96% rename from docs/en/em002-3.adoc rename to docs/em002-3.adoc index 3a9585f..f8ba800 100644 --- a/docs/en/em002-3.adoc +++ b/docs/em002-3.adoc @@ -38,7 +38,7 @@ Figure 1: Simplified licence selection guide To a certain extent, these two licences form the two extremes in the spectrum of OSS licences. It can be very useful to select a more suitable licence for a specific project. This guide is intended to provide concrete assistance. -If the analysis of the software libraries reveals that a different licence must be used, the developers will draw the project management's attention to this. The analysis is set out in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +If the analysis of the software libraries reveals that a different licence must be used, the developers will draw the project management's attention to this. The analysis is set out in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. When working on existing projects, all OSI-compatible licences are generally acceptable. @@ -251,13 +251,13 @@ This section concerns the following cases: + For completely new developments, a licence type should be chosen that enables a broad and sustainable basis for further developments. For this, it is important that the licence in question should be widely accepted in the relevant developer community. -The compatibility check is carried out according to link:em002-2.adoc[Em002-2 Instructions for Publishing OSS], Section 7.4. The compatibility of the licences is shown in Figure 2. +The compatibility check is carried out according to link:em002-2.pdf[Em002-2 Instructions for Publishing OSS], Section 7.4. The compatibility of the licences is shown in Figure 2. The following dimensions should be considered: * Use case -* Desired checking link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] -* Ease of building a community link:em002-4.adoc[Em002-4 OSS Community Guidelines] +* Desired checking link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] +* Ease of building a community link:em002-4.pdf[Em002-4 OSS Community Guidelines] * Ease of application * Legal certainty * Distribution @@ -284,7 +284,7 @@ When collaborating on existing projects, the following licences can also be used * Mozilla Public Licence * Microsoft Public Licence -If another licence is to be used, it is recommended to briefly justify this in link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]. +If another licence is to be used, it is recommended to briefly justify this in link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist]. *According to Art. 9 para. 4 EMOTA, internationally established licences should be used in all cases.* @@ -385,7 +385,7 @@ Figure 3: Extended decision tree for licence selection in the Federal Administra The bill of materials in Figure 3 is the software bill of materials (SBOM) of all pre-existing software libraries and sub-programs that have been incorporated into the overall solution. Each library has its own licence. Depending on how this is compatible with others (see Section 4.4), the possible selection of licences for the publication is limited. -One last point can also influence the decision: *changing from a more restrictive licence to a less restrictive one is easier afterwards*. In the opposite case, a forkfootnote:[For definition see link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration].] is almost unavoidable. +One last point can also influence the decision: *changing from a more restrictive licence to a less restrictive one is easier afterwards*. In the opposite case, a forkfootnote:[For definition see link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration].] is almost unavoidable. == Special legal topics @@ -433,7 +433,7 @@ The author can license software under different licences simultaneously. This is An interesting form of dual licensing is where the copyright holder licenses the software as OSS with a strong copyleft (which prevents it from being integrated into proprietary software) and also offers interested licensees a _paid_ licence that allows them to integrate the software into their proprietary software. -Because interested licensees can thus avoid releasing their proprietary software as OSS, they are willing to pay for the licence. See also the annex to link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. +Because interested licensees can thus avoid releasing their proprietary software as OSS, they are willing to pay for the licence. See also the annex to link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. For the federal authorities themselves, dual licensing is likely to be uninteresting in most cases. As long as the copyrights lie with the federal authorities (which is regulated, for example, according to the Federal Administration's general terms and conditions), the federal authorities alone can decide on any dual licensing. @@ -469,7 +469,7 @@ From a data protection point of view, compulsion to do so should be avoided, alt === Copyright, licences for generative AI for code creation -Here, we are referring only to code that has been created using generative AI. Further information on this topic can be found in link:em002-6.adoc[Em002-6 FAQ about OSS++*++ in Section 2.2]. Code created by an LLM is not itself protected by copyright. However, the training data used by the LLM may be protected by copyright. If the code corresponds 1:1, then the licence should also be adopted. If the code was created piecemeal and then modified by the developers, there is little risk that this will be considered derived software. It should be noted that certain LLMs require the code to be labelled accordingly; any contractual agreements in this regard must be observed. +Here, we are referring only to code that has been created using generative AI. Further information on this topic can be found in link:em002-6.pdf[Em002-6 FAQ about OSS++*++ in Section 2.2]. Code created by an LLM is not itself protected by copyright. However, the training data used by the LLM may be protected by copyright. If the code corresponds 1:1, then the licence should also be adopted. If the code was created piecemeal and then modified by the developers, there is little risk that this will be considered derived software. It should be noted that certain LLMs require the code to be labelled accordingly; any contractual agreements in this regard must be observed. === Contributor Licence Agreements (CLA) and Developer Certificate of Origin (DCO) @@ -495,9 +495,9 @@ Figure 4: Transfer source code and rights in different constellations There are no problems for *own developments* (creation): According to Art. 17 CopA, the federal authority is the holder of the usage rights to software created by its own employees. For *third-party developers*, the federal authorities should secure the rights (for example, by using the corresponding GTCs of the Confederation). This means that no CLA or DCO is necessary here. -Where federal authorities are the main developers and accept contributions and collaborations, the use of a CLA should be avoided. Digital Certificates of Origin (explained with an example in link:em002-4.adoc[Em002-4 OSS Community Guidelines], Section 3.3) may be used instead. In principle, contributions to federal authority projects should build on the OSS licence so as not to raise the barrier to contribution any further. +Where federal authorities are the main developers and accept contributions and collaborations, the use of a CLA should be avoided. Digital Certificates of Origin (explained with an example in link:em002-4.pdf[Em002-4 OSS Community Guidelines], Section 3.3) may be used instead. In principle, contributions to federal authority projects should build on the OSS licence so as not to raise the barrier to contribution any further. -Should a need for a CLA nonetheless be identified in a specific case following appropriate review, the federal authority should use the Apache CLA.footnote:[https://www.apache.org/licenses/contributor-agreements.html] In that event, this decision and the CLA should be noted in the concluding remarks of both link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. +Should a need for a CLA nonetheless be identified in a specific case following appropriate review, the federal authority should use the Apache CLA.footnote:[https://www.apache.org/licenses/contributor-agreements.html] In that event, this decision and the CLA should be noted in the concluding remarks of both link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Preliminary Assessment Checklist] and link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist]. Where federal authorities contribute to third-party software that requires a CLA, the legal service must examine on a case-by-case basis whether the federal authority can accept the existing CLA.footnote:[For any given recipient, the federal administration would only need to review the signing of a CLA once. In other organisations, this is therefore treated as a high-level matter, with signed CLAs kept on file in the contracts repository. CLAs must not undermine the federal authority's obligations under Art. 9 EMOTA.] The following points must be determined: @@ -572,11 +572,11 @@ Today, compliance with open source licences is primarily implemented using softw === References -See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. +See link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. === Abbreviations -See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. +See link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.pdf[Em002-6 FAQ about OSS]. === Examples of releases and their licence diff --git a/docs/en/em002-4-1-checklist-oss-community.adoc b/docs/em002-4-1-checklist-oss-community.adoc similarity index 100% rename from docs/en/em002-4-1-checklist-oss-community.adoc rename to docs/em002-4-1-checklist-oss-community.adoc diff --git a/docs/en/em002-4.adoc b/docs/em002-4.adoc similarity index 97% rename from docs/en/em002-4.adoc rename to docs/em002-4.adoc index 868ec7a..ded4ae9 100644 --- a/docs/en/em002-4.adoc +++ b/docs/em002-4.adoc @@ -33,7 +33,7 @@ The most important points of the document are listed below. * A community can emerge and then be formalised. * The goal of the community is to increase the *benefit for everyone*. General principle: 'You get back at least as much as you put in'. * The community should be *structured as simply as possible*. -* In a first step, the community should be briefly reviewed using the checklist link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]. Only if it makes sense should it be further developed. +* In a first step, the community should be briefly reviewed using the checklist link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Only if it makes sense should it be further developed. * Formalisation takes place via a *community concept*. As much as possible should be taken from existing sources. General principle: 'Don't reinvent the wheel'. * If collaboration is the aim, this must be taken into account at the very beginning of the project, as potential partners should already be picked up during the requirements analysis. This also needs to be well planned from the outset in terms of legal and procurement law. * The options for joining an existing collaboration in regard to legal and procurement law must be examined. @@ -54,7 +54,7 @@ As a second element, to promote standardisation, a directory of existing communi This document does not include direct recommendations for organising communities for software libraries (parts of software that fulfil partial functions, e.g. PDF generation). Normally, no separate concept is developed for these; instead, they use the simple template defined in the repository's storage template. -The document link:em002-1.adoc[Em002-01 Practical Guidelines for Open Source Software in the Federal Administration] contains in Section 4 fundamental forms of collaboration, in Section 8 the various support models, and in the Annex information on market behaviour of open source. +The document link:em002-1.pdf[Em002-01 Practical Guidelines for Open Source Software in the Federal Administration] contains in Section 4 fundamental forms of collaboration, in Section 8 the various support models, and in the Annex information on market behaviour of open source. == Type, aim and purpose of a community @@ -84,13 +84,13 @@ The following constellations exist: * *Joining a collaboration*: The Federal Administration must examine whether and how it can do this. * *Contribution to a third-party project*: The point to be checked is the project's policy for contribution (Contributor Licence Agreement, Developer Certificate of Origin, etc.). -Procurement law issues are dealt with in link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]. +Procurement law issues are dealt with in link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software]. === Special case: New collaboration for the development, maintenance and support of open source software The collective costs of open source software decrease when it is developed and further maintained collaboratively. This can occur without formal cooperation arrangements, or with no more than joint planning. -Where a more formal collaboration is sought, a market assessment should be carried out to ensure that collaboration is the most appropriate form of cooperation. Collaborations are more cost-effective than individual development by each party (see link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]). +Where a more formal collaboration is sought, a market assessment should be carried out to ensure that collaboration is the most appropriate form of cooperation. Collaborations are more cost-effective than individual development by each party (see link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]). It should be noted that, for collaborations, it makes sense to initiate the collaboration at a very early stage in the HERMESfootnote:[https://www.hermes.admin.ch/en/project-management/method-overview.html] project methodology --- specifically during the situation analysis and requirements phases. @@ -113,7 +113,7 @@ There are also two special casesfootnote:[https://www.eda.admin.ch/deza/en/home/ ==== Procurement law dimension -In many cases, collaboration will take place between public sector organisations. In such cases, procurement is unproblematic where the arrangement is 'in-state' (see link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software]). +In many cases, collaboration will take place between public sector organisations. In such cases, procurement is unproblematic where the arrangement is 'in-state' (see link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software]). Contracts with foreign companies not domiciled in Switzerland are possible, provided procurement law requirements are met. @@ -156,7 +156,7 @@ By making a contribution to this project, we certify that: (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source licence(s) involved. ____ -The structure of a Contributor Licence Agreement is described in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], Section 8.9. +The structure of a Contributor Licence Agreement is described in link:em002-3.pdf[Em002-3 OSS Licensing Guidelines], Section 8.9. The effective transfer of code takes place in accordance with the guidelines of the respective project. @@ -209,7 +209,7 @@ A possible source for parts is also the documentation of the Eclipse Foundation, == Fundamental decisions when building a community -The principles of the community, or lack thereof, are determined using link:em002-4-1-checklist-oss-community.adoc[Em002-4.1]. The relevant fundamental questions can be found in the morphological box in Figure 1. +The principles of the community, or lack thereof, are determined using link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. The relevant fundamental questions can be found in the morphological box in Figure 1. image::assets/em002-4/media/image1.png[Morphological box OSS community] @@ -366,7 +366,7 @@ This information can all be displayed with publiccode.yml.footnote:[https://yml. === Objectives -The objective should contain the actual purpose or 'vision' of the application. This vision should also be included in the *README.md* file in the repository (see link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist]). +The objective should contain the actual purpose or 'vision' of the application. This vision should also be included in the *README.md* file in the repository (see link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Analysis and Preparation Checklist]). At the same time, it should also describe what the community is aiming for: @@ -745,7 +745,7 @@ In OSS projects, this is normally regulated through the *Code of Conduct*. The F === Open development -If software development is planned in an open repository from the start, release happens automatically. The relevant checklists according to the instructions link:em002-2.adoc[Em002-2] must be completed at the beginning, and the development processes of the service provider/supplier must allow this. The advantage is that the community can be built from the very beginning. Multiple organisations can also collaborate on the development. +If software development is planned in an open repository from the start, release happens automatically. The relevant checklists according to the instructions link:em002-2.pdf[Em002-2] must be completed at the beginning, and the development processes of the service provider/supplier must allow this. The advantage is that the community can be built from the very beginning. Multiple organisations can also collaborate on the development. Closed repositories are an intermediate form, but are used for other partners in a collaboration. @@ -771,7 +771,7 @@ The contribution of software to other projects is addressed in Section 3.3. The The following points are important: -* A suitable Contributor Licence Agreement must be used to ensure that the source code subsequently belongs to the Confederation (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], section on Contributor Licence Agreements). This must be signed by the owner of the contribution. +* A suitable Contributor Licence Agreement must be used to ensure that the source code subsequently belongs to the Confederation (see also link:em002-3.pdf[Em002-3 OSS Licensing Guidelines], section on Contributor Licence Agreements). This must be signed by the owner of the contribution. * Confirmations must be filed. * Contributions must be reviewed before being integrated into the codebase. * Submissions should be responded to in a timely manner (issues, requests, pull requests) and handled as constructively as possible. @@ -845,7 +845,7 @@ Furthermore, user management needs to be resolved to ensure control over the pub * New Section 7.7 Handling third-party contributions * Noted that suppliers should not publish entirely on their own (in accordance with _[BBL-WL]_, V.2) * Publicode.yml mentioned -* Alignment with new link:em002-7.adoc[Em002-7] +* Alignment with new link:em002-7.pdf[Em002-7] * Further editorial changes and improvements === References @@ -854,7 +854,7 @@ See _Em002 Strategic Guidelines for Open Source Software in the Federal Administ === Abbreviations -See link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.adoc[Em002-6 FAQ about OSS]. +See link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-6.pdf[Em002-6 FAQ about OSS]. === Examples of existing community concepts diff --git a/docs/en/em002-5.adoc b/docs/em002-5.adoc similarity index 89% rename from docs/en/em002-5.adoc rename to docs/em002-5.adoc index a65ecad..34b278a 100644 --- a/docs/en/em002-5.adoc +++ b/docs/em002-5.adoc @@ -47,33 +47,33 @@ If yes, see b) === a) Procurement and use of standard software Where the Confederation purchases software without customisation, Article 9 EMOTA does not apply. Every federal authority is free to decide whether to procure and use open source or other software. -Assistance with the procurement of software can be found on the website of the https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Federal Office for Buildings and Logistics (FOBL)] and the https://perimap.admin.ch/goto_perimap_file_46835_download.html[Information sheet on software procurement and Art. 9 EMOTA] from the CCPP. If necessary, link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] can also be consulted. +Assistance with the procurement of software can be found on the website of the https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Federal Office for Buildings and Logistics (FOBL)] and the https://perimap.admin.ch/goto_perimap_file_46835_download.html[Information sheet on software procurement and Art. 9 EMOTA] from the CCPP. If necessary, link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and OSS] can also be consulted. === b) Creation or further development of software -If a federal authority develops software itself or through third parties, OSS Article 9 EMOTA must be applied. This also includes software that is further developed as part of a contribution in existing OSS projects. Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. Please complete the link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist]. +If a federal authority develops software itself or through third parties, OSS Article 9 EMOTA must be applied. This also includes software that is further developed as part of a contribution in existing OSS projects. Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. Please complete the link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist]. -NOTE: This checklist also serves as a justification for why software [.underline]#does not# have to be published. It should therefore be consulted as early as possible in the project. The guide link:em002-2.adoc[Em002-2] describes the entire process. +NOTE: This checklist also serves as a justification for why software [.underline]#does not# have to be published. It should therefore be consulted as early as possible in the project. The guide link:em002-2.pdf[Em002-2] describes the entire process. Further questions to be clarified are: === Under which open source licence is it published? -The fundamental question of whether the software is published under a [.underline]#copyleft# licence (in which case AGPL V3 is a good choice, for example) or [.underline]#permissively# (in which case under an MIT licence, for example) must be answered. With regard to licence selection, the link:em002-3.adoc[Em002-3 OSS Licensing Guidelines] provides detailed information. Please complete the link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist]. +The fundamental question of whether the software is published under a [.underline]#copyleft# licence (in which case AGPL V3 is a good choice, for example) or [.underline]#permissively# (in which case under an MIT licence, for example) must be answered. With regard to licence selection, the link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] provides detailed information. Please complete the link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist]. NOTE: Ideally, this should be completed by the (technical) project manager or IT architect. === Where and how should the software and associated artefacts be published? -Please complete the link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] +Please complete the link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist] NOTE: This is a collective record of where and how software is published. It may be necessary to involve other organisations. === Should an OSS community be established? -link:em002-4.adoc[Em002-4 OSS Community Guidelines] describe the advantages and tasks involved in setting up an OSS community on the basis of a concept. +link:em002-4.pdf[Em002-4 OSS Community Guidelines] describe the advantages and tasks involved in setting up an OSS community on the basis of a concept. -[.underline]#If yes#: Fill in the link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] which provides information about the desired type and platform for the community. +[.underline]#If yes#: Fill in the link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] which provides information about the desired type and platform for the community. NOTE: The project team has a great deal of leeway here as to whether and what type of community should be created. It may be necessary to involve other units. diff --git a/docs/en/em002-6.adoc b/docs/em002-6.adoc similarity index 90% rename from docs/en/em002-6.adoc rename to docs/em002-6.adoc index 31adb34..d8ad294 100644 --- a/docs/en/em002-6.adoc +++ b/docs/em002-6.adoc @@ -58,7 +58,7 @@ Each section is structured as follows: |Q |*What is meant by open source software?* |A -|This is defined in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] +|This is defined in link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] |=== === Software and licences @@ -68,7 +68,7 @@ Each section is structured as follows: |Q |*What is meant by software?* |A -|This is defined in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. For licences, see link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +|This is defined in link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. For licences, see link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. |=== [cols="1,9",options="header"] @@ -76,7 +76,7 @@ Each section is structured as follows: |Q |*What is meant by licences?* |A -|Here we are referring to software licences. Further information can be found in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +|Here we are referring to software licences. Further information can be found in link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. |=== [cols="1,9",options="header"] @@ -114,7 +114,7 @@ a|According to Art. 9 EMOTAfootnote:[SR 172.019], federal authorities of the cen Publication of source code can only be avoided in relation to third-party rights or for security-relevant reasons. -More information can be found in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +More information can be found in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== [cols="1,9",options="header"] @@ -122,7 +122,7 @@ More information can be found in link:em002-2.adoc[Em002-2 Instructions for Publ |Q |*What is meant by security-relevant reasons?* |A -|The security-relevant reasons permitted under Art. 9 EMOTA and how to deal with them are defined in Section 3.2 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|The security-relevant reasons permitted under Art. 9 EMOTA and how to deal with them are defined in Section 3.2 of link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== [cols="1,9",options="header"] @@ -130,7 +130,7 @@ More information can be found in link:em002-2.adoc[Em002-2 Instructions for Publ |Q |*What are third-party rights?* |A -|Third-party rights under Art. 9 EMOTA and how to deal with them are defined in Section 3.3 of link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +|Third-party rights under Art. 9 EMOTA and how to deal with them are defined in Section 3.3 of link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== [cols="1,9",options="header"] @@ -181,7 +181,7 @@ a|According to Art. 9 para. 1 EMOTA, software that is or has been developed afte For software developed before 1 January 2024, release should be considered when major changes are pending. -If there is considerable interest from third parties, existing software may also be released voluntarily (possibly with cost sharing). In this case, a community (see link:em002-4.adoc[Em002-4]) should also be considered. +If there is considerable interest from third parties, existing software may also be released voluntarily (possibly with cost sharing). In this case, a community (see link:em002-4.pdf[Em002-4]) should also be considered. For smaller scripts, publication is usually not the best option. There may be repositories for tools that then go through the release process at the same time. @@ -289,7 +289,7 @@ This consent should be obtained from suppliers and employees as part of the proc |Q |*Where can I find the documentation for OSS procurement?* a|A -a|With Version 2.0, a tool link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and Open Source Software] was made available. +a|With Version 2.0, a tool link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software] was made available. The Competence Centre for Federal Public Procurement (CCPP) has published a new information sheet entitled Software Procurement and Art. 9 EMOTA [KBB-MB] as well as two documents 'Sample criteria – EMOTA procurement and open source.docx' and 'Sample contract texts – software development.docx'. @@ -333,7 +333,7 @@ Publication under an open source licence does not mean waiving copyright: this r Only on the basis of their copyright can they legally defend against licence violations or grant more extensive licences in parallel to OSS licences. -The [.underline]#original rights# should therefore always lie with the federal government for new or further developments, if possible. [.underline]#Contributor Licence Agreements# (CLA) or Developer Certificate of Origin (DCO) should be used for other participants. Instructions for this can be found in link:em002-3.adoc[Em002-3 OSS Licensing Guidelines], link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +The [.underline]#original rights# should therefore always lie with the federal government for new or further developments, if possible. [.underline]#Contributor Licence Agreements# (CLA) or Developer Certificate of Origin (DCO) should be used for other participants. Instructions for this can be found in link:em002-3.pdf[Em002-3 OSS Licensing Guidelines], link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software] and link:em002-4.pdf[Em002-4 OSS Community Guidelines]. |=== [cols="1,9",options="header"] @@ -343,7 +343,7 @@ The [.underline]#original rights# should therefore always lie with the federal g a|A a|According to Art. 9 EMOTA: yes, if they were developed after 1 January 2024. -However, this should be done in a way that also provides benefit. The document link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] provides information on the process. +However, this should be done in a way that also provides benefit. The document link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software] provides information on the process. |=== [cols="1,9",options="header"] @@ -355,7 +355,7 @@ a|Art. 9 EMOTA is not specific in this regard and there is a great deal of room For example, the requirements of the law are satisfied by simply publishing the source code in a zip file on a website. -In order to achieve a benefit, including through the publication of documentation etc., this should be done on a code repository according to best practices. Information on this can be found in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +In order to achieve a benefit, including through the publication of documentation etc., this should be done on a code repository according to best practices. Information on this can be found in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== [cols="1,9",options="header"] @@ -393,7 +393,7 @@ MIT, on the other hand, is a very liberal licence where almost anything is possi The two licences cover the entire spectrum. If particular importance is attached to not naming the federal government in the case of permissive licences, BSD-3 is to be preferred over MIT. -For a more detailed selection of licences, please refer to link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]. +For a more detailed selection of licences, please refer to link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. |=== === Quality criteria for OSS @@ -403,7 +403,7 @@ For a more detailed selection of licences, please refer to link:em002-3.adoc[Em0 |Q |*Does open source software have to meet certain quality criteria?* |A -|As a rule, all quality criteria for any other software also applies. Open source primarily makes everything more transparent. To comply with the licence, the criteria for a 'good' release, and any community rules in place, some additional points are necessary. These are outlined in link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]. +|As a rule, all quality criteria for any other software also applies. Open source primarily makes everything more transparent. To comply with the licence, the criteria for a 'good' release, and any community rules in place, some additional points are necessary. These are outlined in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist]. |=== [cols="1,9",options="header"] @@ -423,7 +423,7 @@ Publication is the Federal Administration's way of going public. If this is not |Q |*How are development guidelines regulated?* |A -|Apart from the general requirements set out in the tools, there are no special requirements regarding the development of open source software. Guidance is provided in link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +|Apart from the general requirements set out in the tools, there are no special requirements regarding the development of open source software. Guidance is provided in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] and link:em002-4.pdf[Em002-4 OSS Community Guidelines]. |=== [cols="1,9",options="header"] @@ -441,7 +441,7 @@ Please contact the responsible unit in the DTI (opensource@bk.admin.ch) to check Federal authorities should in all cases maintain a local copy of the code. It is also advisable for each federal authority to have a corresponding strategy. It is also advisable for each federal authority to have corresponding internal rules in place. -Further recommendations are given in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +Further recommendations are given in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== === Documentation @@ -466,12 +466,12 @@ a|A a|* If the projects are open source, then Art. 9 EMOTA is fulfilled. However, the projects must also remain open source. If they fail to do so, the code must be published again. * Upstream contributions have the advantage that maintenance takes place within the upstream project and the benefit for the community is maximised. + -The following disadvantages exist: less control and influence, a CLA may have to be signed or a DCO (see link:em002-4.adoc[Em002-4] Section 3.3). The contributions also do not appear in the publiccode.yml and the federal directories. A completely different advantage is that with such contributions, the developers continue to develop within the ecosystem. +The following disadvantages exist: less control and influence, a CLA may have to be signed or a DCO (see link:em002-4.pdf[Em002-4] Section 3.3). The contributions also do not appear in the publiccode.yml and the federal directories. A completely different advantage is that with such contributions, the developers continue to develop within the ecosystem. * As long as the risks and effort remain manageable (CLA content, collection of the code), upstream contributions are to be welcomed. -* The licence of the upstream project then applies to the contribution. This corresponds to the procedure in link:em002-3.adoc[Em002-3]. +* The licence of the upstream project then applies to the contribution. This corresponds to the procedure in link:em002-3.pdf[Em002-3]. * *Forking of upstream projects should be avoided:* The entire maintenance and update burden then falls to the federal authority. Inadequate maintenance of the fork also represents a security risk. There is hardly any benefit for the community. * Contributions to upstream projects should generally be viewed positively and actively discussed by the federal authorities' project managers. -* If the upstream project belongs to the Federal Administration and involves third-party contributions, link:em002-7.adoc[Em002-7] Section 9 will help. +* If the upstream project belongs to the Federal Administration and involves third-party contributions, link:em002-7.pdf[Em002-7] Section 9 will help. |=== === Support @@ -491,7 +491,7 @@ According to Art. 9 paras 5 and 6 EMOTA, it may also charge fees for support. |Q |*How should an authority proceed if it wishes to charge for support?* |A -|For resource reasons, this is not part of the current project to provide tools. If required, this could be included in the tools in a subsequent stage. For the time being, each federal authority regulates this itself. (See also link:em002-4.adoc[Em002-4 OSS Community Guidelines]) +|For resource reasons, this is not part of the current project to provide tools. If required, this could be included in the tools in a subsequent stage. For the time being, each federal authority regulates this itself. (See also link:em002-4.pdf[Em002-4 OSS Community Guidelines]) |=== == Tools @@ -503,9 +503,9 @@ According to Art. 9 paras 5 and 6 EMOTA, it may also charge fees for support. |Q |Is there any central guidance on working with open source software in the Federal Administration? a|A -a|Yes, the DTI Sector of the Federal Chancellery provides comprehensive materials for this as part of link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. +a|Yes, the DTI Sector of the Federal Chancellery provides comprehensive materials for this as part of link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. -OSS is discussed in general terms in link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. Release under Art. 9 EMOTA is addressed in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. +OSS is discussed in general terms in link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration]. Release under Art. 9 EMOTA is addressed in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. |=== === Checklists @@ -517,10 +517,10 @@ OSS is discussed in general terms in link:em002-1.adoc[Em002-1 Practical Guideli a|A a|Yes, the DTI Sector of the Federal Chancellery provides the following checklists for free use: -* link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] -* link:em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 OSS Analysis and Preparation Checklist] -* link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist] -* link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 OSS Analysis and Preparation Checklist] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] See the *Checklist for Art. 9 EMOTA Blanket Exception* [BBL-CL] from the FOBL. |=== @@ -631,7 +631,7 @@ Under Article 11 of the Government Liability Act, the Confederation's liability |Q |*If software is based on a library/program component published under a permissive licence, can the main software (excluding the library) be published under a non-permissive licence?* |A -|Yes, this is unproblematic. See the information provided in the guidelines link:em002-3.adoc[Em002-3]. +|Yes, this is unproblematic. See the information provided in the guidelines link:em002-3.pdf[Em002-3]. |=== === Licence provisions @@ -687,7 +687,7 @@ Nevertheless, it is advisable to address the provider's responsibility for their |Q |*Does it matter whether OSS is used commercially or non-commercially?* |A -|Open source licences generally do not distinguish between commercial and non-commercial use. Therefore, OSS can be used for any purpose, including commercial applications. Commercial suppliers often try to integrate OSS components into proprietary products. This is only permissible if the OSS components are not under a licence with copyleft effects (see also link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]). +|Open source licences generally do not distinguish between commercial and non-commercial use. Therefore, OSS can be used for any purpose, including commercial applications. Commercial suppliers often try to integrate OSS components into proprietary products. This is only permissible if the OSS components are not under a licence with copyleft effects (see also link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]). |=== [cols="1,9",options="header"] @@ -703,7 +703,7 @@ Association memberships are possible, as is informal collaboration. It is possible to delegate memberships to eOperations or similar organisations. -See also link:em002-4.adoc[Em002-4 OSS Community Guidelines], Section 3.1 +See also link:em002-4.pdf[Em002-4 OSS Community Guidelines], Section 3.1 |=== [cols="1,9",options="header"] @@ -715,25 +715,25 @@ a|ISO Standard 5230:2020 was reviewed and taken into account during the drafting *3.1 Programme foundation* -* The 'link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]' and the referenced strategies provide the framework. The respective federal departments and offices are responsible for implementation. +* The 'link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]' and the referenced strategies provide the framework. The respective federal departments and offices are responsible for implementation. *3.2 Relevant tasks defined and supported* -* The guide 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]' and the checklists define specific tasks for publication. There is currently no central body within the Federal Administration. +* The guide 'link:em002-2.pdf[Em002-2 Instructions for Publishing OSS]' and the checklists define specific tasks for publication. There is currently no central body within the Federal Administration. *3.3 Open source content review and approval* -* The publication process is described in the resource 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). -* The resource 'link:em002-3.adoc[Em002-3 OSS Licensing Guidelines]' provides comprehensive information on licensing. +* The publication process is described in the resource 'link:em002-2.pdf[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). +* The resource 'link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]' provides comprehensive information on licensing. *3.4 Compliance artifact creation and delivery* -* The publication process is described in the resource 'link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). +* The publication process is described in the resource 'link:em002-2.pdf[Em002-2 Instructions for Publishing OSS]'. This also refers to the existence of a Software Bill of Materials (SBOM). * Implementation is not described in further detail and takes place within the federal departments or offices. *3.5 Understanding open source community engagements* -* The resource 'link:em002-4.adoc[Em002-4 OSS Community Guidelines]' describes how to set up and maintain a community. A concept must be defined and implemented for each project. +* The resource 'link:em002-4.pdf[Em002-4 OSS Community Guidelines]' describes how to set up and maintain a community. A concept must be defined and implemented for each project. *3.6 Adherence to the specification requirements* @@ -796,7 +796,7 @@ Core developer:: Developer of an OSS project who has committer access rights to the repository. Market analysis:: -A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html). Possible sources of OSS software can be found in link:em002-1.adoc[Em002-1 Practical Guidelines for OSS] in Section 7. +A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html). Possible sources of OSS software can be found in link:em002-1.pdf[Em002-1 Practical Guidelines for OSS] in Section 7. OSS:: Open source software diff --git a/docs/en/em002-7.adoc b/docs/em002-7.adoc similarity index 96% rename from docs/en/em002-7.adoc rename to docs/em002-7.adoc index 6334e80..5110449 100644 --- a/docs/en/em002-7.adoc +++ b/docs/em002-7.adoc @@ -65,7 +65,7 @@ For the sustainable use of open source software, it is important that OSS is not The Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/de] requires that additional considerations be taken into account when procuring newly developed software and software development services. -To support compliance with Art. 9 EMOTA, DTI has developed tools and resources as part of link:em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] +To support compliance with Art. 9 EMOTA, DTI has developed tools and resources as part of link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] and link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] image::./assets/em002-7/media/image1.png[Overview of OSS tools] @@ -233,7 +233,7 @@ Total costs of ownership (TCO) -- covering operation, maintenance and further de The following sections focus increasingly on open source, discussing the relevant procurement approach and how it should be implemented. -The choice between consumption, contribution, collaboration and creation is made _on a project-specific basis_ according to economic efficiency and the legal situation, with costs distributed as broadly as possible. From this perspective, the four Cs as defined in link:em002.adoc[Em002 OSS Strategic Guidelines], Section 3, are ranked in descending order of importance: +The choice between consumption, contribution, collaboration and creation is made _on a project-specific basis_ according to economic efficiency and the legal situation, with costs distributed as broadly as possible. From this perspective, the four Cs as defined in link:em002.pdf[Em002 OSS Strategic Guidelines], Section 3, are ranked in descending order of importance: image::./assets/em002-7/media/image5.png[Ranking of the four Cs: Consumption, Contribution, Collaboration, Creation] @@ -290,7 +290,7 @@ A transaction falls within the scope of Art. 9 EMOTA if it falls within the rele |Procuring existing software |Buy -a|Generally no, but check whether publication requirements apply to any parts being developed. Handling of third-party rights is particularly relevant (see link:./em002-3.adoc[Em002-3 OSS Licensing Guidelines]). +a|Generally no, but check whether publication requirements apply to any parts being developed. Handling of third-party rights is particularly relevant (see link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]). |Acquiring software from other public bodies |Make or buy @@ -311,7 +311,7 @@ _Table 1: Classification of publication requirement and make-or-buy decision (ba NB: Art. 9 EMOTA must also be taken into account for existing software and SaaS where the software is to be further developed or adapted for the federal government. Even where the likelihood of this is low, it should be addressed in the procurement process. -Where clarification is needed, the recommended reference is link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software]. The checklists should be *completed provisionally as early as possible* for potentially relevant projects. The _Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL]_ may also be used for this purpose. +Where clarification is needed, the recommended reference is link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. The checklists should be *completed provisionally as early as possible* for potentially relevant projects. The _Checklist for Art. 9 EMOTA Blanket Exception [BBL-CL]_ may also be used for this purpose. === Preparing a procurement under Article 9 EMOTA @@ -322,10 +322,10 @@ In addition to the usual preparatory steps, the following two documents should b Where Art. 9 EMOTA is clearly relevant, the administrative unit should have: -* provisionally completed the checklists link:em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 OSS Preliminary Assessment Checklist] through to link:em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 OSS Release and Publication Checklist]; +* provisionally completed the checklists link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 OSS Preliminary Assessment Checklist] through to link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 OSS Release and Publication Checklist]; * taken a basic decision on whether to use a copyleft or permissive licence;footnote:[A more detailed analysis can be carried out later using _Em002-3 OSS Licensing Guidelines_ if needed).] -* searched for possible open source alternatives (or potential base projects for contributions/collaboration) in accordance with link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software], using the tools specified therein for market research/market analysis;footnote:[See also link:em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration], Section 7.] -* clarified the structure of any relevant community (link:em002-4.adoc[Em002-4 OSS Community Guidelines] and link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist]). +* searched for possible open source alternatives (or potential base projects for contributions/collaboration) in accordance with link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software], using the tools specified therein for market research/market analysis;footnote:[See also link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration], Section 7.] +* clarified the structure of any relevant community (link:em002-4.pdf[Em002-4 OSS Community Guidelines] and link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist]). Where an existing OSS project is to be used, supported or built upon through collaboration, Sections 5, 0, 8 and 9 of this document must be read. @@ -339,7 +339,7 @@ New service tenders should always include a requirement for publication in accor Building and maintaining a community maximises the benefits of open source software, but also involves considerable effort. -Where a community and collaboration make sense, this has implications for procurement from the outset. link:em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community] should therefore be completed on the basis of the link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +Where a community and collaboration make sense, this has implications for procurement from the outset. link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community] should therefore be completed on the basis of the link:em002-4.pdf[Em002-4 OSS Community Guidelines]. Where the federal authority is to take on a significant role in the community (e.g. a governance role) or where collaboration is planned (see Section 8), it may be necessary to procure additional services: community building, consolidation of requirements, management of further development. @@ -423,7 +423,7 @@ Example: eOperations Switzerland Ltd (http://www.eoperations.ch[www.eoperations. Public administration can use open source software in various ways, from simple download and installation through to formal procurement (see Section 6.2). -Where OSS is deployed in critical areas, consistently high standards of security,footnote:[See also link:em002-6.adoc[Em002-6 FAQ-OSS], Section 5.3] maintenance and further development are required. In regular software procurement, this is usually covered by the tender. The requirements apply to both the software itself and to the relevant libraries and frameworks used. Support and maintenance warrant particular attention, since further development is often covered under the same contract and in any case constitutes creation and therefore falls within the scope of Art. 9 EMOTA. +Where OSS is deployed in critical areas, consistently high standards of security,footnote:[See also link:em002-6.pdf[Em002-6 FAQ-OSS], Section 5.3] maintenance and further development are required. In regular software procurement, this is usually covered by the tender. The requirements apply to both the software itself and to the relevant libraries and frameworks used. Support and maintenance warrant particular attention, since further development is often covered under the same contract and in any case constitutes creation and therefore falls within the scope of Art. 9 EMOTA. These labour-intensive services almost always exceed the threshold value under the Public Procurement Act (PPA) when calculated over the application lifecycle. Where they are purchased from third parties, procurement law must be complied with. Exceptions may apply, such as in-state procurement from another public contracting authority,footnote:[Art. 10 para. 3 let. b PPA.] or in exceptional cases direct procurement of specialist services.footnote:[Art. 21 para. 2 let. c PPA.] @@ -553,7 +553,7 @@ The following options are currently availablefootnote:[Other, more niche options == Collaboration: Procurement law aspects of collaborative creation, maintenance and support of OSS -The costs of open source software decrease when it is developed collaboratively, whether informally or through a structured arrangement. link:em002-4.adoc[Em002-4 OSS Community Guidelines] sets out the relevant approaches. +The costs of open source software decrease when it is developed collaboratively, whether informally or through a structured arrangement. link:em002-4.pdf[Em002-4 OSS Community Guidelines] sets out the relevant approaches. Collaboration with other public contracting authorities or third parties is unproblematic under procurement law as long as each party bears its own costs. Difficulties arise where the collaboration does not result in OSS, since the Federal Administration is bound by Art. 9 EMOTA. @@ -582,7 +582,7 @@ Two special casesfootnote:[https://www.eda.admin.ch/deza/en/home/partnerschaften == Contribution: Contributing to OSS projects -Most of the characteristics and legal considerations relating to contributions are covered in link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +Most of the characteristics and legal considerations relating to contributions are covered in link:em002-4.pdf[Em002-4 OSS Community Guidelines]. From a procurement law perspective, contributions are generally unproblematic, since the services are provided to develop code for a project that is either of direct relevance to the authority or has already been addressed from a procurement law standpoint. @@ -700,7 +700,7 @@ According to the Gabler Business Dictionary, collaboration also refers to 'coope |Market analysis a|A specific market analysis is used to identify and process information on the current and potential procurement market. The purpose of the market analysis is to identify and understand market structures and, in particular, the supplier structure with regard to all relevant characteristics: price situation (high, low, fluctuations); market size; geographical distribution of potential suppliers and key players, etc. (see https://perimap.admin.ch/goto_perimap_file_38221_download.html). + -Possible sources of OSS software can be found in link:em002-1.adoc[Em002-1 Practical Guidelines for OSS] in Section 7. +Possible sources of OSS software can be found in link:em002-1.pdf[Em002-1 Practical Guidelines for OSS] in Section 7. |Product a|Used here as a synonym for 'application'. + diff --git a/docs/en/em002.adoc b/docs/em002.adoc similarity index 94% rename from docs/en/em002.adoc rename to docs/em002.adoc index ff9c428..bb41397 100644 --- a/docs/en/em002.adoc +++ b/docs/em002.adoc @@ -45,7 +45,7 @@ On 1 February 2019, these Strategic Guidelines for Open Source Software in the F === Procedure -The federal offices are responsible for implementing EMOTA themselves. However, given the growing importance of open source, it was decided to revise the practical guidelines _link:em002-1.adoc[Em002-1]_ together with all stakeholders. Furthermore, additional tools for implementing EMOTA were added. +The federal offices are responsible for implementing EMOTA themselves. However, given the growing importance of open source, it was decided to revise the practical guidelines _link:em002-1.pdf[Em002-1]_ together with all stakeholders. Furthermore, additional tools for implementing EMOTA were added. The practical guidelines define the necessary concepts, set out the constellations for using open source software, where and how alternatives to existing commercial software can be found, how open source should be procured, what business models exist for open source and what support models are possible when using open source. The other tools provide answers to frequently asked questions and guidance on releasing open source software in accordance with EMOTA. They explore all issues surrounding OSS licences and show how a community can be built around software. Several checklists for guidance and documentation are also made available to federal authorities. @@ -81,7 +81,7 @@ When *consuming* open source software, it should be treated and evaluated as equ When *developing* software, open source release is generally mandatory, subject to the exceptions set out in Art. 9 EMOTA (third-party rights and security-relevant reasons). -These exceptions are addressed in link:em002-2.adoc[Em002-2 Instructions for Publishing OSS]. +These exceptions are addressed in link:em002-2.pdf[Em002-2 Instructions for Publishing OSS]. The federal authorities, i.e. the administrative units of the Federal Administration, are themselves responsible for correct compliance; there is no centralised responsibility. @@ -91,9 +91,9 @@ In practice, release often consists of not only the source code, but also all ot In principle, the Federal Administration has no obligation to build communities; the legal mandate only requires it to publish the source code. The Federal Administration should prioritise investing in communities where the benefit for the Confederation and third parties is great and the effort is as low as possible. -Currently, there is no common federal platform for *developing and publishing source code*. Each public authority must therefore select a platform (repository) for publication itself. The practical guidelines in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and the associated checklists define how to work with a platform and which properties it must fulfil. +Currently, there is no common federal platform for *developing and publishing source code*. Each public authority must therefore select a platform (repository) for publication itself. The practical guidelines in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software] and the associated checklists define how to work with a platform and which properties it must fulfil. -The *choice of licence* is dealt with in the OSS Licensing Guidelines link:em002-3.adoc[Em002-3]), which presents a selection of standard licences and explains their uses. The Federal Administration should only use its own licence texts in justified cases according to Art. 9 para. 4 EMOTA. +The *choice of licence* is dealt with in the OSS Licensing Guidelines link:em002-3.pdf[Em002-3]), which presents a selection of standard licences and explains their uses. The Federal Administration should only use its own licence texts in justified cases according to Art. 9 para. 4 EMOTA. When using and developing OSS, *support*footnote:[At least during the lifecycle by way of contracts or a community.] must always be regulated (even if it is waived). The responsible administrative unit regulates this during the release process or when defining the community. EMOTA does not make any provisions here, and no additional financing or personnel will be made available for support. It may make sense to include support and joint further development where the benefit for Swiss authorities or the Swiss economy is considered sufficiently large (ecosystem costs) and/or cost-sharing or cooperation is sought. If the supplier takes this on, its support costs can be covered by the users. @@ -103,13 +103,13 @@ In addition, a _Software procurement and Art. 9 EMOTA information sheet_ is avai Legal and practical considerations mean that under certain circumstances the obligation to release OSS may be transferred to a supplier (during the tender or in operation). The procurement tools and the release process determine how this is to be approached with the supplier. Most of this is achieved by supplementing existing processes, contract drafts and tools. -The organisational procedure is regulated in link:em002-2.adoc[Em002-2 Instructions for Publishing Open Source Software] and the associated tools. +The organisational procedure is regulated in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software] and the associated tools. *OSS is treated equally to proprietary software under procurement law.* Since no licence fees are incurred for OSS according to the definition of the Open Source Initiative (OSI), software can be downloaded and used in principle without a tender. Only the services to be provided by companies (e.g. support, engineering) are then subject to procurement law and must be put out to tender. Where necessary, the relevant aspects from the tools are integrated into the Confederation's project management processes (i.e. HERMES). -Open development (direct open development on an openly accessible repository) and participation in existing projects (contribution) are also covered in the explanations in link:em002-4.adoc[Em002-4 OSS Community Guidelines]. +Open development (direct open development on an openly accessible repository) and participation in existing projects (contribution) are also covered in the explanations in link:em002-4.pdf[Em002-4 OSS Community Guidelines]. === Overview of OSS documents @@ -146,24 +146,24 @@ The following table illustrates how the objectives are linked to the correspondi |Objectives |Measures |*A) Compliance with legal requirements (EMOTA)* -a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + -2) Implement the _Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2]_ and the tools derived from that. + +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.pdf[Em002-1]_ + +2) Implement the _Instructions for Publishing Open Source Software link:em002-2.pdf[Em002-2]_ and the tools derived from that. + 3) Procurement authorities build up open source know-how and thus support the Federal Administration. |*B) Increase innovation and efficiency* -a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.pdf[Em002-1]_ + 3) The procurement authorities can deal with open source and optimally support Art. 9 EMOTA. + 8) Promote community building |*C) Promote a culture of collaboration* -a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.pdf[Em002-1]_ + 4) Promote knowledge and experience exchange + 8) Promote community building + 9) Examine the possibility of establishing own publication platform; promote Open Development |*D) Create clarity and minimise risks* -a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_ + -2) Implement the _Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2]_ and the tools derived from that. +a|1) Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.pdf[Em002-1]_ + +2) Implement the _Instructions for Publishing Open Source Software link:em002-2.pdf[Em002-2]_ and the tools derived from that. |*E) Create an overview to utilise synergies* a|6) Implement joint procurement of services + @@ -179,7 +179,7 @@ a|5) Promote and communicate an open source culture + [cols="20,80"] |=== -|*Measure 1:* |*Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.adoc[Em002-1]_.* +|*Measure 1:* |*Implement the _Practical Guidelines for Open Source Software in the Federal Administration link:em002-1.pdf[Em002-1]_.* 2+a| Although the term open source software is already over 20 years old, the steady spread of open source software and the continuous development of application scenarios constantly lead to new practices and questions. New and further developments of open source solutions are also increasingly forming full-fledged alternatives to proprietary software. With EMOTA, the obligation to publish in-house developments is added. @@ -188,9 +188,9 @@ The _Practical Guidelines for Open Source Software in the Federal Administration These practical guidelines and the other tools should be used and implemented by the federal authorities when dealing with open source software and releases. -As a brief introduction to the topic, an _information sheet on the application of Art. 9 EMOTA_ and link:em002-6.adoc[EM002-6 FAQ about Publishing OSS (OSS-FAQ)] are available. +As a brief introduction to the topic, an _information sheet on the application of Art. 9 EMOTA_ and link:em002-6.pdf[EM002-6 FAQ about Publishing OSS (OSS-FAQ)] are available. -|*Measure 2:* |*Implement the Instructions for Publishing Open Source Software link:em002-2.adoc[Em002-2] and the tools derived from that.* +|*Measure 2:* |*Implement the Instructions for Publishing Open Source Software link:em002-2.pdf[Em002-2] and the tools derived from that.* 2+a| The efficient use of OSS in software development often requires contributions in the form of bug fixes and functional enhancements. With EMOTA, there is also an obligation to release self-created software. The necessary guidance is available with various tools. @@ -206,7 +206,7 @@ To facilitate the application of Art. 9 EMOTA, additions will be made to the Con |*Measure 3:* |*Procurement authorities build up open source know-how and thus support the Federal Administration.* 2+a| -The new link:em002-7.adoc[Em002-7 Strategic Aspects of Procurement and OSS] was created to address procurement aspects. +The new link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and OSS] was created to address procurement aspects. To ensure broad competition, procurement requires that open and closed source software be treated equally. The increased requirements in connection with Art. 9 EMOTA regarding the resources to be procured for software publication must be taken into account. @@ -233,7 +233,7 @@ In order to be perceived by the public as an 'open source-friendly' employer, th 2+a| Maintenance and support of open source software is currently provided by internal employees of the Federal Administration, while external suppliers offer services for certain open source solutions. These services are often procured independently by the respective offices, which can lead to duplication and the associated financial losses. -The joint procurement of services for open source software should increase the reliability of maintenance and support in operation and simplify the use of open source solutions. Based on the technology radar (see Measure 5), services for the most widespread open source systems and technologies should be centrally procured. These services can then be obtained by all offices as needed.footnote:[This concerns support for the software in use. Third party support for software released under EMOTA is possible and may be charged for. This is covered in link:em002-4.adoc[Em002-4 OSS Community Guidelines.]] +The joint procurement of services for open source software should increase the reliability of maintenance and support in operation and simplify the use of open source solutions. Based on the technology radar (see Measure 5), services for the most widespread open source systems and technologies should be centrally procured. These services can then be obtained by all offices as needed.footnote:[This concerns support for the software in use. Third party support for software released under EMOTA is possible and may be charged for. This is covered in link:em002-4.pdf[Em002-4 OSS Community Guidelines.]] |*Measure 7:* |*Create an overview of open source software used, released and co-developed.* @@ -265,13 +265,13 @@ Federal cooperation across all authorities in Switzerland (similar to opencode.d * Minor editorial changes and improvements. * Factsheet Em002-5 has been replaced by the OSS tools information sheet'. -* A new addition is the document '`link:em002-7.adoc[Em002-7 Procurement and OSS]`'. +* A new addition is the document '`link:em002-7.pdf[Em002-7 Procurement and OSS]`'. * New diagram depicting the 4 Cs in the context of OSS (addition of 'collaboration'). * New FOBL and CCPP references. === References for OSS tools -The following reference table lists the documents relating to the document set for link:em002.adoc[Em002 Tools for Open Source Software] in the Federal Administration. +The following reference table lists the documents relating to the document set for link:em002.pdf[Em002 Tools for Open Source Software] in the Federal Administration. [cols="1"] |=== @@ -406,7 +406,7 @@ Intranet: link:https://intranet.dti.bk.admin.ch/isb_kp/de/home/ikt-vorgaben/stan === Abbreviations -This list of abbreviations contains all the abbreviations used in the OSS Em002 document set. A glossary can be found in link:em002-6.adoc[Em002-6 FAQ about Publishing OSS]. +This list of abbreviations contains all the abbreviations used in the OSS Em002 document set. A glossary can be found in link:em002-6.pdf[Em002-6 FAQ about Publishing OSS]. [options="header",cols="20,80"] |=== diff --git a/docs/index_en.adoc b/docs/index.adoc similarity index 67% rename from docs/index_en.adoc rename to docs/index.adoc index b097618..ab28f2c 100644 --- a/docs/index_en.adoc +++ b/docs/index.adoc @@ -33,29 +33,29 @@ The individual agencies are responsible for implementation. The Federal Chancell The following tools are available in the form of guidelines, instructions, checklists, fact sheets, and FAQs: -link:en/em002.adoc[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] (05.05.2026) +link:em002.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration] (05.05.2026) -link:en/em002-1.adoc[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] (05.05.2026) +link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] (05.05.2026) -link:en/em002-2.adoc[Em002-2 Instructions for Publishing OSS] (05.05.2026) +link:em002-2.pdf[Em002-2 Instructions for Publishing OSS] (05.05.2026) -link:en/em002-2-1-checklist-oss-preliminary-assessment.adoc[Em002-2.1 Preliminary Assessment Checklist] (ODT, 05.05.2026) +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Preliminary Assessment Checklist] (ODT, 05.05.2026) -link:en/em002-2-2-checklist-oss-analysis-and-preparation.adoc[Em002-2.2 Analysis and Preparation Checklist] (ODT, 92 kB, 05.05.2026) +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Analysis and Preparation Checklist] (ODT, 92 kB, 05.05.2026) -link:en/em002-2-3-checklist-oss-release-and-publication.adoc[Em002-2.3 Release and Publication Checklist] (ODT, 93 kB, 05.05.2026) +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Release and Publication Checklist] (ODT, 93 kB, 05.05.2026) -link:en/em002-3.adoc[Em002-3 OSS Licensing Guidelines] (05.05.2026) +link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] (05.05.2026) -link:en/em002-4.adoc[Em002-4 OSS Community Guidelines] (05.05.2026) +link:em002-4.pdf[Em002-4 OSS Community Guidelines] (05.05.2026) -link:en/em002-4-1-checklist-oss-community.adoc[Em002-4.1 OSS Community Checklist] (ODT, 94 kB, 05.05.2026) +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] (ODT, 94 kB, 05.05.2026) -link:en/em002-5.adoc[Em002-5 EMOTA and OSS Factsheet] (06.05.2026) +link:em002-5.pdf[Em002-5 EMOTA and OSS Factsheet] (06.05.2026) -link:en/em002-6.adoc[Em002-6 FAQ on OSS and Art. 9 EMOTA] (05.05.2026) +link:em002-6.pdf[Em002-6 FAQ on OSS and Art. 9 EMOTA] (05.05.2026) -link:en/em002-7.adoc[Em002-7 OSS Guideline: Applying Article 9 of Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA)] (05.05.2026) +link:em002-7.pdf[Em002-7 OSS Guideline: Applying Article 9 of Federal Act on the Use of Electronic Means for Fulfilling Administrative Tasks (EMOTA)] (05.05.2026) https://www.bk.admin.ch/dam/bk/de/dokumente/dti/OSS/oss_merkblatt_kbb_beschaffung_artikel9_embag.pdf.download.pdf/Merkblatt_KBB_Beschaffung-Software-Art9-EMBAG_de.pdf[Merkblatt KBB Beschaffung Software Artikel 9 EMBAG] (PDF, 177 kB, 13.08.2025) only available in German, French and Italian diff --git a/publiccode.yml b/publiccode.yml index 7ee0694..0a6d15e 100644 --- a/publiccode.yml +++ b/publiccode.yml @@ -46,7 +46,7 @@ description: - Documentation - Open Source Knowledge screenshots: - - https://github.com/swiss/opensource-guidelines/blob/e173972f2119e46d38e017064544d179e69805eb/docs/en/assets/em002-1/media/image1.png + - https://github.com/swiss/opensource-guidelines/blob/main/docs/assets/em002-1/media/image1.png legal: license: CC0-1.0 maintenance: @@ -60,4 +60,5 @@ localisation: - de-CH - fr-CH - it-CH + - rm-CH - en From 3e36c98ea280fb9977f2aa5252e203cd7f33af36 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Tue, 15 Sep 2026 13:22:45 +0200 Subject: [PATCH 07/58] Carry all five languages in em002-5.adoc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proves the mechanism the remaining documents will follow. `ifeval::` on {lang} selects one body block of five; `open-govpress render --lang` pins {lang} as a locked API attribute, so it outranks the document's own :lang: and drives the guards. Verified: five 7-page PDFs, each with its own title, TOC heading and admonition labels, and no leaked markup. `:lang: en` moves to line 1, above the title. Attribute entries may precede a doctitle, and this one has to: without it nothing defines {lang} before the conditional title is read, so "auto" mode -- GitHub's .adoc preview, the desktop app, a bare asciidoctor run -- would produce a document with no title at all. The four :title-logo-base:/-line1/-line2/-line3 attributes are deleted rather than translated. Their presence is precisely what suppresses open-govpress's own localisation (sniffStatesLogo), which is why the title page read "Federal Chancellery FCh" in all five languages before and now reads Departement/Amt, Département/Office, Dipartimento/Ufficio and Departament/Uffizi. Note this trades the FCh naming for the tool's generic placeholder; restoring it means putting that one string back into the per-language chain by hand. Co-Authored-By: Claude Opus 5 (1M context) --- TRANSLATING.md | 124 +++++ docs/em002-5.adoc | 1304 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 1422 insertions(+), 6 deletions(-) create mode 100644 TRANSLATING.md diff --git a/TRANSLATING.md b/TRANSLATING.md new file mode 100644 index 0000000..68a6936 --- /dev/null +++ b/TRANSLATING.md @@ -0,0 +1,124 @@ +# Translating these guidelines + +Every document in `docs/` carries **all five languages in one `.adoc` file**. +There is no per-language copy of a file and no per-language directory — those +were removed on purpose, because five copies of a document drift apart the first +time someone fixes a typo in only one of them. + +## How a document is structured + +```asciidoc +:lang: en <1> +ifeval::["{lang}" == "en"] += Em002-5 EMOTA and OSS Factsheet <2> +endif::[] +ifeval::["{lang}" == "de"] += Em002-5 Merkblatt EMBAG und OSS +endif::[] +…fr, it, rm… +:govpress-style: report <3> +:toc: +… + +ifeval::["{lang}" == "en"] <4> +…the whole English body… +endif::[] + +ifeval::["{lang}" == "de"] +…the whole German body… +endif::[] + +…fr, it, rm… +``` + +1. **Must stay the first line.** It is the default language when nobody pins + one, which is what GitHub's `.adoc` preview and the open-govpress desktop app + use. Without it the `ifeval::` guards have no `{lang}` to compare against and + the document renders empty. +2. Only the **title** is per-language in the header. +3. Every other attribute is shared, written once, after the title chain. +4. The body is five blocks, always in the order `en, de, fr, it, rm`. + +Language codes are the bare subtags `en de fr it rm` — never `de-CH`. The tool +reduces `de-CH` to `de` when it looks up captions, but `{lang}` would still hold +the literal `de-CH` and no `ifeval::` would ever match. + +### What you must not localise by hand + +The **Kennzeichnung** on the title page (`Departement` / `Amt` and its +equivalents) and every caption, TOC heading and admonition label are localised +by open-govpress from the active language. Do not add `:title-logo-base:` or +`:title-logo-line1:`/`line2:`/`line3:` to a document — their mere *presence* +switches the automatic localisation off and pins whatever language they were +written in across all five outputs. + +## Building + +```sh +render-docs # all five languages into build/ +render-docs de rm # just those two +``` + +Check a single document while translating it: + +```sh +for l in en de fr it rm; do + open-govpress render --lang "$l" -o "build/$l" docs/em002-5.adoc +done +``` + +A near-empty PDF means that language's body block is missing or its `endif::[]` +is malformed. A PDF where all five languages show the same Kennzeichnung means a +`title-logo-*` attribute crept back in. + +## Terminology + +| en | de | fr | it | rm | +|---|---|---|---|---| +| EMOTA | EMBAG | LMETA | LMeCA | EMBAG | +| Federal Chancellery FCh | Bundeskanzlei BK | Chancellerie fédérale ChF | Cancelleria federale CaF | Chanzlia federala ChF | +| FOBL | BBL | OFCL | UFCL | UFCL | +| CCPP | KBB | CCMP | CCAP | CCA | +| FITSU | ISB | USIC | ODIC | ISB | +| DTI sector | Sektor DTI | secteur TNI | settore TDI | sectur TDI | +| open source software (OSS) | Open-Source-Software (OSS) | logiciel open source (OSS) | software open source (OSS) | software open source (OSS) | +| checklist | Checkliste | liste de contrôle | lista di controllo | glista da controlla | +| guidelines (Em002-3/-4) | Leitfaden | guide | guida | guida | +| practical guidelines (Em002-1) | Praxisleitfaden | guide pratique | guida pratica | guida pratica | +| instructions (Em002-2) | Anleitung | instructions | istruzioni | instrucziuns | +| information sheet / factsheet | Merkblatt | aide-mémoire | promemoria | fegl d'infurmaziun | +| administrative unit (OU) | Organisationseinheit (OE) | unité d'organisation (UO) | unità organizzativa (UO) | unitad d'organisaziun (UO) | + +**Romansh (Rumantsch Grischun) is the weakest link.** `EMBAG` is used as the +short title because it is the abbreviation Romansh federal texts cite; if +Fedlex publishes a Romansh abbreviation for SR 172.019, use that instead. The +Romansh text in this repository has not been reviewed by a Romansh speaker. + +## Rules + +- **Preserve every AsciiDoc construct exactly.** `footnote:[SR 172.019]`, + `image::` macros, `|===` table delimiters and cell counts, `a|` cell prefixes, + `* [ ]` checklist items (they render as interactive checkboxes), inline roles + such as `[.underline]#…#`, `'''` rules, `+` line breaks. +- **Translate image alt text**, but not image paths — all five languages share + `docs/assets/`. +- **Translate `link:…[display text]`, never the target.** Targets are `.pdf` + because the links are followed inside the rendered PDFs, where the documents + sit side by side in one language directory. +- **Switch the language segment of admin.ch and fedlex.admin.ch URLs** to match + (`…/2023/682/en#art_9` → `…/2023/682/de#art_9`). Leave a URL alone when only + one language of it exists — several `beschaffung.admin.ch` links are + German-only and are cited as such in the English source too. +- **Keep abbreviations that the English source keeps**, such as `ISBO / DSBO` + and `Application Manager`. +- Section numbering is generated (`:sectnums:`), so cross-references that name a + section number stay valid in every language as long as the section structure + is identical. Keep the same headings in the same order in all five blocks. + +## Status + +The German, French, Italian and Romansh texts are **unreviewed machine +translation**. The binding versions of these documents are the ones published in +the official languages on the Federal Chancellery website. An FCh translation +review is required before the non-English versions here are treated as anything +more than drafts. diff --git a/docs/em002-5.adoc b/docs/em002-5.adoc index 34b278a..70f7c68 100644 --- a/docs/em002-5.adoc +++ b/docs/em002-5.adoc @@ -1,13 +1,23 @@ -= Em002-5 EMOTA and OSS Factsheet :lang: en +ifeval::["{lang}" == "en"] += Em002-5 EMOTA and OSS Factsheet +endif::[] +ifeval::["{lang}" == "de"] += Em002-5 Merkblatt EMBAG und OSS +endif::[] +ifeval::["{lang}" == "fr"] += Em002-5 Aide-mémoire LMETA et OSS +endif::[] +ifeval::["{lang}" == "it"] += Em002-5 Promemoria LMeCA e OSS +endif::[] +ifeval::["{lang}" == "rm"] += Em002-5 Fegl d'infurmaziun EMBAG ed OSS +endif::[] :govpress-style: report :govpress-front-block: report :classification: :title-logo: logo-ch-black.svg -:title-logo-base: black -:title-logo-line1: Federal Chancellery FCh -:title-logo-line2: Office -:title-logo-line3: :title-page: :pdf-theme: basic :toc: @@ -19,6 +29,7 @@ :revdate: 14.09.2026 :url-repo: https://github.com/swiss/opensource-guidelines/tree/main +ifeval::["{lang}" == "en"] [IMPORTANT] ==== This document is an evolving draft and part of the guidelines and tools designed to support the Federal Administration in publishing open source code. For more information, see the main https://github.com/swiss/opensource-guidelines/tree/main[README]. @@ -86,7 +97,7 @@ Each federal authority (e.g. office, administrative unit) that develops or commi image::./assets/em002-5/media/image2.png[Overview of OSS tools and resources,600] The tools and resources are available on the Federal Chancellery website -under https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[OSS tools]. They are also https://github.com/swiss/opensource-guidelines/tree/main/docs/en[published in English on GitHub] where you can give feedback directly. The OSS Catalogue (opensource.admin.ch) provides an overview of software published by the federal authorities. For enquiries please contact: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. +under https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[OSS tools]. They are also https://github.com/swiss/opensource-guidelines/tree/main/docs[published on GitHub] where you can give feedback directly. The OSS Catalogue (opensource.admin.ch) provides an overview of software published by the federal authorities. For enquiries please contact: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. == Target groups of the various OSS tools @@ -336,3 +347,1284 @@ Glossary: * Bold = Proposal of the responsible body in an OU (may be regulated differently) * Numbers and capital letters: relevant sections and annexes. If none are specified, the entire document is relevant. * Responsibility for the documents: FCh/DTI (yellow), CCPP and FOBL (blue) +endif::[] + +ifeval::["{lang}" == "de"] +[IMPORTANT] +==== +Dieses Dokument ist ein laufend weiterentwickelter Entwurf und Teil der Hilfsmittel, welche die Bundesverwaltung bei der Veröffentlichung von Open-Source-Code unterstützen. Weitere Informationen finden Sie im https://github.com/swiss/opensource-guidelines/tree/main[README]. +==== + +''' + +== Merkblatt: Anwendung von OSS Artikel 9 EMBAG + +Das neue https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG)] ist am 1. Januar 2024 in Kraft getreten. Es verpflichtet die Bundesbehörden, den Quellcode von Software offenzulegen, die sie entwickeln oder entwickeln lassen. Ausnahmen bestehen, wenn Rechte Dritter oder sicherheitsrelevante Gründe die Veröffentlichung ausschliessen oder einschränken. + +image::./assets/em002-5/media/image1.png[Übersichtsgrafik zum Prozess OSS Artikel 9 EMBAG,600] + +Dieses Dokument richtet sich an [.underline]#Projektleiterinnen und Projektleiter# sowie an weitere [.underline]#für die Beschaffung von Software verantwortliche Personen#. + +== Einleitende Fragen: + +Beschafft oder nutzt die Bundesbehörde Standardsoftware ohne Anpassungen? +Wenn ja, siehe a) + +oder + +Muss eine Softwareanwendung oder -komponente eigens für den Bund entwickelt werden (Individualsoftware = make)? +Wenn ja, siehe b) + +=== a) Beschaffung und Nutzung von Standardsoftware + +Kauft der Bund Software ohne Anpassungen, so ist Artikel 9 EMBAG nicht anwendbar. Jede Bundesbehörde entscheidet frei, ob sie Open-Source-Software oder andere Software beschafft und einsetzt. +Unterstützung bei der Beschaffung von Software bietet die Website des https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Bundesamts für Bauten und Logistik (BBL)] sowie das https://perimap.admin.ch/goto_perimap_file_46835_download.html[Merkblatt zur Softwarebeschaffung und Art. 9 EMBAG] der KBB. Bei Bedarf kann zusätzlich link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und OSS] beigezogen werden. + +=== b) Erstellung oder Weiterentwicklung von Software + +Entwickelt eine Bundesbehörde Software selbst oder durch Dritte, so ist OSS Artikel 9 EMBAG anzuwenden. Dazu zählt auch Software, die im Rahmen eines Beitrags an bestehende OSS-Projekte weiterentwickelt wird. Auf die Veröffentlichung des Quellcodes kann nur mit Blick auf Rechte Dritter oder aus sicherheitsrelevanten Gründen verzichtet werden. Bitte füllen Sie die link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] aus. + +NOTE: Diese Checkliste dient auch als Begründung dafür, weshalb Software [.underline]#nicht# veröffentlicht werden muss. Sie sollte deshalb möglichst früh im Projekt beigezogen werden. Die Anleitung link:em002-2.pdf[Em002-2] beschreibt den gesamten Prozess. + +Weitere zu klärende Fragen sind: + +=== Unter welcher Open-Source-Lizenz wird veröffentlicht? + +Zu beantworten ist die Grundsatzfrage, ob die Software unter einer [.underline]#Copyleft#-Lizenz (dann ist beispielsweise die AGPL V3 eine gute Wahl) oder [.underline]#permissiv# (dann beispielsweise unter einer MIT-Lizenz) veröffentlicht wird. Zur Lizenzwahl gibt der link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] ausführlich Auskunft. Bitte füllen Sie die link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] aus. + +NOTE: Idealerweise wird dies durch die (technische) Projektleitung oder die IT-Architektin bzw. den IT-Architekten ausgefüllt. + +=== Wo und wie sollen die Software und die zugehörigen Artefakte veröffentlicht werden? + +Bitte füllen Sie die link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] aus. + +NOTE: Es handelt sich um eine gesamthafte Erfassung, wo und wie Software veröffentlicht wird. Unter Umständen sind weitere Organisationen einzubeziehen. + +=== Soll eine OSS-Community aufgebaut werden? + +Der link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] beschreibt die Vorteile und die Aufgaben beim Aufbau einer OSS-Community auf der Grundlage eines Konzepts. + +[.underline]#Wenn ja#: Füllen Sie die link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] aus, die Auskunft über die gewünschte Art und Plattform der Community gibt. + +NOTE: Das Projektteam hat hier grossen Spielraum, ob und welche Art von Community aufgebaut werden soll. Unter Umständen sind weitere Stellen einzubeziehen. + +Beantworten Sie diese Fragen und prüfen Sie regelmässig (rund einmal jährlich), ob sich wesentliche Änderungen ergeben haben. + +Jede Bundesbehörde (z. B. Amt, Verwaltungseinheit), die Software entwickelt oder entwickeln lässt, ist eigenständig für den gesamten Veröffentlichungsprozess verantwortlich. + +== Übersicht über die Hilfsmittel + +image::./assets/em002-5/media/image2.png[Übersicht über die OSS-Hilfsmittel,600] + +Die Hilfsmittel stehen auf der Website der Bundeskanzlei +unter https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[OSS-Hilfsmittel] zur Verfügung. Sie sind zudem https://github.com/swiss/opensource-guidelines/tree/main/docs[auf GitHub veröffentlicht], wo Sie direkt Rückmeldungen geben können. Der OSS-Katalog (opensource.admin.ch) gibt einen Überblick über die von den Bundesbehörden veröffentlichte Software. Für Anfragen wenden Sie sich an: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. + +== Zielgruppen der verschiedenen OSS-Hilfsmittel + +Die OSS-Hilfsmittel richten sich an unterschiedliche Zielgruppen. Die folgende Tabelle enthält eine Empfehlung, welche Dokumente für welche Zielgruppe relevant sind. + +.OSS-Hilfsmittel nach Zielgruppe +[options="header",cols="3,1,1,1,1,1,1,1,1,1"] +|=== +|Dokument \ Zielgruppe |Geschäftsleitung |IT-Leitung (a) |ISBO / DSBO (a) |Application Manager |Projektleitung |Rechtsdienst |Beschaffung |Entwicklung |Kommunikation + +|Em002 Strategische Leitlinien +a|X + +3,4,5 +a|*X* + +2-5 + +Anhang B, C +a|X + +2-5 + +Anhang B, C +| +a|(X) + +5 + +Anhang B +| +| +| +|(X) + +|Em002-1 Praxisleitfaden +|X +|*X* +|*X* +|*X* +|X +| +| +| +| + +|Em002-2 Anleitung zur Veröffentlichung von OSS +| +a|(X) + +1,3,5 +a|X + +1,3 5 +a|(X) + +1,3,5 +a|*(X)* + +3,5 +| +| +a|X + +1-5 +| + +|Em002-2.1 Checkliste OSS-Vorabklärung +| +a|*(X)* + +(c) +a|*X* + +(b), (c) +a|X + +(b) +a|X + +(b) +| +| +| +| + +|Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung +| +| +a|*X* + +*(c)* +a|*X* + +*(c)* +a|*X* + +*(c)* +| +| +a|X + +(b) +| + +|Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung +| +| +a|*X* + +(c) +a|*X* + +(c) +| +| +| +a|X + +(b) +a|X + +(d) + +|Em002-3 Leitfaden OSS-Lizenzierung +| +|*(X)* +|*(X)* +| +| +|*X* +a|(X) + +8 +|(X) +| + +|Em002-4 Leitfaden OSS-Community +a|(X) + +3 +a|X + +3,5 +a|X + +4,5 +|*X* +| +| +| +|(X) +|X + +|Em002-4.1 Checkliste OSS-Community +| +a|*(X)* + +(c) +a|*(X)* + +(c) +a|(X) + +(d) +a|X + +(b) +a|(X) + +(d) +| +| +a|(X) + +(d) + +|Em002-5 Merkblatt OSS-Hilfsmittel (e) +|X +|X +|X +|X +|X +|X +|X +|X +|X + +|Em002-6 FAQ zu OSS (e) +|(X) +|(X) +|(X) +|X +| +|X +|(X) +|(X) +|(X) + +|Em002-7 Strategische Aspekte der Beschaffung und OSS +| +|*(X)* +|*(X)* +| +|(X) +|X +|X +| +| + +|Merkblatt KBB +|X +|*X* +|*X* +|X +|(X) +|X +|X +| +| + +|Weisung BBL +| +| +| +|*(X)* +|*(X)* +| +|X +| +| + +|Checkliste BBL für Pauschalausnahme +| +|*(X)* +| +|(X) +|(X) +| +|X +| +| +|=== + +Legende: + +* X -- Zielgruppe, (X) -- bei Interesse/Bedarf, mindestens Management Summary +* (a) für Art. 9 EMBAG verantwortliche Person in der OE. Kann die IT-Leitung sein oder delegiert werden +* (b) ausfüllen +* (c) genehmigen +* (d) konsultieren +* (e) primär zur Information und als Nachschlagewerk +* Fett = Vorschlag der verantwortlichen Stelle in einer OE (kann anders geregelt werden) +* Zahlen und Grossbuchstaben: massgebende Kapitel und Anhänge. Sind keine angegeben, ist das gesamte Dokument relevant. +* Verantwortung für die Dokumente: BK/DTI (gelb), KBB und BBL (blau) +endif::[] + +ifeval::["{lang}" == "fr"] +[IMPORTANT] +==== +Le présent document est un projet en cours d'élaboration et fait partie des outils destinés à soutenir l'administration fédérale dans la publication de code open source. Pour de plus amples informations, voir le https://github.com/swiss/opensource-guidelines/tree/main[README] principal. +==== + +''' + +== Aide-mémoire : application de l'OSS article 9 LMETA + +La nouvelle https://www.fedlex.admin.ch/eli/cc/2023/682/fr#art_9[loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA)] est entrée en vigueur le 1^er^ janvier 2024. Elle oblige les autorités fédérales à publier le code source des logiciels qu'elles développent ou font développer. Des exceptions sont prévues lorsque des droits de tiers ou des motifs relevant de la sécurité excluent ou restreignent la publication. + +image::./assets/em002-5/media/image1.png[Schéma du processus OSS article 9 LMETA,600] + +Le présent document s'adresse aux [.underline]#cheffes et chefs de projet# ainsi qu'aux autres [.underline]#personnes responsables de l'acquisition de logiciels#. + +== Questions préliminaires : + +L'autorité fédérale acquiert-elle ou utilise-t-elle un logiciel standard sans adaptation ? +Si oui, voir a) + +ou + +Une application ou un composant logiciel doit-il être développé spécifiquement pour la Confédération (logiciel sur mesure = make) ? +Si oui, voir b) + +=== a) Acquisition et utilisation de logiciels standard + +Lorsque la Confédération achète un logiciel sans adaptation, l'article 9 LMETA ne s'applique pas. Chaque autorité fédérale est libre de décider si elle acquiert et utilise un logiciel open source ou un autre logiciel. +Une aide à l'acquisition de logiciels est disponible sur le site de l'https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Office fédéral des constructions et de la logistique (OFCL)] ainsi que dans l'https://perimap.admin.ch/goto_perimap_file_46835_download.html[aide-mémoire sur l'acquisition de logiciels et l'art. 9 LMETA] du CCMP. Au besoin, le document link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et OSS] peut également être consulté. + +=== b) Création ou développement de logiciels + +Lorsqu'une autorité fédérale développe un logiciel elle-même ou par l'intermédiaire de tiers, l'OSS article 9 LMETA doit être appliqué. Cela vaut également pour les logiciels développés dans le cadre d'une contribution à des projets OSS existants. Il n'est possible de renoncer à la publication du code source qu'en raison de droits de tiers ou pour des motifs relevant de la sécurité. Veuillez remplir la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable OSS]. + +NOTE: Cette liste de contrôle sert également à justifier pourquoi un logiciel [.underline]#ne doit pas# être publié. Il convient donc de la consulter le plus tôt possible dans le projet. Le guide link:em002-2.pdf[Em002-2] décrit l'ensemble du processus. + +Les autres questions à clarifier sont les suivantes : + +=== Sous quelle licence open source la publication a-t-elle lieu ? + +Il faut répondre à la question de principe de savoir si le logiciel est publié sous une licence [.underline]#copyleft# (l'AGPL V3 est alors un bon choix, par exemple) ou de manière [.underline]#permissive# (par exemple sous licence MIT). Le link:em002-3.pdf[Em002-3 Guide de licences OSS] fournit des informations détaillées sur le choix de la licence. Veuillez remplir la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[liste de contrôle Em002-2.2 Analyse et préparation OSS]. + +NOTE: Idéalement, cette liste est remplie par la direction (technique) du projet ou par l'architecte informatique. + +=== Où et comment le logiciel et les artefacts associés doivent-ils être publiés ? + +Veuillez remplir la link:em002-2-3-checklist-oss-release-and-publication.pdf[liste de contrôle Em002-2.3 Validation et publication OSS]. + +NOTE: Il s'agit d'un relevé global indiquant où et comment un logiciel est publié. Il peut être nécessaire d'associer d'autres organisations. + +=== Faut-il constituer une communauté OSS ? + +Le link:em002-4.pdf[Em002-4 Guide des communautés OSS] décrit les avantages et les tâches liés à la constitution d'une communauté OSS sur la base d'un concept. + +[.underline]#Si oui# : remplissez la link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS], qui renseigne sur le type et la plateforme souhaités pour la communauté. + +NOTE: L'équipe de projet dispose ici d'une grande marge de manœuvre quant à la question de savoir si une communauté doit être constituée et de quel type. Il peut être nécessaire d'associer d'autres services. + +Répondez à ces questions et vérifiez régulièrement (environ une fois par an) si des changements importants sont intervenus. + +Chaque autorité fédérale (p. ex. office, unité administrative) qui développe ou fait développer un logiciel est responsable de manière autonome de l'ensemble du processus de publication. + +== Vue d'ensemble des outils et ressources + +image::./assets/em002-5/media/image2.png[Vue d'ensemble des outils OSS,600] + +Les outils et ressources sont disponibles sur le site de la Chancellerie fédérale +sous https://www.bk.admin.ch/bk/fr/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[outils OSS]. Ils sont également https://github.com/swiss/opensource-guidelines/tree/main/docs[publiés sur GitHub], où vous pouvez donner directement votre avis. Le catalogue OSS (opensource.admin.ch) donne une vue d'ensemble des logiciels publiés par les autorités fédérales. Pour toute question, veuillez vous adresser à : mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. + +== Groupes cibles des différents outils OSS + +Les outils et ressources OSS s'adressent à différents groupes cibles. Le tableau suivant recommande quels documents sont pertinents pour quel groupe cible. + +.Outils et ressources OSS par groupe cible +[options="header",cols="3,1,1,1,1,1,1,1,1,1"] +|=== +|Document \ Groupe cible |Direction |Direction informatique (a) |ISBO / DSBO (a) |Application Manager |Direction de projet |Service juridique |Achats |Développement |Communication + +|Em002 Lignes directrices stratégiques +a|X + +3,4,5 +a|*X* + +2-5 + +Annexes B, C +a|X + +2-5 + +Annexes B, C +| +a|(X) + +5 + +Annexe B +| +| +| +|(X) + +|Em002-1 Guide pratique +|X +|*X* +|*X* +|*X* +|X +| +| +| +| + +|Em002-2 Instructions pour la publication d'OSS +| +a|(X) + +1,3,5 +a|X + +1,3 5 +a|(X) + +1,3,5 +a|*(X)* + +3,5 +| +| +a|X + +1-5 +| + +|Em002-2.1 Liste de contrôle Évaluation préalable OSS +| +a|*(X)* + +(c) +a|*X* + +(b), (c) +a|X + +(b) +a|X + +(b) +| +| +| +| + +|Em002-2.2 Liste de contrôle Analyse et préparation OSS +| +| +a|*X* + +*(c)* +a|*X* + +*(c)* +a|*X* + +*(c)* +| +| +a|X + +(b) +| + +|Em002-2.3 Liste de contrôle Validation et publication OSS +| +| +a|*X* + +(c) +a|*X* + +(c) +| +| +| +a|X + +(b) +a|X + +(d) + +|Em002-3 Guide de licences OSS +| +|*(X)* +|*(X)* +| +| +|*X* +a|(X) + +8 +|(X) +| + +|Em002-4 Guide des communautés OSS +a|(X) + +3 +a|X + +3,5 +a|X + +4,5 +|*X* +| +| +| +|(X) +|X + +|Em002-4.1 Liste de contrôle Communauté OSS +| +a|*(X)* + +(c) +a|*(X)* + +(c) +a|(X) + +(d) +a|X + +(b) +a|(X) + +(d) +| +| +a|(X) + +(d) + +|Em002-5 Aide-mémoire Outils OSS (e) +|X +|X +|X +|X +|X +|X +|X +|X +|X + +|Em002-6 FAQ sur l'OSS (e) +|(X) +|(X) +|(X) +|X +| +|X +|(X) +|(X) +|(X) + +|Em002-7 Aspects stratégiques des achats et OSS +| +|*(X)* +|*(X)* +| +|(X) +|X +|X +| +| + +|Aide-mémoire CCMP +|X +|*X* +|*X* +|X +|(X) +|X +|X +| +| + +|Directives OFCL +| +| +| +|*(X)* +|*(X)* +| +|X +| +| + +|Liste de contrôle OFCL pour exception forfaitaire +| +|*(X)* +| +|(X) +|(X) +| +|X +| +| +|=== + +Légende : + +* X -- groupe cible, (X) -- en cas d'intérêt ou de besoin, au moins le résumé à l'intention de la direction +* (a) personne responsable de l'art. 9 LMETA au sein de l'UO. Il peut s'agir de la direction informatique ou d'une personne déléguée +* (b) à remplir +* (c) à approuver +* (d) à consulter +* (e) principalement à titre d'information et de référence +* Gras = proposition de l'unité responsable au sein d'une UO (peut être réglé différemment) +* Chiffres et lettres majuscules : chapitres et annexes déterminants. Si rien n'est indiqué, l'ensemble du document est pertinent. +* Responsabilité des documents : ChF/TNI (jaune), CCMP et OFCL (bleu) +endif::[] + +ifeval::["{lang}" == "it"] +[IMPORTANT] +==== +Il presente documento è una bozza in continua evoluzione e fa parte degli strumenti destinati a sostenere l'Amministrazione federale nella pubblicazione di codice open source. Per maggiori informazioni si veda il https://github.com/swiss/opensource-guidelines/tree/main[README] principale. +==== + +''' + +== Promemoria: applicazione dell'OSS articolo 9 LMeCA + +La nuova https://www.fedlex.admin.ch/eli/cc/2023/682/it#art_9[legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA)] è entrata in vigore il 1° gennaio 2024. Essa obbliga le autorità federali a pubblicare il codice sorgente del software che sviluppano o fanno sviluppare. Sono previste eccezioni se diritti di terzi o motivi rilevanti per la sicurezza escludono o limitano la pubblicazione. + +image::./assets/em002-5/media/image1.png[Grafico riassuntivo del processo OSS articolo 9 LMeCA,600] + +Il presente documento si rivolge ai [.underline]#capiprogetto# e alle altre [.underline]#persone responsabili dell'acquisto di software#. + +== Domande introduttive: + +L'autorità federale acquista o utilizza software standard senza adattamenti? +In caso affermativo, vedi a) + +oppure + +Un'applicazione o un componente software deve essere sviluppato appositamente per la Confederazione (software su misura = make)? +In caso affermativo, vedi b) + +=== a) Acquisto e utilizzo di software standard + +Se la Confederazione acquista software senza adattamenti, l'articolo 9 LMeCA non si applica. Ogni autorità federale decide liberamente se acquistare e utilizzare software open source o altro software. +Un supporto per l'acquisto di software è disponibile sul sito dell'https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Ufficio federale delle costruzioni e della logistica (UFCL)] e nel https://perimap.admin.ch/goto_perimap_file_46835_download.html[promemoria sull'acquisto di software e l'art. 9 LMeCA] del CCAP. Se necessario, può essere consultato anche il documento link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e OSS]. + +=== b) Creazione o ulteriore sviluppo di software + +Se un'autorità federale sviluppa software autonomamente o tramite terzi, si applica l'OSS articolo 9 LMeCA. Ciò vale anche per il software ulteriormente sviluppato nell'ambito di un contributo a progetti OSS esistenti. Si può rinunciare alla pubblicazione del codice sorgente soltanto in relazione a diritti di terzi o per motivi rilevanti per la sicurezza. Vi preghiamo di compilare la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare OSS]. + +NOTE: Questa lista di controllo serve anche a motivare perché un software [.underline]#non debba# essere pubblicato. È quindi opportuno consultarla il prima possibile nel progetto. La guida link:em002-2.pdf[Em002-2] descrive l'intero processo. + +Ulteriori questioni da chiarire sono: + +=== Sotto quale licenza open source avviene la pubblicazione? + +Occorre rispondere alla domanda di fondo se il software venga pubblicato sotto una licenza [.underline]#copyleft# (in tal caso l'AGPL V3 è per esempio una buona scelta) oppure in modo [.underline]#permissivo# (per esempio sotto licenza MIT). Per la scelta della licenza, la link:em002-3.pdf[Em002-3 Guida alle licenze OSS] fornisce informazioni dettagliate. Vi preghiamo di compilare la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[lista di controllo Em002-2.2 Analisi e preparazione OSS]. + +NOTE: Idealmente la compilazione spetta alla direzione (tecnica) del progetto o all'architetto informatico. + +=== Dove e come devono essere pubblicati il software e i relativi artefatti? + +Vi preghiamo di compilare la link:em002-2-3-checklist-oss-release-and-publication.pdf[lista di controllo Em002-2.3 Rilascio e pubblicazione OSS]. + +NOTE: Si tratta di una rilevazione complessiva di dove e come il software viene pubblicato. Può essere necessario coinvolgere altre organizzazioni. + +=== Occorre costituire una community OSS? + +La link:em002-4.pdf[Em002-4 Guida alle community OSS] descrive i vantaggi e i compiti legati alla costituzione di una community OSS sulla base di un concetto. + +[.underline]#In caso affermativo#: compilate la link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS], che fornisce indicazioni sul tipo e sulla piattaforma desiderati per la community. + +NOTE: Il team di progetto dispone qui di ampio margine di manovra riguardo alla costituzione e al tipo di community. Può essere necessario coinvolgere altri servizi. + +Rispondete a queste domande e verificate regolarmente (circa una volta all'anno) se sono intervenuti cambiamenti sostanziali. + +Ogni autorità federale (p. es. ufficio, unità amministrativa) che sviluppa o fa sviluppare software è responsabile in modo autonomo dell'intero processo di pubblicazione. + +== Panoramica degli strumenti e delle risorse + +image::./assets/em002-5/media/image2.png[Panoramica degli strumenti OSS,600] + +Gli strumenti e le risorse sono disponibili sul sito della Cancelleria federale +alla pagina https://www.bk.admin.ch/bk/it/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[strumenti OSS]. Sono inoltre https://github.com/swiss/opensource-guidelines/tree/main/docs[pubblicati su GitHub], dove potete fornire direttamente un riscontro. Il catalogo OSS (opensource.admin.ch) offre una panoramica del software pubblicato dalle autorità federali. Per domande rivolgetevi a: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. + +== Gruppi target dei diversi strumenti OSS + +Gli strumenti e le risorse OSS si rivolgono a gruppi target diversi. La tabella seguente raccomanda quali documenti sono rilevanti per quale gruppo target. + +.Strumenti e risorse OSS per gruppo target +[options="header",cols="3,1,1,1,1,1,1,1,1,1"] +|=== +|Documento \ Gruppo target |Direzione |Direzione informatica (a) |ISBO / DSBO (a) |Application Manager |Direzione di progetto |Servizio giuridico |Acquisti |Sviluppo |Comunicazione + +|Em002 Linee guida strategiche +a|X + +3,4,5 +a|*X* + +2-5 + +Allegati B, C +a|X + +2-5 + +Allegati B, C +| +a|(X) + +5 + +Allegato B +| +| +| +|(X) + +|Em002-1 Guida pratica +|X +|*X* +|*X* +|*X* +|X +| +| +| +| + +|Em002-2 Istruzioni per la pubblicazione di OSS +| +a|(X) + +1,3,5 +a|X + +1,3 5 +a|(X) + +1,3,5 +a|*(X)* + +3,5 +| +| +a|X + +1-5 +| + +|Em002-2.1 Lista di controllo Valutazione preliminare OSS +| +a|*(X)* + +(c) +a|*X* + +(b), (c) +a|X + +(b) +a|X + +(b) +| +| +| +| + +|Em002-2.2 Lista di controllo Analisi e preparazione OSS +| +| +a|*X* + +*(c)* +a|*X* + +*(c)* +a|*X* + +*(c)* +| +| +a|X + +(b) +| + +|Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS +| +| +a|*X* + +(c) +a|*X* + +(c) +| +| +| +a|X + +(b) +a|X + +(d) + +|Em002-3 Guida alle licenze OSS +| +|*(X)* +|*(X)* +| +| +|*X* +a|(X) + +8 +|(X) +| + +|Em002-4 Guida alle community OSS +a|(X) + +3 +a|X + +3,5 +a|X + +4,5 +|*X* +| +| +| +|(X) +|X + +|Em002-4.1 Lista di controllo Community OSS +| +a|*(X)* + +(c) +a|*(X)* + +(c) +a|(X) + +(d) +a|X + +(b) +a|(X) + +(d) +| +| +a|(X) + +(d) + +|Em002-5 Promemoria Strumenti OSS (e) +|X +|X +|X +|X +|X +|X +|X +|X +|X + +|Em002-6 FAQ sull'OSS (e) +|(X) +|(X) +|(X) +|X +| +|X +|(X) +|(X) +|(X) + +|Em002-7 Aspetti strategici degli acquisti e OSS +| +|*(X)* +|*(X)* +| +|(X) +|X +|X +| +| + +|Promemoria CCAP +|X +|*X* +|*X* +|X +|(X) +|X +|X +| +| + +|Direttive UFCL +| +| +| +|*(X)* +|*(X)* +| +|X +| +| + +|Lista di controllo UFCL per eccezione forfettaria +| +|*(X)* +| +|(X) +|(X) +| +|X +| +| +|=== + +Legenda: + +* X -- gruppo target, (X) -- in caso di interesse/necessità, almeno il riassunto per la direzione +* (a) persona responsabile dell'art. 9 LMeCA nell'UO. Può essere la direzione informatica o una persona delegata +* (b) compilare +* (c) approvare +* (d) consultare +* (e) principalmente a scopo informativo e di consultazione +* Grassetto = proposta del servizio responsabile in un'UO (può essere disciplinato diversamente) +* Cifre e lettere maiuscole: capitoli e allegati determinanti. Se non ne sono indicati, è rilevante l'intero documento. +* Responsabilità dei documenti: CaF/TDI (giallo), CCAP e UFCL (blu) +endif::[] + +ifeval::["{lang}" == "rm"] +[IMPORTANT] +==== +Quest document è ina sbozza ch'è vegn sviluppada vinavant e fa part dals meds che sustegnan l'administraziun federala en la publicaziun da code open source. Ulteriuras infurmaziuns chattais Vus en il https://github.com/swiss/opensource-guidelines/tree/main[README] principal. +==== + +''' + +== Fegl d'infurmaziun: applicaziun da l'OSS artitgel 9 EMBAG + +La nova https://www.fedlex.admin.ch/eli/cc/2023/682/rm#art_9[lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG)] è entrada en vigur ils 1. da schaner 2024. Ella oblighescha las autoritads federalas da publitgar il code da funtauna dal software ch'ellas sviluppan u fan sviluppar. Excepziuns datti, sche dretgs da terzas persunas u motivs relevants per la segirezza excludan u restrenschan la publicaziun. + +image::./assets/em002-5/media/image1.png[Grafica da survista dal process OSS artitgel 9 EMBAG,600] + +Quest document s'adressa a las [.underline]#manadras e als manaders da project# sco er a las autras [.underline]#persunas responsablas per l'acquist da software#. + +== Dumondas introductivas: + +Acquista u utilisescha l'autoritad federala in software standard senza adattaziuns? +Sche gea, vesair a) + +u + +Sto ina applicaziun u ina cumponenta da software vegnir sviluppada spezialmain per la Confederaziun (software individual = make)? +Sche gea, vesair b) + +=== a) Acquist ed utilisaziun da software standard + +Sche la Confederaziun cumpra software senza adattaziuns, n'è l'artitgel 9 EMBAG betg applitgabel. Mintga autoritad federala decida libramain, sch'ella acquista ed utilisescha software open source u auter software. +Sustegn per l'acquist da software chattais Vus sin la pagina d'internet da l'https://www.beschaffung.admin.ch/bpl/de/home/fachstellen/kompetenzzentrum-beschaffungswesen-bund-kbb.html[Uffizi federal per edifizis e logistica (UFCL)] sco er en il https://perimap.admin.ch/goto_perimap_file_46835_download.html[fegl d'infurmaziun davart l'acquist da software e l'art. 9 EMBAG] dal CCA. Sche necessari po vegnir consultà ultra da quai link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist ed OSS]. + +=== b) Creaziun u svilup vinavant da software + +Sche in'autoritad federala sviluppa software sezza u tras terzas persunas, sto vegnir applitgà l'OSS artitgel 9 EMBAG. Quai vala er per software che vegn sviluppà vinavant en il rom d'ina contribuziun a projects OSS existents. Sin la publicaziun dal code da funtauna po vegnir renunzià mo pervia da dretgs da terzas persunas u per motivs relevants per la segirezza. Empleni p.pl. la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara OSS]. + +NOTE: Questa glista da controlla serva er sco motivaziun, pertge ch'in software [.underline]#na sto betg# vegnir publitgà. Ella duess perquai vegnir consultada uschè baud sco pussaivel en il project. L'instrucziun link:em002-2.pdf[Em002-2] descriva l'entir process. + +Ulteriuras dumondas da sclerir èn: + +=== Sut tge licenza open source vegn publitgà? + +I sto vegnir respundida la dumonda fundamentala, sche il software vegn publitgà sut ina licenza [.underline]#copyleft# (lura è per exempel l'AGPL V3 ina buna tscherna) u [.underline]#permissivamain# (lura per exempel sut ina licenza MIT). Concernent la tscherna da la licenza da la link:em002-3.pdf[Em002-3 Guida da licenzas OSS] infurmaziuns detagliadas. Empleni p.pl. la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[glista da controlla Em002-2.2 Analisa e preparaziun OSS]. + +NOTE: Idealmain vegn quai emplenì da la direcziun (tecnica) dal project u da l'architecta u l'architect d'informatica. + +=== Nua e co duain il software ed ils artefacts appartenents vegnir publitgads? + +Empleni p.pl. la link:em002-2-3-checklist-oss-release-and-publication.pdf[glista da controlla Em002-2.3 Relaschada e publicaziun OSS]. + +NOTE: I sa tracta d'ina registraziun cumplessiva, nua e co che software vegn publitgà. Eventualmain ston vegnir integradas ulteriuras organisaziuns. + +=== Duai vegnir construida ina communitad OSS? + +La link:em002-4.pdf[Em002-4 Guida da communitads OSS] descriva ils avantatgs e las incumbensas cun construir ina communitad OSS sin basa d'in concept. + +[.underline]#Sche gea#: Empleni la link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS], che dat infurmaziuns davart il gener e la plattafurma giavischada da la communitad. + +NOTE: Il team dal project ha qua ina gronda libertad, sche e tge gener da communitad che duai vegnir construida. Eventualmain ston vegnir integrads ulteriurs posts. + +Respundai questas dumondas e controllai regularmain (var ina giada l'onn), sche i dat midadas essenzialas. + +Mintga autoritad federala (p.ex. uffizi, unitad administrativa) che sviluppa u fa sviluppar software è responsabla independentamain per l'entir process da publicaziun. + +== Survista dals meds e da las resursas + +image::./assets/em002-5/media/image2.png[Survista dals meds OSS,600] + +Ils meds e las resursas stattan a disposiziun sin la pagina d'internet da la Chanzlia federala +sut https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[meds OSS]. Els èn ultra da quai https://github.com/swiss/opensource-guidelines/tree/main/docs[publitgads sin GitHub], nua che Vus pudais dar directamain in resun. Il catalog OSS (opensource.admin.ch) dat ina survista dal software publitgà da las autoritads federalas. Per dumondas As drizzai a: mailto:opensource@bk.admin.ch[opensource@bk.admin.ch]. + +== Gruppas da destinaziun dals differents meds OSS + +Ils meds e las resursas OSS s'adressan a differentas gruppas da destinaziun. La tabella suandanta cuntegna ina recumandaziun, tge documents che èn relevants per tge gruppa da destinaziun. + +.Meds e resursas OSS tenor gruppa da destinaziun +[options="header",cols="3,1,1,1,1,1,1,1,1,1"] +|=== +|Document \ Gruppa da destinaziun |Direcziun |Direcziun d'informatica (a) |ISBO / DSBO (a) |Application Manager |Direcziun da project |Servetsch giuridic |Acquist |Svilup |Communicaziun + +|Em002 Directivas strategicas +a|X + +3,4,5 +a|*X* + +2-5 + +Agiunta B, C +a|X + +2-5 + +Agiunta B, C +| +a|(X) + +5 + +Agiunta B +| +| +| +|(X) + +|Em002-1 Guida pratica +|X +|*X* +|*X* +|*X* +|X +| +| +| +| + +|Em002-2 Instrucziuns per publitgar OSS +| +a|(X) + +1,3,5 +a|X + +1,3 5 +a|(X) + +1,3,5 +a|*(X)* + +3,5 +| +| +a|X + +1-5 +| + +|Em002-2.1 Glista da controlla Evaluaziun preliminara OSS +| +a|*(X)* + +(c) +a|*X* + +(b), (c) +a|X + +(b) +a|X + +(b) +| +| +| +| + +|Em002-2.2 Glista da controlla Analisa e preparaziun OSS +| +| +a|*X* + +*(c)* +a|*X* + +*(c)* +a|*X* + +*(c)* +| +| +a|X + +(b) +| + +|Em002-2.3 Glista da controlla Relaschada e publicaziun OSS +| +| +a|*X* + +(c) +a|*X* + +(c) +| +| +| +a|X + +(b) +a|X + +(d) + +|Em002-3 Guida da licenzas OSS +| +|*(X)* +|*(X)* +| +| +|*X* +a|(X) + +8 +|(X) +| + +|Em002-4 Guida da communitads OSS +a|(X) + +3 +a|X + +3,5 +a|X + +4,5 +|*X* +| +| +| +|(X) +|X + +|Em002-4.1 Glista da controlla Communitad OSS +| +a|*(X)* + +(c) +a|*(X)* + +(c) +a|(X) + +(d) +a|X + +(b) +a|(X) + +(d) +| +| +a|(X) + +(d) + +|Em002-5 Fegl d'infurmaziun Meds OSS (e) +|X +|X +|X +|X +|X +|X +|X +|X +|X + +|Em002-6 FAQ davart OSS (e) +|(X) +|(X) +|(X) +|X +| +|X +|(X) +|(X) +|(X) + +|Em002-7 Aspects strategics da l'acquist ed OSS +| +|*(X)* +|*(X)* +| +|(X) +|X +|X +| +| + +|Fegl d'infurmaziun CCA +|X +|*X* +|*X* +|X +|(X) +|X +|X +| +| + +|Directivas UFCL +| +| +| +|*(X)* +|*(X)* +| +|X +| +| + +|Glista da controlla UFCL per excepziun forfaitara +| +|*(X)* +| +|(X) +|(X) +| +|X +| +| +|=== + +Legenda: + +* X -- gruppa da destinaziun, (X) -- en cas d'interess/basegn, almain il resumaziun per la direcziun +* (a) persuna responsabla per l'art. 9 EMBAG en l'UO. Po esser la direcziun d'informatica u vegnir delegada +* (b) emplenir +* (c) approvar +* (d) consultar +* (e) principalmain per l'infurmaziun e sco ovra da consultaziun +* Grass = proposta dal post responsabel en in'UO (po vegnir reglà autramain) +* Cifras e maiusclas: chapitels ed agiuntas relevants. Sche naginas n'èn inditgadas, è l'entir document relevant. +* Responsabladad per ils documents: ChF/TDI (mellen), CCA ed UFCL (blau) +endif::[] From 2366419e9ebd42befba680b7759e0ab1c7106307 Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Tue, 15 Sep 2026 13:24:49 +0200 Subject: [PATCH 08/58] Build the five languages in parallel and publish one site The render job becomes a matrix over en/de/fr/it/rm. Each renders the same sources with its own `--lang` into out//, which is what keeps the outputs apart: `-o ` names every PDF `.pdf` with the language nowhere in the filename. A new collect job merges the five artifacts into site// -- `merge-multiple: true` is load-bearing, without it each archive lands under its own pdfs-/ -- and writes the language chooser. Pages now deploys that tree instead of a flat pdfs/ directory. The index pages move out of the workflow into tools/site-index.sh and tools/site-root.sh so `render-docs` can build byte-identical ones locally; an index reimplemented in the workflow is an index that stops matching what you see before you push. site-index.sh labels each entry with the document's title read from that language's ifeval:: block, and lists only the PDFs actually present -- which is how a document that opts out of a language with `:l10n-languages:` stays absent from it rather than appearing as a blank PDF. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/render-docs.yml | 88 +++++++++++++++++------- devenv.nix | 53 +++++++++++--- tools/site-index.sh | 110 ++++++++++++++++++++++++++++++ tools/site-root.sh | 69 +++++++++++++++++++ 4 files changed, 289 insertions(+), 31 deletions(-) create mode 100755 tools/site-index.sh create mode 100755 tools/site-root.sh diff --git a/.github/workflows/render-docs.yml b/.github/workflows/render-docs.yml index 7e0650d..a2a2a7e 100644 --- a/.github/workflows/render-docs.yml +++ b/.github/workflows/render-docs.yml @@ -23,8 +23,19 @@ env: GOVPRESS_SHA256: 3766f1da1137208a438abe06b4ad8427734e1de782aac33ff1d47df3e975ecdf jobs: + # One job per language. Every document carries all five languages in one + # file, so the same sources are rendered five times, each pinned with + # `--lang`, into a directory of its own -- `-o ` names outputs + # `.pdf` with no language in the filename, so the directory is + # what keeps them apart. render: runs-on: ubuntu-latest + strategy: + # One broken language should report itself rather than cancel the other + # four and hide whether they were fine. + fail-fast: false + matrix: + lang: [en, de, fr, it, rm] steps: - uses: actions/checkout@v4 @@ -48,43 +59,74 @@ jobs: bin=$(find /tmp/open-govpress -maxdepth 2 -name open-govpress -type f) echo "OGP_BIN=$bin" >> "$GITHUB_ENV" - - name: Render all documents + - name: Render all documents in ${{ matrix.lang }} + env: + LANG_ID: ${{ matrix.lang }} run: | - mkdir -p pdfs - mapfile -t docs < <(git ls-files '*.adoc') - xvfb-run -a "$OGP_BIN" render --no-sandbox -o pdfs "${docs[@]}" + mkdir -p "out/$LANG_ID" - - name: Generate index page - run: | - { - echo '' - echo '' - echo 'opensource-guidelines — rendered PDFs' - echo '

opensource-guidelines — rendered documents

' - echo '

Auto-rendered from the .adoc sources in this repository by GitHub Actions.

' - echo '
    ' - for f in pdfs/*.pdf; do - name=$(basename "$f") - echo "
  • $name
    • " - done - echo '
' - } > pdfs/index.html + # A document may opt out of a language with `:l10n-languages:` in its + # header. Absent means all five. Skipping it here is what makes an + # untranslated document *absent* from that language rather than + # rendered as a blank PDF -- no ifeval:: branch matches, so the body + # would be empty. + docs=() + while IFS= read -r doc; do + langs=$(sed -n 's/^:l10n-languages:[[:space:]]*//p' "$doc" | head -1) + if [ -z "$langs" ] || grep -qw "$LANG_ID" <<<"$langs"; then + docs+=("$doc") + else + echo "skipping $doc (no $LANG_ID translation)" + fi + done < <(git ls-files '*.adoc') + + xvfb-run -a "$OGP_BIN" render --no-sandbox \ + --lang "$LANG_ID" -o "out/$LANG_ID" "${docs[@]}" + + - name: Generate language index page + run: tools/site-index.sh "${{ matrix.lang }}" "out/${{ matrix.lang }}" - name: Upload build artifact uses: actions/upload-artifact@v4 with: - name: rendered-pdfs - path: pdfs/ + # `path: out/` so the archive's root is `/`, which is what lets + # the collect job merge all five into one tree. + name: pdfs-${{ matrix.lang }} + path: out/ + + collect: + needs: render + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Download every language + uses: actions/download-artifact@v4 + with: + pattern: pdfs-* + # Without this each archive lands under its own `pdfs-/` + # directory instead of merging into `site//`. + merge-multiple: true + path: site + + - name: Generate language chooser + run: tools/site-root.sh site + + - name: Upload site artifact + uses: actions/upload-artifact@v4 + with: + name: site + path: site/ - name: Upload Pages artifact if: github.event_name == 'push' && github.ref == 'refs/heads/main' uses: actions/upload-pages-artifact@v3 with: - path: pdfs/ + path: site/ deploy: if: github.event_name == 'push' && github.ref == 'refs/heads/main' - needs: render + needs: collect runs-on: ubuntu-latest permissions: pages: write diff --git a/devenv.nix b/devenv.nix index 0ae3b00..79f4ff2 100644 --- a/devenv.nix +++ b/devenv.nix @@ -150,19 +150,56 @@ in ''; }; - # Renders every tracked .adoc file in the repo to PDF, next to its source - # -- a quick way to sanity-check the whole corpus still renders after an - # edit, mirroring the check every converting agent ran individually during - # the Markdown -> AsciiDoc migration. + # Builds the whole published site locally: every tracked .adoc rendered + # once per language into build//, with the same per-language index + # pages and language chooser that CI publishes to GitHub Pages. + # + # It shares tools/site-index.sh and tools/site-root.sh with the workflow on + # purpose -- the point of building locally is to see what will be published, + # which a second implementation of the index would quietly stop doing. scripts.render-docs = { - description = "Render every .adoc document in the repo to PDF"; + description = "Render every .adoc document in every language into build/ (render-docs [lang...])"; exec = '' set -euo pipefail cd '${config.devenv.root}' - mapfile -t docs < <(git ls-files '*.adoc') - echo "Rendering ''${#docs[@]} documents..." - open-govpress render "''${docs[@]}" + if [ "$#" -gt 0 ]; then + langs=("''${@}") + else + langs=(en de fr it rm) + fi + + for lang in "''${langs[@]}"; do + case "$lang" in + en | de | fr | it | rm) ;; + *) + echo "render-docs: unknown language '$lang' (expected en, de, fr, it or rm)" >&2 + exit 1 + ;; + esac + done + + for lang in "''${langs[@]}"; do + # A document may opt out of a language with `:l10n-languages:` in its + # header; absent means all five. Skipping it here keeps an untranslated + # document out of that language entirely, rather than rendering a PDF + # whose body every ifeval:: guard rejected. + docs=() + while IFS= read -r doc; do + doc_langs=$(sed -n 's/^:l10n-languages:[[:space:]]*//p' "$doc" | head -1) + if [ -z "$doc_langs" ] || grep -qw "$lang" <<<"$doc_langs"; then + docs+=("$doc") + fi + done < <(git ls-files '*.adoc') + + echo "Rendering ''${#docs[@]} documents in $lang..." + mkdir -p "build/$lang" + open-govpress render --lang "$lang" -o "build/$lang" "''${docs[@]}" + ./tools/site-index.sh "$lang" "build/$lang" + done + + ./tools/site-root.sh build + echo "Site built in build/ -- open build/index.html" ''; }; } diff --git a/tools/site-index.sh b/tools/site-index.sh new file mode 100755 index 0000000..0008f05 --- /dev/null +++ b/tools/site-index.sh @@ -0,0 +1,110 @@ +#!/usr/bin/env bash +# +# Write the listing page for one language directory of the published site. +# +# tools/site-index.sh +# +# Lists the PDFs that are actually present in , which is what implements +# "a document that has no translation in this language is omitted": the render +# step never produced the file, so nothing links to it. +# +# Each entry is labelled with the document's title *in that language*, read out +# of the source's `ifeval::["{lang}" == ""]` block rather than from the +# filename. + +set -euo pipefail + +lang="${1:?usage: site-index.sh }" +dir="${2:?usage: site-index.sh }" + +case "$lang" in + en) heading="Tools for Publishing Open Source Software" + lead="Automatically rendered from the AsciiDoc sources in this repository." ;; + de) heading="Hilfsmittel zur Veröffentlichung von Open-Source-Software" + lead="Automatisch aus den AsciiDoc-Quellen dieses Repositorys gerendert." ;; + fr) heading="Outils pour la publication de logiciels open source" + lead="Généré automatiquement à partir des sources AsciiDoc de ce dépôt." ;; + it) heading="Strumenti per la pubblicazione di software open source" + lead="Generato automaticamente dai sorgenti AsciiDoc di questo repository." ;; + rm) heading="Meds per publitgar software open source" + lead="Generà automaticamain a partir da las funtaunas AsciiDoc da quest repositori." ;; + *) echo "site-index.sh: unknown language '$lang'" >&2; exit 1 ;; +esac + +escape() { sed -e 's/&/\&/g' -e 's//\>/g' -e 's/"/\"/g'; } + +# The title for this language, or the bare filename if the source has no block +# for it (which the render step should already have prevented). +doc_title() { + local src="$1" title + title=$(awk -v lang="$lang" ' + /^ifeval::\["\{lang\}" == "/ { inblock = ($0 ~ "\"" lang "\"]$"); next } + /^endif::\[\]/ { inblock = 0; next } + inblock && /^= / { sub(/^= /, ""); print; exit } + ' "$src") + [ -n "$title" ] || title=$(basename "$src" .adoc) + printf '%s' "$title" +} + +# basename -> source path, so a rendered PDF can be traced back to its document. +declare -A source_of +while IFS= read -r src; do + source_of["$(basename "$src" .adoc)"]="$src" +done < <(git ls-files '*.adoc') + +{ + cat < + + + +$(printf '%s' "$heading" | escape) + +

$(printf '%s' "$heading" | escape)

+

$(printf '%s' "$lead" | escape)

+
The German, French, Italian and Romansh versions are unreviewed translations. The binding versions are published in the official languages by -the Federal Chancellery.
+the Federal Chancellery. +HTML + + # Only on the published site, where site-archive.sh has written the listing. + # A pull request build has no archive, and a dead link would be worse than + # no link at all. + [ -f "$dir/archive.html" ] && + printf '
Earlier builds and releases\n' + + cat <<'HTML' + HTML } > "$dir/index.html" From b059a07b8c1cf92fefb040bd32f949fe895c8b3e Mon Sep 17 00:00:00 2001 From: shrewd-laidback palace Date: Wed, 16 Sep 2026 03:16:36 +0200 Subject: [PATCH 24/58] Make the links on the generated pages look like links Every row on the language chooser, the document listings and the archive was an anchor styled `color: inherit; text-decoration: none`, so nothing marked it as clickable until the pointer was already over it and the hover tint appeared. Keyboard users got no cue at all. Each row now carries an underlined label in a link colour, and the affordance matches what the row actually does: a chevron where the row navigates, and a PDF badge on the document listings, where the row hands over a file instead. `:focus-visible` gets a visible ring, and the palette moves to custom properties with a dark-scheme variant so the link colour stays legible either way. The back arrows are labelled rather than bare glyphs -- "All languages", and its translation in each of the five languages on the document listings -- so the link says where it leads. The archive link in the chooser footer is likewise a coloured, underlined link rather than plain footer text. Co-Authored-By: Claude Opus 5 --- tools/site-archive.sh | 37 +++++++++++++++++++++----------- tools/site-index.sh | 49 +++++++++++++++++++++++++++++++------------ tools/site-root.sh | 42 ++++++++++++++++++++++++++----------- 3 files changed, 91 insertions(+), 37 deletions(-) diff --git a/tools/site-archive.sh b/tools/site-archive.sh index 3b13795..38a89e5 100755 --- a/tools/site-archive.sh +++ b/tools/site-archive.sh @@ -51,12 +51,12 @@ emit_entries() { local date subject date=$(meta_field "$meta" date) subject=$(meta_field "$meta" subject) - printf '
  • %s%s%s
    • \n' \ + printf '
  • %s%s%s
    • \n' \ "$(printf '%s' "$subdir" | escape)" \ "$(printf '%s' "$name" | escape)" \ - "$(printf '%s' "${date%T*}" | escape)" \ "$(printf '%s' "$name" | escape)" \ - "$(printf '%s' "$subject" | escape)" + "$(printf '%s' "$subject" | escape)" \ + "$(printf '%s' "${date%T*}" | escape)" done < <(printf '%s\n' "${rows[@]}" | sort -rn -t' ' -k1,1) } @@ -68,7 +68,11 @@ emit_entries() { Archived builds — Open Source Guidelines

    Archived builds

    Each entry is the complete set of documents, in all languages, as @@ -109,7 +122,7 @@ HTML fi cat <<'HTML' -

    + HTML } > "$dir/archive.html" diff --git a/tools/site-index.sh b/tools/site-index.sh index 0008f05..68b5bbf 100755 --- a/tools/site-index.sh +++ b/tools/site-index.sh @@ -17,17 +17,24 @@ set -euo pipefail lang="${1:?usage: site-index.sh }" dir="${2:?usage: site-index.sh }" +# `back` labels the link to the language chooser. A bare arrow gave no clue +# where it led, or that it led anywhere. case "$lang" in en) heading="Tools for Publishing Open Source Software" - lead="Automatically rendered from the AsciiDoc sources in this repository." ;; + lead="Automatically rendered from the AsciiDoc sources in this repository." + back="All languages" ;; de) heading="Hilfsmittel zur Veröffentlichung von Open-Source-Software" - lead="Automatisch aus den AsciiDoc-Quellen dieses Repositorys gerendert." ;; + lead="Automatisch aus den AsciiDoc-Quellen dieses Repositorys gerendert." + back="Alle Sprachen" ;; fr) heading="Outils pour la publication de logiciels open source" - lead="Généré automatiquement à partir des sources AsciiDoc de ce dépôt." ;; + lead="Généré automatiquement à partir des sources AsciiDoc de ce dépôt." + back="Toutes les langues" ;; it) heading="Strumenti per la pubblicazione di software open source" - lead="Generato automaticamente dai sorgenti AsciiDoc di questo repository." ;; + lead="Generato automaticamente dai sorgenti AsciiDoc di questo repository." + back="Tutte le lingue" ;; rm) heading="Meds per publitgar software open source" - lead="Generà automaticamain a partir da las funtaunas AsciiDoc da quest repositori." ;; + lead="Generà automaticamain a partir da las funtaunas AsciiDoc da quest repositori." + back="Tut las linguas" ;; *) echo "site-index.sh: unknown language '$lang'" >&2; exit 1 ;; esac @@ -60,18 +67,34 @@ done < <(git ls-files '*.adoc') $(printf '%s' "$heading" | escape)

    $(printf '%s' "$heading" | escape)

    $(printf '%s' "$lead" | escape)

    @@ -94,7 +117,7 @@ HTML else label="$stem" fi - printf '
  • %s%s
    • \n' \ + printf '
  • %s%sPDF
    • \n' \ "$(printf '%s' "$pdf" | escape)" \ "$(printf '%s' "$label" | escape)" \ "$(printf '%s' "$pdf" | escape)" @@ -102,7 +125,7 @@ HTML cat < - + HTML } > "$dir/index.html" diff --git a/tools/site-root.sh b/tools/site-root.sh index 3effc24..d8b98ec 100755 --- a/tools/site-root.sh +++ b/tools/site-root.sh @@ -32,18 +32,35 @@ label_of() { Open Source Guidelines

    Open Source Guidelines

    Tools for publishing open source software in the Swiss Federal @@ -53,22 +70,23 @@ HTML for lang in en de fr it rm; do [ -d "$dir/$lang" ] || continue - printf '

  • %s%s
    • \n' \ - "$lang" "$lang" "$(label_of "$lang")" + printf '
  • %s%s
    • \n' \ + "$lang" "$(label_of "$lang")" "$lang" done cat <<'HTML' -