diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000..c46ae4d --- /dev/null +++ b/.editorconfig @@ -0,0 +1,35 @@ +# http://editorconfig.org + +# A special property that should be specified at the top of the file outside of +# any sections. Set to true to stop .editor config file search on current file +root = true + +[*] +# Indentation style +# Possible values - tab, space +indent_style = space + +# Indentation size in single-spaced characters +# Possible values - an integer, tab +indent_size = 2 + +# Line ending file format +# Possible values - lf, crlf, cr +end_of_line = lf + +# File character encoding +# Possible values - latin1, utf-8, utf-16be, utf-16le +charset = utf-8 + +# Denotes whether to trim whitespace at the end of lines +# Possible values - true, false +trim_trailing_whitespace = true + +# Denotes whether file should end with a newline +# Possible values - true, false +insert_final_newline = true + +# Verbatim legal text, reproduced exactly as published. Its roman-numeral +# hanging indents are not ours to normalise. +[LICENSE] +indent_size = unset 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/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 0000000..07f0059 --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,58 @@ +name: Lint + +on: + push: + # Kept in step with render-docs.yml's trigger list: a branch worth rendering + # is a branch worth linting. Nothing here depends on which branch publishes. + branches: [main, develop] + pull_request: + +permissions: + contents: read + +# Deliberately not the `pages` group that render-docs.yml uses: linting does not +# touch the deployment, and sharing that group would queue every lint run behind +# a publish. +concurrency: + group: lint-${{ github.ref }} + cancel-in-progress: true + +jobs: + git-hooks: + runs-on: ubuntu-latest + steps: + # The hooks read the index, not just the work tree -- check-asciidoc and + # site-index.sh both call `git ls-files` -- so this needs a real checkout. + # Full history is not needed: every hook looks at the tree as it stands. + - uses: actions/checkout@v7 + + - name: Install Nix + uses: cachix/install-nix-action@v31 + + # Pulls the prebuilt devenv closure instead of compiling it on the runner. + - name: Use the devenv binary cache + uses: cachix/cachix-action@v17 + with: + name: devenv + + - name: Install devenv + run: nix profile install nixpkgs#devenv + + # `prek run --all-files` rather than `devenv test`: devenv reports only + # that the git-hooks task failed, without saying which hook or why, even + # with tasks."devenv:git-hooks:run".showOutput set. Running prek directly + # prints the per-hook result and the offending lines, which is the whole + # point of having this job. + # + # --show-diff-on-failure matters because several of these hooks fix the + # file rather than just complaining (end-of-file-fixer, dos2unix, + # trim-trailing-whitespace, nixfmt). Without the diff, CI would report + # "files were modified by this hook" and show nothing else. + # + # `--option env.cicd:bool true` drops the interactive-only packages, most + # of which is VS Code. Without it this job would download the whole + # editor closure on every push just to run the hooks. + - name: Run every git hook over every file + run: | + devenv --option env.cicd:bool true \ + shell -- prek run --all-files --show-diff-on-failure diff --git a/.github/workflows/render-docs.yml b/.github/workflows/render-docs.yml new file mode 100644 index 0000000..c61e5cd --- /dev/null +++ b/.github/workflows/render-docs.yml @@ -0,0 +1,232 @@ +name: Render docs + +on: + push: + # `on:` is the one block where expressions are not allowed, so this list + # cannot itself be driven by PAGES_PUBLISH_BRANCH (see `env:` below). Read + # it as the set of branches CI may *run* on; the variable picks which one of + # them *publishes*. A branch missing from here triggers nothing at all, so + # pointing the variable at a new branch means listing it here as well. + branches: [main, develop] + # Docs releases only. `open-govpress-v*` tags the renderer binary released + # from this repo (see GOVPRESS_URL below), and must not publish a docs + # archive of its own -- `v*` excludes it by construction. + tags: ['v*'] + 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.19" + GOVPRESS_URL: https://github.com/736-c41-2c1-e464fc974/opensource-guidelines/releases/download/open-govpress-v0.0.19/open-govpress-0.0.19-linux-x64.tar.gz + GOVPRESS_SHA256: 946c7f187ec1eb109681e89cbd9aebcba869e560df8f7493ddbecd3540a9b679 + + # Which branch owns the published site. Set the repository variable + # PAGES_PUBLISH_BRANCH (Settings -> Secrets and variables -> Actions -> + # Variables) to move publishing to another branch without editing this file; + # unset means `main`, so the default is the behaviour this workflow has always + # had. Tags publish regardless -- a release archives itself whatever branch is + # currently the published one. + # + # Carried into tools/site-publish.sh, which re-checks it rather than trusting + # the caller, and on into tools/site-archive.sh, which names the branch on the + # archive page. + PUBLISH_BRANCH: ${{ vars.PAGES_PUBLISH_BRANCH || 'main' }} + +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@v7 + + - name: Cache open-govpress download + uses: actions/cache@v6 + 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 in ${{ matrix.lang }} + env: + LANG_ID: ${{ matrix.lang }} + run: | + mkdir -p "out/$LANG_ID" + + # 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/partials/` is excluded: it holds fragments that are + # `include::`d into the documents, and a fragment is not a document. + 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' ':!docs/partials/*') + + 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@v7 + with: + # `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 + outputs: + # The one publish decision for the whole workflow -- the steps below read + # it back, and so does the deploy job. + publish: ${{ steps.gate.outputs.publish }} + permissions: + # `contents: write` is for pushing the accumulated site to the + # `site-history` branch. Job-level permissions replace the top-level block + # outright rather than adding to it, so the read scopes have to be + # restated here. + contents: write + actions: read + steps: + - uses: actions/checkout@v7 + + # Decided once, here, instead of as the same three-clause condition + # repeated on every publishing step and on the deploy job. Those copies + # had to agree with each other and with site-publish.sh's own guard to + # mean anything; a single output cannot drift out of step with itself. + # + # The ref reaches the shell through the environment rather than through + # `${{ }}`: branch names may contain characters that would otherwise be + # substituted into the script before bash ever sees it. + - name: Decide whether this run publishes + id: gate + env: + REF_NAME: ${{ github.ref_name }} + REF_TYPE: ${{ github.ref_type }} + EVENT_NAME: ${{ github.event_name }} + run: | + publish=false + if [ "$EVENT_NAME" = push ]; then + # The trigger admits only `v*` tags, so any tag push reaching here + # is a docs release and archives itself under tags/ either way. + if [ "$REF_TYPE" = tag ] || [ "$REF_NAME" = "$PUBLISH_BRANCH" ]; then + publish=true + fi + fi + echo "publish=$publish" >> "$GITHUB_OUTPUT" + echo "publish=$publish (event=$EVENT_NAME $REF_TYPE=$REF_NAME, published branch=$PUBLISH_BRANCH)" + + - name: Download every language + uses: actions/download-artifact@v8 + 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@v7 + with: + name: site + path: site/ + + # A Pages deployment always replaces the whole site, so publishing an + # older build alongside the current one means uploading both -- which + # means remembering the older one somewhere between runs. That somewhere + # is the `site-history` branch. + - name: Overlay this build onto the published site + if: steps.gate.outputs.publish == 'true' + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + KEEP_COMMITS: "10" + run: tools/site-publish.sh site .site-history + + # upload-pages-artifact excludes `.git` from its tar since v4, but the + # site is re-published from a fresh clone each run and the object store + # has no business being in the artifact -- dropping it here keeps that + # guarantee ours rather than the action's. + - name: Strip the git metadata + if: steps.gate.outputs.publish == 'true' + run: rm -rf .site-history/.git + + - name: Upload Pages artifact + if: steps.gate.outputs.publish == 'true' + uses: actions/upload-pages-artifact@v5 + with: + path: .site-history/ + + deploy: + # Job-level `if:` cannot read the `env` context, which is why the decision + # travels as a job output rather than as PUBLISH_BRANCH compared in place. + if: needs.collect.outputs.publish == 'true' + needs: collect + 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 + env: + # actions/deploy-pages keys the deployment on GITHUB_SHA alone, and + # Pages treats a repeat of an already-published version as a no-op -- + # reporting success while continuing to serve the earlier build. A + # release tag normally points at the commit main has just published, + # so the tag's archive would never reach the site. Qualifying the + # version with the ref name makes each ref its own deployment. + # Undocumented but stable: the runner layers step `env` over the + # default variables, and pages_build_version is a free-form string. + GITHUB_SHA: ${{ github.sha }}-${{ github.ref_name }} + uses: actions/deploy-pages@v5 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..723c601 --- /dev/null +++ b/.gitignore @@ -0,0 +1,20 @@ +# devenv / direnv +.devenv* +.direnv/ + +# Generated by devenv from the git-hooks.hooks block in devenv.nix, as a +# symlink into the nix store. Committing it would pin hook versions to one +# machine's store paths. +/.pre-commit-config.yaml + +# 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 + +# the per-language site built by `render-docs` locally and by CI +/build/ +/site/ diff --git a/DEVENV-SETUP.adoc b/DEVENV-SETUP.adoc new file mode 100644 index 0000000..f1f4958 --- /dev/null +++ b/DEVENV-SETUP.adoc @@ -0,0 +1,227 @@ +:lang: en +ifeval::["{lang}" == "en"] += Setting up the development environment +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +:govpress-style: report +// Black, not the colour mark the guidelines carry: contributor documentation, +// addressed to whoever works on this repository rather than to its readers. +:title-logo-base: black +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +// Contributor documentation, not a guideline: there is no translated body, so +// without this the English text below would be rendered once per language and +// take a row on each of the five index pages. render-docs.sh reads the +// attribute and builds the document only in the languages it names. +:l10n-languages: en +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 +// The repository, written as `{url-repo}` throughout the body. +:url-repo: https://github.com/swiss/opensource-guidelines + +Everything needed to lint and render the documents in this repository is declared in `devenv.nix` and pinned by `devenv.lock`. Nothing is installed globally and no version is left to the machine: the toolchain a contributor gets is the one CI uses, which is why a clean `lint` locally means a green lint job. + +This page covers getting into that environment. What to do once inside -- how a five-language document is structured, and how to render one while translating it -- is link:TRANSLATING.adoc[TRANSLATING.adoc]. + +== Prerequisites + +* *Linux on x86-64*, or Windows with WSL2. macOS is not supported: the renderer ships as a `linux-x64` binary and is run through a Nix FHS environment, which exists only on Linux, so the environment fails to evaluate elsewhere. See the comment at the top of `devenv.nix`. +* *git*, per the https://git-scm.com/book/en/v2/Getting-Started-Installing-Git[official instructions]. +* *Disk and bandwidth.* The first shell downloads a few GB into the Nix store -- most of it VS Code -- and the first render pulls a further 112 MiB for the renderer. +* An internet connection, for both of the above. + +== Installing Nix + +On NixOS there is nothing to do here. Everywhere else: + +[source,sh] +---- +sh <(curl -L https://nixos.org/nix/install) --daemon +---- + +Then open a new shell, so that the profile script the installer added is sourced and `nix` is on the path. + +NOTE: On Fedora and other SELinux distributions, the daemon may refuse to start. Open `/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh` and comment out the first two lines. + +== Configuring Nix + +Two settings, both in `/etc/nix/nix.conf` (on NixOS, in `nix.settings` in your system configuration instead): + +[source,ini] +---- +experimental-features = nix-command flakes +extra-substituters = https://devenv.cachix.org +extra-trusted-public-keys = devenv.cachix.org-1:w1cLUi8dv3hnoSPGAuibQv+f9TZLr6cv/Hm9XgU50cw= +---- + +The first is required: devenv is a flake, and the stock installer leaves both features off. The second points Nix at devenv's binary cache, so the closure is downloaded prebuilt rather than compiled locally -- the difference between minutes and hours on the first shell. CI does the same thing with `cachix/cachix-action`. + +Restart the daemon so the new settings are read: + +[source,sh] +---- +sudo systemctl restart nix-daemon.service +---- + +== Installing devenv + +[source,sh] +---- +nix profile install --accept-flake-config nixpkgs#devenv +---- + +`--accept-flake-config` is what lets devenv's own substituters apply without a prompt. If you would rather not enable flakes at all, the channel equivalent works too: + +[source,sh] +---- +nix-env --install --attr devenv -f https://github.com/NixOS/nixpkgs/tarball/nixos-26.05 +---- + +== Installing direnv + +direnv is what makes the environment load on `cd` instead of on demand. It is optional -- `devenv shell` gives the same environment -- but everything below assumes it. + +. Install it per the https://direnv.net/docs/installation.html[official instructions]. +. https://direnv.net/docs/hook.html[Hook it into your shell]. This step is easy to skip and nothing works without it. + +== Entering the environment + +[source,sh] +---- +git clone {url-repo}.git +cd opensource-guidelines +direnv allow +---- + +`direnv allow` is required once per clone, and again whenever `.envrc` changes: direnv refuses to run a file it has not been told to trust. The first load takes a while and says little; subsequent ones are instant. + +Without direnv, the equivalent is `devenv shell` from the repository root, repeated in every terminal. + +== Verifying the setup + +Entering the shell prints the helper scripts it provides. `devenv-help` prints the same list again at any time: + +[options="header",cols="1,2"] +|=== +|Script |What it does + +|`devenv-help` |Print the list of scripts +|`lint` |Run every git hook over every file +|`render-docs` |Render every document in every language into `build/` +|`open-govpress` |Render named documents -- the renderer itself +|=== + +A working setup runs both of these clean: + +[source,sh] +---- +lint # every hook, every file +render-docs en # the English site into build/en/ +---- + +`render-docs` finishes by naming the file to open -- `build/index.html`, the language chooser, with `build/en/index.html` behind it. That is the same site CI publishes to GitHub Pages, built by the same scripts, which is the point of being able to build it locally at all. + +== The git hooks + +Entering the shell installs the hooks; there is no separate install step and no `pre-commit install` to remember. `.pre-commit-config.yaml` at the root is generated from `devenv.nix` and gitignored -- edit the `git-hooks.hooks` block in `devenv.nix`, never the generated file. + +The hooks run against staged files at commit time. `lint` runs them against everything, which is what CI does, and takes arguments through to https://github.com/j178/prek[prek]: + +[source,sh] +---- +lint # every hook, every file +lint check-asciidoc --all-files # one hook, every file +---- + +Several hooks fix the file rather than only complaining -- `end-of-file-fixer`, `dos2unix`, `trim-trailing-whitespace`, `nixfmt`. A commit they touch fails; stage the fix and commit again. + +`git commit --no-verify` skips them. CI runs the same hooks on push, so this defers the failure rather than avoiding it. + +== Rendering the documents + +`render-docs` builds the whole site; `open-govpress` renders named documents, which is the faster loop while editing one: + +[source,sh] +---- +render-docs # all five languages +render-docs de rm # just those two +open-govpress render --lang de -o build/de/ docs/em002-5.adoc +---- + +The trailing slash on `-o build/de/` is not decoration: with a single input file, that path is treated as a directory only if it ends in a separator or already exists. Without it, the first render into a fresh clone writes a PDF into a file named `build/de`. link:TRANSLATING.adoc[TRANSLATING.adoc] covers this alongside the rest of the per-document loop. + +The first invocation of either downloads the renderer -- a ~112 MiB release asset, checksum-verified -- into `open-govpress/.cache/` and unpacks it into `open-govpress/.extracted/`. Both are gitignored and both are reused afterwards, so only the first render pays for this. It happens on first use rather than on shell entry so that entering the shell stays fast for anyone who is not rendering. + +The renderer is Electron and has no headless mode, so it is always run under `xvfb-run`. This is handled by the `open-govpress` script and needs no display of your own. + +== The editor + +Interactive shells include VS Code with the extensions that match the hooks -- AsciiDoc, direnv, EditorConfig, Nix, ShellCheck, YAML and GitHub Actions -- so that what the hooks reject is visible while typing: + +[source,sh] +---- +code . +---- + +Two things the extensions cannot infer, both worth setting once: point `nix.formatterPath` at `nixfmt`, so the Nix extension formats the way the `nixfmt` hook expects; and note that the ShellCheck hook runs stricter than the extension does (`-x -o all`), so a clean editor does not guarantee a clean commit. + +== Matching what CI does + +CI never installs the editor. Interactive shells get it, CI does not, and the switch is an environment flag: + +[source,sh] +---- +devenv --option env.cicd:bool true shell -- prek run --all-files --show-diff-on-failure +---- + +That is the lint job from `.github/workflows/lint.yml`, verbatim. Reach for it when a hook passes locally and fails in CI, or to lint without pulling the VS Code closure at all. + +== Local overrides + +devenv reads two files that let a machine differ from the repository: `devenv.local.nix` for Nix-level overrides, and `.env` for environment variables, which this environment has enabled. + +[source,nix] +---- +# devenv.local.nix +{ ... }: +{ + env.SOME_TOKEN = "..."; +} +---- + +WARNING: Neither file is in `.gitignore` here. Keep them out of commits by hand, or add them before you write one. See the https://devenv.sh/files-and-variables/[devenv documentation] for what else they can set. + +Run `direnv reload` after changing either. + +== Troubleshooting + +`direnv: error .envrc is blocked`:: +Expected on a fresh clone and after any change to `.envrc`. Run `direnv allow`. + +`devenv: command not found` right after installing it:: +The profile script is sourced by login shells only. Open a new terminal. + +Nothing happens on `cd` into the repository:: +direnv is installed but not hooked into the shell. See https://direnv.net/docs/hook.html[the hook instructions]. + +The first shell is compiling rather than downloading:: +The binary cache is not in effect. Re-check `extra-substituters` and `extra-trusted-public-keys` in `/etc/nix/nix.conf`, and that the daemon was restarted afterwards. + +`open-govpress` exits with code 5:: +Electron could not find a display. Use the `open-govpress` script rather than the extracted binary -- the script supplies `xvfb-run`. + +A checksum mismatch after bumping the renderer:: +`govpressVersion`, `govpressUrl` and `govpressSha256` in `devenv.nix` and the three `GOVPRESS_` variables in `.github/workflows/render-docs.yml` are one version pinned in two places, and have to move together. + +Renders still use the old version after a bump:: +The extracted copy is keyed by version and should not go stale, but `rm -rf open-govpress/.extracted` forces a clean unpack. diff --git a/README.adoc b/README.adoc new file mode 100644 index 0000000..d310ee7 --- /dev/null +++ b/README.adoc @@ -0,0 +1,274 @@ +:lang: en +ifeval::["{lang}" == "en"] += Guidelines to open source software (according to Article 9 EMOTA) +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Hilfsmittel zu Open-Source-Software (gemäss Artikel 9 EMBAG) +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Outils relatifs aux logiciels open source (selon l'article 9 LMETA) +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Strumenti per il software open source (secondo l'articolo 9 LMeCA) +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Meds per software open source (tenor l'artitgel 9 EMBAG) +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// Black, not the colour mark the guidelines carry: this page describes the +// repository that holds them and is not itself one of them. +:title-logo-base: black +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Where CI publishes the rendered PDFs, written as `{url-site}` in all five +// body blocks. Shared like `{url-repo}` rather than per-language: the site +// carries every language behind one chooser, so there is nothing to localise +// in the address itself. +:url-site: https://swiss.github.io/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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]. + +Every document in this repository carries all five languages -- English, German, French, Italian and Romansh -- in a single AsciiDoc file. The German, French, Italian and Romansh texts are *unreviewed translations*; see link:TRANSLATING.adoc[TRANSLATING.adoc] before editing them. + +For a complete list of documents, see: link:docs/index.adoc[Tools for Publishing Open Source Software] + +The drafts are also rendered to PDF and published in all five languages at {url-site}[swiss.github.io/opensource-guidelines]. + +== 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. + +To build and check the sources on your own machine, see link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc]. + +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. Major changes between versions can be followed using the {url-repo}/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] +endif::[] + +ifeval::["{lang}" == "de"] +Dieses Repository enthält *laufend weiterentwickelte Entwürfe* von Hilfsmitteln, welche die Bundesverwaltung bei der Veröffentlichung von Open-Source-Code unterstützen. Die *offiziellen und verbindlichen Fassungen* sind in allen Amtssprachen auf der https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Website der Schweizerischen Bundeskanzlei] verfügbar. + +Jedes Dokument in diesem Repository enthält alle fünf Sprachen -- Englisch, Deutsch, Französisch, Italienisch und Rumantsch -- in einer einzigen AsciiDoc-Datei. Die deutschen, französischen, italienischen und rätoromanischen Texte sind *ungeprüfte Übersetzungen*; lesen Sie link:TRANSLATING.adoc[TRANSLATING.adoc], bevor Sie sie bearbeiten. + +Eine vollständige Liste der Dokumente finden Sie unter: link:docs/index.adoc[Hilfsmittel zur Veröffentlichung von Open-Source-Software] + +Die Entwürfe werden zudem als PDF gerendert und in allen fünf Sprachen unter {url-site}[swiss.github.io/opensource-guidelines] veröffentlicht. + +== Gesetzliche Pflichten und Verantwortung + +Gemäss https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[Artikel 9 EMBAG] ist die Bundesverwaltung *grundsätzlich verpflichtet, ihre Software als Open Source zu veröffentlichen.* Jede Bundesbehörde trägt eigenständig die Verantwortung für die Einhaltung dieser Pflicht, einschliesslich der öffentlichen Bereitstellung des Quellcodes. + +== Mitwirkung + +Beiträge aus der Open-Source-Community und von weiteren Interessierten zu diesen Hilfsmitteln sind sehr willkommen. Haben Sie einen Verbesserungsvorschlag? Sie können: + +. Das Repository forken +. Ihren Feature-Branch erstellen (`git checkout -b feature/AmazingFeature`) +. Ihre Änderungen committen (`git commit -m 'Add some AmazingFeature'`) +. Auf den Branch pushen (`git push origin feature/AmazingFeature`) +. Einen Pull Request eröffnen + +Alternativ können Sie auch einfach ein Issue eröffnen. + +Wie Sie die Quellen auf Ihrem eigenen Rechner bauen und prüfen, steht in link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc]. + +NOTE: Sie können auch auf *Deutsch, Französisch oder Italienisch* schreiben und dort, wo es sinnvoll ist, auf die https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Dokumente in den Amtssprachen] verweisen. + +== Änderungen + +Werden *wesentliche Änderungen* vorgeschlagen, so durchlaufen sie das übliche Prüfverfahren der Bundeskanzlei und werden nach der Genehmigung übersetzt und auf der https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Website der Schweizerischen Bundeskanzlei] veröffentlicht. Die betreffenden Dokumente erhalten anschliessend eine neue Versionsnummer. Wesentliche Änderungen zwischen den Versionen lassen sich anhand der {url-repo}/releases[Release]-Notizen nachvollziehen. + +*Geringfügige Änderungen* fliessen regelmässig in die offiziellen PDF-Publikationen auf der https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[Website der Schweizerischen Bundeskanzlei] ein. + +== Lizenz + +Diese Hilfsmittel stehen unter der *CC0 1.0 Universal-Lizenz*. Einzelheiten finden Sie in der Datei `LICENSE`. + +== Kontakt + +mailto:opensource@bk.admin.ch[opensource@bk.admin.ch] +endif::[] + +ifeval::["{lang}" == "fr"] +Ce dépôt contient des *projets en cours d'élaboration* d'outils destinés à soutenir l'administration fédérale dans la publication de code open source. Les *versions officielles et contraignantes* sont disponibles dans toutes les langues officielles sur le https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[site de la Chancellerie fédérale suisse]. + +Chaque document de ce dépôt contient les cinq langues -- anglais, allemand, français, italien et romanche -- dans un seul fichier AsciiDoc. Les textes allemand, français, italien et romanche sont des *traductions non vérifiées* ; veuillez lire link:TRANSLATING.adoc[TRANSLATING.adoc] avant de les modifier. + +Pour la liste complète des documents, voir : link:docs/index.adoc[Outils pour la publication de logiciels open source] + +Les projets sont également rendus en PDF et publiés dans les cinq langues sur {url-site}[swiss.github.io/opensource-guidelines]. + +== Obligations légales et responsabilité + +Conformément à l'https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[article 9 LMETA], l'administration fédérale est *en principe tenue de publier ses logiciels en open source.* Chaque autorité fédérale est responsable de manière autonome du respect de cette obligation, y compris de la mise à disposition publique du code source. + +== Contribuer + +Les contributions de la communauté open source et des autres parties prenantes à ces outils sont très appréciées. Vous avez une suggestion d'amélioration ? Vous pouvez : + +. Forker le dépôt +. Créer votre branche de fonctionnalité (`git checkout -b feature/AmazingFeature`) +. Valider vos modifications (`git commit -m 'Add some AmazingFeature'`) +. Pousser la branche (`git push origin feature/AmazingFeature`) +. Ouvrir une pull request + +Vous pouvez également ouvrir simplement une issue. + +Pour générer et vérifier les sources sur votre propre machine, voir link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc]. + +NOTE: Vous pouvez aussi écrire en *allemand, français ou italien* et renvoyer, le cas échéant, aux https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[documents dans les langues officielles]. + +== Modifications + +Lorsque des *modifications importantes* sont proposées, elles suivent la procédure d'examen habituelle de la Chancellerie fédérale et sont, après approbation, traduites et publiées sur le https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[site de la Chancellerie fédérale suisse]. Les documents concernés reçoivent ensuite un nouveau numéro de version. Les modifications importantes entre les versions peuvent être suivies au moyen des notes de {url-repo}/releases[publication]. + +Les *modifications mineures* sont régulièrement intégrées aux publications PDF officielles sur le https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[site de la Chancellerie fédérale suisse]. + +== Licence + +Ces outils sont placés sous la *licence CC0 1.0 Universal*. Pour les détails, voir le fichier `LICENSE`. + +== Contact + +mailto:opensource@bk.admin.ch[opensource@bk.admin.ch] +endif::[] + +ifeval::["{lang}" == "it"] +Questo repository contiene *bozze in continua evoluzione* di strumenti destinati a sostenere l'Amministrazione federale nella pubblicazione di codice open source. Le *versioni ufficiali e vincolanti* sono disponibili in tutte le lingue ufficiali sul https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[sito della Cancelleria federale svizzera]. + +Ogni documento di questo repository contiene tutte e cinque le lingue -- inglese, tedesco, francese, italiano e romancio -- in un unico file AsciiDoc. I testi tedesco, francese, italiano e romancio sono *traduzioni non verificate*; consultate link:TRANSLATING.adoc[TRANSLATING.adoc] prima di modificarli. + +Per l'elenco completo dei documenti si veda: link:docs/index.adoc[Strumenti per la pubblicazione di software open source] + +Le bozze sono inoltre rese in PDF e pubblicate in tutte e cinque le lingue su {url-site}[swiss.github.io/opensource-guidelines]. + +== Obblighi legali e responsabilità + +Conformemente all'https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[articolo 9 LMeCA], l'Amministrazione federale è *tenuta in linea di principio a pubblicare il proprio software come open source.* Ogni autorità federale è responsabile in modo autonomo del rispetto di tale obbligo, compresa la messa a disposizione pubblica del codice sorgente. + +== Contribuire + +I contributi della community open source e delle altre parti interessate a questi strumenti sono molto apprezzati. Avete un suggerimento di miglioramento? Potete: + +. Forkare il repository +. Creare il vostro feature branch (`git checkout -b feature/AmazingFeature`) +. Eseguire il commit delle modifiche (`git commit -m 'Add some AmazingFeature'`) +. Effettuare il push sul branch (`git push origin feature/AmazingFeature`) +. Aprire una pull request + +In alternativa potete semplicemente aprire una issue. + +Per compilare e verificare i sorgenti sul vostro computer, si veda link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc]. + +NOTE: Potete scrivere anche in *tedesco, francese o italiano* e rinviare, ove opportuno, ai https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[documenti nelle lingue ufficiali]. + +== Modifiche + +Quando vengono proposte *modifiche sostanziali*, esse seguono la consueta procedura di esame della Cancelleria federale e, una volta approvate, vengono tradotte e pubblicate sul https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[sito della Cancelleria federale svizzera]. I documenti interessati ricevono poi un nuovo numero di versione. Le modifiche sostanziali tra le versioni possono essere seguite mediante le note di {url-repo}/releases[release]. + +Le *modifiche minori* confluiscono regolarmente nelle pubblicazioni PDF ufficiali sul https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[sito della Cancelleria federale svizzera]. + +== Licenza + +Questi strumenti sono pubblicati sotto la *licenza CC0 1.0 Universal*. Per i dettagli si veda il file `LICENSE`. + +== Contatto + +mailto:opensource@bk.admin.ch[opensource@bk.admin.ch] +endif::[] + +ifeval::["{lang}" == "rm"] +Quest repositori cuntegna *sbozzas ch'èn vegnidas sviluppadas vinavant* da meds che sustegnan l'administraziun federala en la publicaziun da code open source. Las *versiuns ufficialas e liantas* èn disponiblas en tuttas linguas ufficialas sin la https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[pagina d'internet da la Chanzlia federala svizra]. + +Mintga document da quest repositori cuntegna tuttas tschintg linguas -- englais, tudestg, franzos, talian e rumantsch -- en ina suletta datoteca AsciiDoc. Ils texts tudestg, franzos, talian e rumantsch èn *translaziuns betg verifitgadas*; legiai link:TRANSLATING.adoc[TRANSLATING.adoc] avant che elavurar els. + +Ina glista cumpletta dals documents chattais Vus sut: link:docs/index.adoc[Meds per publitgar software open source] + +Las sbozzas vegnan ultra da quai renderisadas sco PDF e publitgadas en tuttas tschintg linguas sut {url-site}[swiss.github.io/opensource-guidelines]. + +== Obligaziuns legalas e responsabladad + +Tenor l'https://www.fedlex.admin.ch/eli/cc/2023/682/de#art_9[artitgel 9 EMBAG] è l'administraziun federala *fundamentalmain obligada da publitgar ses software sco open source.* Mintga autoritad federala porta independentamain la responsabladad per l'observaziun da questa obligaziun, inclusiv la messa a disposiziun publica dal code da funtauna. + +== Cooperaziun + +Contribuziuns da la communitad open source e d'ulteriurs interessads a quests meds èn fitg bainvegnidas. Avais Vus ina proposta da meglierament? Vus pudais: + +. Forkar il repositori +. Crear Voss feature-branch (`git checkout -b feature/AmazingFeature`) +. Committar Vossas midadas (`git commit -m 'Add some AmazingFeature'`) +. Pushar sin il branch (`git push origin feature/AmazingFeature`) +. Avrir ina pull request + +Alternativamain pudais Vus era simplamain avrir in issue. + +Co ch'i vegn bajegià e controllà las funtaunas sin Voss agen computer, chattais Vus en link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc]. + +NOTE: Vus pudais era scriver per *tudestg, franzos u talian* e renviar, nua ch'igl è sensa, als https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[documents en las linguas ufficialas]. + +== Midadas + +Sche *midadas essenzialas* vegnan proponidas, passan ellas il process da controlla usità da la Chanzlia federala e vegnan, suenter l'approvaziun, translatadas e publitgadas sin la https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[pagina d'internet da la Chanzlia federala svizra]. Ils documents pertutgads survegnan lura in nov numer da versiun. Midadas essenzialas tranter las versiuns pon vegnir suandadas cun agid da las notizias da {url-repo}/releases[release]. + +*Midadas pitschnas* fluescha regularmain en las publicaziuns PDF ufficialas sin la https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software/hilfsmittel_oss.html[pagina d'internet da la Chanzlia federala svizra]. + +== Licenza + +Quests meds èn suttamess a la *licenza CC0 1.0 Universal*. Detagls chattais Vus en la datoteca `LICENSE`. + +== Contact + +mailto:opensource@bk.admin.ch[opensource@bk.admin.ch] +endif::[] 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/TRANSLATING.adoc b/TRANSLATING.adoc new file mode 100644 index 0000000..5964843 --- /dev/null +++ b/TRANSLATING.adoc @@ -0,0 +1,219 @@ +:lang: en +ifeval::["{lang}" == "en"] += Translating these guidelines +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +:govpress-style: report +// Black, not the colour mark the guidelines carry: contributor documentation, +// addressed to whoever works on this repository rather than to its readers. +:title-logo-base: black +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +// Contributor documentation, not a guideline: there is no translated body, so +// without this the English text below would be rendered once per language and +// take a row on each of the five index pages. render-docs.sh reads the +// attribute and builds the document only in the languages it names. Set by this +// file and by DEVENV-SETUP.adoc, the two contributor documents; every guideline +// in docs/ omits it and is built in all five. +:l10n-languages: en +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +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. + +Two kinds of file are outside that rule. `docs/partials/` holds fragments, which are one file per language; they have a section of their own below. The contributor documentation at the repository root -- this page and link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc] -- is English-only, and says so with `:l10n-languages: en`. + +One five-language document is easy to overlook because it does not sit in `docs/` with the others: `docs/assets/em002-2/md/README_template.adoc`, the README template Em002-2 hands out. `render-docs` publishes it like any other document, and it needs translating like any other document. + +== How a document is structured + +// The preprocessor runs inside listing blocks too, so every `ifeval::`, +// `endif::[]` and `include::` below is escaped with a backslash that +// asciidoctor eats again on the way out. The two lines carrying a callout are +// the exception: the trailing `` already stops them matching the directive +// pattern, and a backslash there would be printed. +[source,asciidoc] +---- +:lang: en <1> +\ifeval::["{lang}" == "en"] += Em002-5 EMOTA and OSS Factsheet <2> +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +\endif::[] +\ifeval::["{lang}" == "de"] += Em002-5 Merkblatt EMBAG und OSS +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +\endif::[] +…fr, it, rm… +:govpress-style: report <3> +:title-logo-base: color +: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> The *title* and the two *Kennzeichnung* lines are per-language. +<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`. Nothing anywhere reduces a region subtag to its base: `open-govpress render --lang de-CH` exits with `unknown --lang "de-CH"`, and a document whose own `:lang:` is `de-CH` fails on its caption include, which is resolved by exact filename. No `ifeval::` would match it either. + +Further attributes are shared and must survive translation unchanged: `:revnumber:` and `:revdate:`, which date the document; `:url-repo:`, the repository URL written once in the header and referenced as `+{url-repo}+` in the body of eight documents; and `:url-site:`, where CI publishes the rendered PDFs, referenced the same way in each of the README's five blocks. Translate neither an attribute name nor a reference -- `+{url-repo}+` is an attribute reference, not text, and expanding it by hand puts the URL back in 64 places. + +=== The Kennzeichnung + +Captions, the TOC heading and admonition labels are localised by open-govpress from the active language. Leave them alone. + +The *Kennzeichnung* on the title page is stated by the document itself. Lines 1 and 2 sit in the per-language blocks and must read exactly: + +[options="header",cols="1,2,3"] +|=== +|lang |line1 |line2 + +|en |Federal Chancellery FCh |Digital Transformation and ICT Steering DTI +|de |Bundeskanzlei BK |Digitale Transformation und IKT-Lenkung DTI +|fr |Chancellerie fédérale ChF |Transformation numérique et gouvernance de l'informatique TNI +|it |Cancelleria federale CaF |Trasformazione digitale e governance delle TIC TDT +|rm |Chanzlia federala ChF |Transfurmaziun digitala e direcziun da las TIC TDT +|=== + +Sector names are from the Federal Chancellery's own pages -- https://www.bk.admin.ch/de/bereich-dti[de], https://www.bk.admin.ch/fr/transformation-numerique-et-gouvernance-de-linformatique[fr], https://www.bk.admin.ch/it/trasformazione-digitale-e-governance-delle-tic[it], https://www.bk.admin.ch/en/dti-sector[en], https://www.bk.admin.ch/bk/rm/home/digitale-transformation-ikt-lenkung.html[rm]. Note the sector abbreviation differs per language: *DTI* in German and English, *TNI* in French, *TDT* in Italian _and Romansh_. + +The logo above those lines is picked by `:title-logo-base:`, which is shared rather than per-language: the asset is the same in all five. The Em002 documents and the README template Em002-2 hands out carry `color`. This page, link:DEVENV-SETUP.adoc[DEVENV-SETUP.adoc], the repository README and the `docs/index.adoc` language index carry `black`, being documentation *about* the guidelines rather than part of them. open-govpress takes `colour` as a synonym and falls back to `black` for anything else, the attribute being absent included -- so a new document that says nothing gets the black mark by default rather than by decision. + +== Building + +[source,sh] +---- +render-docs # all five languages into build/ +render-docs de rm # just those two +---- + +Check a single document while translating it: + +[source,sh] +---- +for l in en de fr it rm; do + open-govpress render --lang "$l" -o "build/$l/" docs/em002-5.adoc +done +---- + +The trailing slash matters. With one input file, `-o` is a directory only when the path ends in a separator or already exists, so `-o build/de` on a clone that has never rendered writes a PDF into a *file* called `build/de`. + +A near-empty PDF means that language's body block is missing. A malformed `endif::[]` does not get that far: asciidoctor reports it as an error and `tools/check-asciidoc.sh` fails the commit before anything is rendered. The third cause is asking for a language the document opted out of. + +A document that is not translated -- contributor documentation, or a guideline whose other four blocks are not written yet -- names the languages it has: + +[source,asciidoc] +---- +:l10n-languages: en +---- + +`render-docs` then builds it only in those languages, instead of rendering the English text five times and giving it a row on each of the five index pages. It still has to *parse* in all five, because `tools/check-asciidoc.sh` checks every language regardless; the guards simply yield an empty body. + +== Terminology + +[options="header",cols="1,1,1,1,1"] +|=== +|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 TDT |sectur TDT +|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 +|SR 172.019 |SR 172.019 |RS 172.019 |RS 172.019 |CS 172.019 +|Strategic Guidelines (Em002) |Strategische Leitlinien |Lignes directrices stratégiques |Linee guida strategiche |Directivas strategicas +|guidelines (Em002-3/-4/-7) |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) +|=== + +The law-collection designator is translated along with everything else -- `SR` in German and English, `RS` in French and Italian, `CS` in Romansh -- so `+footnote:[SR 172.019]+` is correct in two languages out of five and wrong in the other three. + +*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 CS 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:[]+`, `image::` macros, `|===` table delimiters and cell counts, `a|` cell prefixes, inline roles such as `+[.underline]#…#+`, `'''` rules, `+` line breaks, and the bare block attribute lines that sit above a block and are the easiest thing in the file to lose: `[%interactive]` above a `* [ ]` list is what turns those items into real form fields in the PDF, and `[.landscape]` above a wide table is what gives it a turned page. +* *Use unconstrained bold where a footnote abuts it.* `+*Digital Switzerland Strategy*footnote:[…]+` never closes its bold, and the asterisks reach the page as literal text; write `+**Digital Switzerland Strategy**footnote:[…]+` instead. The same goes for italic. Nothing warns you -- the document renders, with asterisks in it. +* *Translate image alt text.* Image _paths_ are per-language where the picture contains words: `assets/four-cs/four-cs.de.svg` belongs in the German block and nowhere else. There are two such sets, `four-cs..svg` and `four-cs-cases..svg`. Both are generated -- edit `tools/make-four-cs-svg.sh` and re-run it, never the `.svg` files. +* *Translate `+link:…[display text]+`, never the target.* Targets are relative `.pdf` paths because the links are followed inside the rendered PDFs, where the documents of one language sit side by side in one directory. They resolve correctly as of open-govpress 0.0.14, which rewrites each annotation back to the authored string after printing; before that the CLI baked in its own loopback origin and every one of the 1,100 targets led nowhere. Nothing was rewritten to work around it, which is why nothing had to be undone. +* *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, which is the majority: `intranet.bbl.admin.ch`, `www.bkb.admin.ch`, `intranet.dti.bk.admin.ch` and `beschaffung.admin.ch` are German-only and are cited as such in the English source too. *The Romansh block keeps the German segment* almost throughout -- admin.ch publishes very little in Romansh, and 42 of the 51 admin.ch URLs in that block point at `/de` on purpose. +* *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. + +== Diagrams + +Diagrams are Mermaid blocks, opened with `+[mermaid,align="center",alt="…"]+` and delimited by `....`, never `----`. Their labels are text you translate like any other. Five rules, each of which has bitten: + +* *Never add `theme:`, `themeVariables`, a `---` frontmatter block or an `+%%{init: …}%%+` directive.* open-govpress generates the whole Mermaid palette from the document's own design tokens -- a couple of hundred theme variables from sixty-odd tokens; any inline theme override throws all of it away and the diagram renders off-brand. +* *Never set `layout: elk`.* The ELK package is not bundled, and the block would fail to load its layout. +// The counter-example is the bare label rather than `Fin([Ende])`, because a +// bracketed token after `(` is exactly how the prose cites a reference key: +// check-asciidoc.sh would report `Ende` as a citation with no entry behind it. +* *`end` is a reserved word* and silently breaks a flowchart. Quote any node label that is just that word: `+Fin(["Ende"])+`, never a bare `+[Ende]+`. +* *Every block needs `alt=`*, translated. Without it the diagram reaches the PDF as an unlabelled figure and a screen reader reads its node labels in layout order, which is word salad. +* *`block-beta` does not take flowchart edge labels.* In a `block-beta` diagram an edge is written `+A-- "label" -->B+`; the flowchart spelling `+A -->|"label"| B+` does not fail, which is the dangerous part -- Mermaid draws an extra block containing the literal text `+|"label"|+` and runs the arrow into it, leaving the intended target unconnected. + +A block that fails to parse degrades to a listing of its own source rather than disappearing, so check the rendered PDF: Mermaid keywords in the text layer mean a diagram did not draw. Not every breakage announces itself that way, though -- the `block-beta` case above parses cleanly and draws the wrong picture -- so look at the figure, not just the log. + +Colour is used only where it carries meaning that the structure does not -- the licence-compatibility graph in Em002-3, the document map, and the highlighted node in Em002-4's digital-sovereignty diagram. Those three carry a `classDef` with an explicit `fill:`; copy it across untouched. Elsewhere the near-monochrome house palette is correct, not a bug. + +== Shared fragments + +`docs/partials/` holds fragments that several documents `include::`, one file per language -- the map of Art. 9 documents, which four documents show and `Em002` shows twice, and the shared `abbreviations..adoc`, `glossary..adoc` and `references..adoc` lists. *Translate the partial, not the inclusion*, and keep the language of the file matching the `ifeval::` block that includes it. They are per-language in exactly the way `document-map..adoc` is: five files, one per language, never one file with five blocks inside it. + +A fragment is not a document: `render-docs` and `tools/site-index.sh` exclude `docs/partials/` so it never becomes a PDF of its own. A missing `include::` still writes a PDF -- only a fatal conversion writes nothing -- but it is not silent: the renderer exits 3 for an unresolved include, so the exit status is the signal to watch. + +=== Tagged partials + +Several documents share one abbreviation list, one glossary and one set of reference entries, but no document wants all of any of them, so each takes the slice it needs by tag: + +[source,asciidoc] +---- +\include::partials/glossary.en.adoc[tags=gloss-em002-7] +---- + +and the partial marks its slices out: + +[source,asciidoc] +---- +// tag::gloss-em002-7[] +[St2024]:: +Report on digital sovereignty … +// end::gloss-em002-7[] +---- + +* *`+// tag::name[]+` and `+// end::name[]+` are structure, not comments.* They render as nothing at all, which is exactly why they get tidied away. Copy them across verbatim, never translate a tag name, and close nested regions innermost first -- a region opened inside another has to end before it. Crossing them or leaving one open is a `WARNING`, so `tools/check-asciidoc.sh` stops the commit. +* *One tag per include.* Every include in this repository selects exactly one region, and that is the policy, because the separator is a trap: `tags=a,b` is neither an error nor a warning. The unquoted comma ends the attribute, so it means `tags=a` and everything under `b` disappears in silence -- taking the two `references` regions as a test, `tags=a;b` selects 46 entries and `tags=a,b` selects 19, with nothing said either way by asciidoctor or open-govpress at any log level. `;` is the separator, `tags="a,b"` works because the quotes keep the comma inside the value, and one tag avoids the question. +* *An entry keeps its `+[Key]::+` shape.* The prose cites it as `[St2024]`, and AsciiDoc knows of no connection between the two, so a citation whose entry a tag did not select renders as an ordinary bracketed label with nothing behind it. Translate the description, never the key and never its brackets. `tools/check-asciidoc.sh` is the only thing that will notice -- but it compares the citations of the whole corpus against the entries of the whole corpus, once per language, so it catches a key that no list defines and misses one that went missing from a single language's list while another still defines it. That case is on you. + +== 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/devenv.lock b/devenv.lock new file mode 100644 index 0000000..753486b --- /dev/null +++ b/devenv.lock @@ -0,0 +1,106 @@ +{ + "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" + } + }, + "flake-compat": { + "flake": false, + "locked": { + "lastModified": 1767039857, + "narHash": "sha256-vNpUSpF5Nuw8xvDLj2KCwwksIbjua2LZCqhV1LNRDns=", + "owner": "NixOS", + "repo": "flake-compat", + "rev": "5edf11c44bc78a0d334f6334cdaf7d60d732daab", + "type": "github" + }, + "original": { + "owner": "NixOS", + "repo": "flake-compat", + "type": "github" + } + }, + "git-hooks": { + "inputs": { + "flake-compat": "flake-compat", + "nixpkgs": [ + "nixpkgs" + ] + }, + "locked": { + "lastModified": 1789514889, + "narHash": "sha256-PFD1nxptCXJyJoiYO1gf/5Vv43yqGpHtMC6LUhl9/pQ=", + "owner": "cachix", + "repo": "git-hooks.nix", + "rev": "59f4ca0d063a1a3ec722c88b51a33004862e5379", + "type": "github" + }, + "original": { + "owner": "cachix", + "repo": "git-hooks.nix", + "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", + "git-hooks": "git-hooks", + "nixpkgs": "nixpkgs", + "pre-commit-hooks": [ + "git-hooks" + ] + } + } + }, + "root": "root", + "version": 7 +} diff --git a/devenv.nix b/devenv.nix new file mode 100644 index 0000000..0d48e35 --- /dev/null +++ b/devenv.nix @@ -0,0 +1,286 @@ +{ + pkgs, + lib, + config, + ... +}: + +let + # open-govpress (https://github.com/swiss/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.19"; + govpressUrl = "https://github.com/736-c41-2c1-e464fc974/opensource-guidelines/releases/download/open-govpress-v${govpressVersion}/open-govpress-${govpressVersion}-linux-x64.tar.gz"; + govpressSha256 = "946c7f187ec1eb109681e89cbd9aebcba869e560df8f7493ddbecd3540a9b679"; + + 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 + ]; + }; + + # A deliberately small bundle: the editor counterpart of the git hooks, so + # that the things the hooks reject are visible while typing rather than at + # commit time. Every entry below pairs with a hook in git-hooks.hooks, except + # direnv (which is how the shell gets loaded at all) and AsciiDoc (which is + # what this repository is written in). + # + # nixpkgs carries all of these, so none of them need the + # extensionsFromVscodeMarketplace escape hatch and its pinned sha256. + vscodeWithExtensions = pkgs.vscode-with-extensions.override { + vscodeExtensions = with pkgs.vscode-extensions; [ + # Syntax highlighting and live preview for the 15 documents in docs/. + asciidoctor.asciidoctor-vscode + + # Loads this devenv automatically, instead of requiring `devenv shell`. + mkhl.direnv + + # Honours .editorconfig while typing -> editorconfig-checker hook. + editorconfig.editorconfig + + # devenv.nix itself. Set nix.formatterPath to nixfmt to match the hook. + jnoortheen.nix-ide + + # Inline shellcheck for tools/*.sh. Note the hook runs it as + # `-x -o all`, which is stricter than this extension's default, so a + # clean editor does not guarantee a clean commit. + timonwong.shellcheck + + # The workflows and publiccode.yml -> yamllint hook. + redhat.vscode-yaml + + # Schema validation and expression completion for the workflows in + # .github/workflows/. CI is the publishing pipeline here, so those two + # files carry more weight than their size suggests. + github.vscode-github-actions + ]; + }; +in +{ + env = { + DO_NOT_TRACK = 1; + + # Interactive devenvs get the editor; CI does not. The lint workflow runs + # `devenv shell`, and without this it would pull the whole VS Code closure + # on every push just to run the hooks. + cicd = lib.mkDefault false; + }; + + 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 + ] + # + # Interactive devenvs only: these are never needed to render or to lint, + # and CI should not pay for them. Enter CI/CD mode with + # `devenv --option env.cicd:bool true ...`. + # + ++ lib.optionals (!config.env.cicd) [ + vscodeWithExtensions + ]; + + # https://devenv.sh/git-hooks/ + # + # Recommended by git-hooks.nix, and much faster than the Python pre-commit on + # a repository this small, where process startup dominates. + git-hooks.package = pkgs.prek; + + git-hooks.hooks = { + # Line endings and whitespace. The .adoc sources came through a + # Word -> Markdown -> AsciiDoc migration, which is exactly the kind of + # pipeline that reintroduces CRLF one file at a time. + dos2unix = { + enable = true; + entry = "${lib.getExe pkgs.dos2unix}"; + args = [ "--info=c" ]; + }; + + trim-trailing-whitespace.enable = true; + end-of-file-fixer.enable = true; + + # The workflow invokes tools/*.sh directly (`run: tools/site-index.sh`), so + # a dropped exec bit breaks the Pages deploy rather than anything local. + check-executables-have-shebangs.enable = true; + check-shebang-scripts-are-executable = { + enable = true; + # .envrc is sourced by direnv, never executed. Its shebang is there to + # get shell highlighting and the shellcheck directive on line 2, so + # marking it executable would be wrong in the way this hook warns about. + excludes = [ "^\\.envrc$" ]; + }; + + check-symlinks.enable = true; + + editorconfig-checker.enable = true; + + nixfmt.enable = true; + + # devenv.lock is JSON, but identify classifies files by extension and does + # not know `.lock`, so it has to be named explicitly to be checked at all. + check-json = { + enable = true; + files = "(\\.json|devenv\\.lock)$"; + types = [ "file" ]; + }; + + # truthy check-keys is off because GitHub Actions' `on:` trigger key is + # read as the YAML 1.1 boolean `true`; every workflow file would fail. + yamllint = { + enable = true; + settings = { + strict = true; + configData = "{ extends: default, rules: { document-start: disable, line-length: {max: 165}, truthy: {check-keys: false} } }"; + }; + }; + + ripsecrets.enable = true; + + shellcheck = { + enable = true; + args = [ + "-x" + "-o" + "all" + ]; + }; + + # git-hooks.nix has no AsciiDoc linter of any kind -- the closest it ships + # are the prose linters (vale, proselint), which check style rather than + # syntax and would drown in false positives on four non-English languages. + # See the script for what this does and does not catch. + check-asciidoc = { + enable = true; + entry = "${config.devenv.root}/tools/check-asciidoc.sh"; + files = "\\.adoc$"; + types = [ "file" ]; + }; + }; + + # Print the output of the git hooks that `devenv test` runs, otherwise a + # failing hook only reports that it failed. + tasks."devenv:git-hooks:run".showOutput = true; + + 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`. + # + # The wrapper only passes down what has to come from Nix -- store paths and + # the pinned release -- because shell inside a Nix string is invisible to + # shellcheck and editorconfig-checker. The logic lives in the script, where + # the hooks can see it. + scripts.open-govpress = { + description = "Render .adoc documents (open-govpress render ... -o out.pdf)"; + exec = '' + GOVPRESS_VERSION='${govpressVersion}' \ + GOVPRESS_URL='${govpressUrl}' \ + GOVPRESS_SHA256='${govpressSha256}' \ + GOVPRESS_FHS='${lib.getExe govpressFHS}' \ + GOVPRESS_XVFB_RUN='${lib.getExe pkgs.xvfb-run}' \ + GOVPRESS_CURL='${lib.getExe pkgs.curl}' \ + GOVPRESS_SHA256SUM='${pkgs.coreutils}/bin/sha256sum' \ + exec '${config.devenv.root}/tools/open-govpress.sh' "''${@}" + ''; + }; + + scripts.render-docs = { + description = "Render every .adoc document in every language into build/ (render-docs [lang...])"; + exec = '' + exec '${config.devenv.root}/tools/render-docs.sh' "''${@}" + ''; + }; +} diff --git a/devenv.yaml b/devenv.yaml new file mode 100644 index 0000000..03edacc --- /dev/null +++ b/devenv.yaml @@ -0,0 +1,14 @@ +inputs: + # Required by the git-hooks.hooks block in devenv.nix. devenv does not pull + # this in on its own -- without the input, evaluating the module fails with + # "To use 'git-hooks', run: devenv inputs add git-hooks ...". + git-hooks: + url: github:cachix/git-hooks.nix + inputs: + nixpkgs: + follows: nixpkgs + nixpkgs: + url: github:cachix/devenv-nixpkgs/rolling + pre-commit-hooks: + follows: git-hooks +allowUnfree: true diff --git a/docs/assets/em002-2/md/README_template.adoc b/docs/assets/em002-2/md/README_template.adoc new file mode 100644 index 0000000..f6f531a --- /dev/null +++ b/docs/assets/em002-2/md/README_template.adoc @@ -0,0 +1,371 @@ +:lang: en +ifeval::["{lang}" == "en"] += README Template +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += README-Vorlage +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Modèle de README +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Modello di README +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Model da README +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +== 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 +endif::[] + +ifeval::["{lang}" == "de"] +== Projekttitel + +Eine kurze Beschreibung, was dieses Projekt tut und für wen es gedacht ist + +=== Funktionen + +* Umschalten zwischen hellem und dunklem Modus +* Live-Vorschauen +* Vollbildmodus +* Plattformübergreifend + +=== Dokumentation + +https://linktodocumentation[Dokumentation] + +=== Installation + +my-project mit npm installieren + +[source,bash] +---- + npm install my-project + cd my-project +---- + +=== Verwendung/Beispiele + +[source,javascript] +---- +import Component from 'my-project' + +function App() { + return +} +---- + +=== Screenshots oder Demo + +GIF einfügen oder Link zur Demo + +image::https://dummyimage.com/468x300?text=App+Screenshot+Here[App-Screenshot] + +=== Support + +Für Support schreiben Sie an fake@fake.com oder treten Sie unserem Slack-Kanal bei. + +=== Mitwirkung + +Beiträge sind jederzeit willkommen! + +Unter `contributing.md` finden Sie Hinweise für den Einstieg. + +Bitte halten Sie sich an den `code of conduct` dieses Projekts. + +=== Lizenz + +https://choosealicense.com/licenses/mit/[MIT] + +=== Roadmap + +* Unterstützung weiterer Browser +* Weitere Integrationen ergänzen +endif::[] + +ifeval::["{lang}" == "fr"] +== Titre du projet + +Une brève description de ce que fait ce projet et de son public cible + +=== Fonctionnalités + +* Bascule entre mode clair et mode sombre +* Aperçus en direct +* Mode plein écran +* Multiplateforme + +=== Documentation + +https://linktodocumentation[Documentation] + +=== Installation + +Installer my-project avec npm + +[source,bash] +---- + npm install my-project + cd my-project +---- + +=== Utilisation / exemples + +[source,javascript] +---- +import Component from 'my-project' + +function App() { + return +} +---- + +=== Captures d'écran ou démo + +Insérer un gif ou un lien vers la démo + +image::https://dummyimage.com/468x300?text=App+Screenshot+Here[Capture d'écran de l'application] + +=== Support + +Pour obtenir de l'aide, écrivez à fake@fake.com ou rejoignez notre canal Slack. + +=== Contribuer + +Les contributions sont toujours les bienvenues ! + +Voir `contributing.md` pour savoir comment commencer. + +Veuillez respecter le `code of conduct` de ce projet. + +=== Licence + +https://choosealicense.com/licenses/mit/[MIT] + +=== Feuille de route + +* Prise en charge de navigateurs supplémentaires +* Ajouter d'autres intégrations +endif::[] + +ifeval::["{lang}" == "it"] +== Titolo del progetto + +Una breve descrizione di ciò che fa questo progetto e a chi è destinato + +=== Funzionalità + +* Commutazione tra modalità chiara e scura +* Anteprime in tempo reale +* Modalità a schermo intero +* Multipiattaforma + +=== Documentazione + +https://linktodocumentation[Documentazione] + +=== Installazione + +Installare my-project con npm + +[source,bash] +---- + npm install my-project + cd my-project +---- + +=== Utilizzo / esempi + +[source,javascript] +---- +import Component from 'my-project' + +function App() { + return +} +---- + +=== Screenshot o demo + +Inserire una gif o un collegamento alla demo + +image::https://dummyimage.com/468x300?text=App+Screenshot+Here[Screenshot dell'applicazione] + +=== Supporto + +Per assistenza scrivete a fake@fake.com o entrate nel nostro canale Slack. + +=== Contribuire + +I contributi sono sempre benvenuti! + +Consultate `contributing.md` per sapere come iniziare. + +Vi preghiamo di attenervi al `code of conduct` di questo progetto. + +=== Licenza + +https://choosealicense.com/licenses/mit/[MIT] + +=== Roadmap + +* Supporto di ulteriori browser +* Aggiungere altre integrazioni +endif::[] + +ifeval::["{lang}" == "rm"] +== Titel dal project + +Ina curta descripziun da quai che quest project fa e per tgi ch'el è previs + +=== Funcziuns + +* Midar tranter il modus cler e stgir +* Previstas live +* Modus da maletg entir +* Sur pliras plattafurmas + +=== Documentaziun + +https://linktodocumentation[Documentaziun] + +=== Installaziun + +Installar my-project cun npm + +[source,bash] +---- + npm install my-project + cd my-project +---- + +=== Utilisaziun/exempels + +[source,javascript] +---- +import Component from 'my-project' + +function App() { + return +} +---- + +=== Screenshots u demo + +Inserir ina gif u in link a la demo + +image::https://dummyimage.com/468x300?text=App+Screenshot+Here[Screenshot da l'applicaziun] + +=== Support + +Per support scrivai a fake@fake.com u vegni en noss chanal Slack. + +=== Cooperaziun + +Contribuziuns èn adina bainvegnidas! + +Sut `contributing.md` chattais Vus indicaziuns per cumenzar. + +Tegnai p.pl. il `code of conduct` da quest project. + +=== Licenza + +https://choosealicense.com/licenses/mit/[MIT] + +=== Roadmap + +* Sustegn d'ulteriurs browsers +* Agiuntar ulteriuras integraziuns +endif::[] diff --git a/docs/assets/four-cs/four-cs-cases.de.svg b/docs/assets/four-cs/four-cs-cases.de.svg new file mode 100644 index 0000000..83c0f90 --- /dev/null +++ b/docs/assets/four-cs/four-cs-cases.de.svg @@ -0,0 +1,61 @@ + + Die 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (Nutzung) + Contribution + Creation + Collaboration + + Fall a) + Fall b) + diff --git a/docs/assets/four-cs/four-cs-cases.en.svg b/docs/assets/four-cs/four-cs-cases.en.svg new file mode 100644 index 0000000..8963e91 --- /dev/null +++ b/docs/assets/four-cs/four-cs-cases.en.svg @@ -0,0 +1,61 @@ + + The four Cs: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (Use) + Contribution + Creation + Collaboration + + case a) + case b) + diff --git a/docs/assets/four-cs/four-cs-cases.fr.svg b/docs/assets/four-cs/four-cs-cases.fr.svg new file mode 100644 index 0000000..1ea6a5d --- /dev/null +++ b/docs/assets/four-cs/four-cs-cases.fr.svg @@ -0,0 +1,61 @@ + + Les 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (utilisation) + Contribution + Creation + Collaboration + + cas a) + cas b) + diff --git a/docs/assets/four-cs/four-cs-cases.it.svg b/docs/assets/four-cs/four-cs-cases.it.svg new file mode 100644 index 0000000..7c98159 --- /dev/null +++ b/docs/assets/four-cs/four-cs-cases.it.svg @@ -0,0 +1,61 @@ + + Le 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (uso) + Contribution + Creation + Collaboration + + caso a) + caso b) + diff --git a/docs/assets/four-cs/four-cs-cases.rm.svg b/docs/assets/four-cs/four-cs-cases.rm.svg new file mode 100644 index 0000000..cd1f4db --- /dev/null +++ b/docs/assets/four-cs/four-cs-cases.rm.svg @@ -0,0 +1,61 @@ + + Ils 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (utilisaziun) + Contribution + Creation + Collaboration + + cas a) + cas b) + diff --git a/docs/assets/four-cs/four-cs.de.svg b/docs/assets/four-cs/four-cs.de.svg new file mode 100644 index 0000000..f385149 --- /dev/null +++ b/docs/assets/four-cs/four-cs.de.svg @@ -0,0 +1,58 @@ + + Die 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (Nutzung) + Contribution + Creation + Collaboration + diff --git a/docs/assets/four-cs/four-cs.en.svg b/docs/assets/four-cs/four-cs.en.svg new file mode 100644 index 0000000..517a04e --- /dev/null +++ b/docs/assets/four-cs/four-cs.en.svg @@ -0,0 +1,58 @@ + + The four Cs: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (Use) + Contribution + Creation + Collaboration + diff --git a/docs/assets/four-cs/four-cs.fr.svg b/docs/assets/four-cs/four-cs.fr.svg new file mode 100644 index 0000000..499d2d7 --- /dev/null +++ b/docs/assets/four-cs/four-cs.fr.svg @@ -0,0 +1,58 @@ + + Les 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (utilisation) + Contribution + Creation + Collaboration + diff --git a/docs/assets/four-cs/four-cs.it.svg b/docs/assets/four-cs/four-cs.it.svg new file mode 100644 index 0000000..51b4980 --- /dev/null +++ b/docs/assets/four-cs/four-cs.it.svg @@ -0,0 +1,58 @@ + + Le 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (uso) + Contribution + Creation + Collaboration + diff --git a/docs/assets/four-cs/four-cs.rm.svg b/docs/assets/four-cs/four-cs.rm.svg new file mode 100644 index 0000000..7f7e321 --- /dev/null +++ b/docs/assets/four-cs/four-cs.rm.svg @@ -0,0 +1,58 @@ + + Ils 4 C: Consumption, Contribution, Collaboration, Creation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Consumption + (utilisaziun) + Contribution + Creation + Collaboration + diff --git a/docs/assets/screenshots/document-map.png b/docs/assets/screenshots/document-map.png new file mode 100644 index 0000000..dee8efa Binary files /dev/null and b/docs/assets/screenshots/document-map.png differ diff --git a/docs/em002-1.adoc b/docs/em002-1.adoc new file mode 100644 index 0000000..f5e6e16 --- /dev/null +++ b/docs/em002-1.adoc @@ -0,0 +1,2665 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-1 Practical Guidelines for Open Source Software in the Federal Administration +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-1 Guida pratica per il software open source nell'Amministrazione federale +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-1 Guida pratica per software open source en l'administraziun federala +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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 {url-repo}/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.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.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.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] + +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.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.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.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.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.pdf[Em002-5 OSS Tools information sheet] + +Contributions of software to third parties and collaborations + +* 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. + +include::partials/document-map.en.adoc[] + +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 under one of approximately 80 licences recognised by the Open Source Initiative OSI _[OSI2024]_. 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:[https://en.wikipedia.org/wiki/Free_software[Free software -- Wikipedia]] + +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:[https://en.wikipedia.org/wiki/Proprietary_software[Proprietary software -- Wikipedia]] 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:[https://opensource.org/[Open Source Initiative]] + +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.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.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:[https://en.wikipedia.org/wiki/Source_code[Source code -- Wikipedia]] + +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:[https://en.wikipedia.org/wiki/Fork_(software_development)[Fork (software development) -- Wikipedia]] 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:[https://en.wikipedia.org/wiki/Contributor_License_Agreement[Contributor License Agreement -- Wikipedia]] 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:[https://en.wikipedia.org/wiki/Version_control[Version control -- Wikipedia]], also known as version control, is a tool that effectively manages changes and version numbers, particularly in software development. The free software Git footnote:[https://en.wikipedia.org/wiki/Git[Git -- Wikipedia]] for managing distributed SCM has become established. + +Open source software development (OSSD):: +In open source software development (OSSD) footnote:[https://en.wikipedia.org/wiki/Open-source_software_development[Open-source software development -- Wikipedia]], 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:[https://en.wikipedia.org/wiki/Software_Package_Data_Exchange[Software Package Data Exchange -- Wikipedia]] 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.pdf[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. + +{empty}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.'] + +{empty}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. + +{empty}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. + +{empty}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. + +{empty}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. + +{empty}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. + +{empty}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). + +{empty}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. + +{empty}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).] + +{empty}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. + +{empty}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. + +{empty}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). + +{empty}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. + +{empty}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.] + +{empty}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. + +{empty}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:[https://www.oss-studie.ch/[OSS Study]] _[OSS2024]_. + +{empty}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. + +{empty}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 the section 'Findability of OSS solutions'). + +{empty}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. + +{empty}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. + +{empty}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, The section 'Open Hub' 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. + +{empty}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.pdf[Em002-3 OSS Licensing Guidelines] and in link:em002-6.pdf[Em002-6 FAQ on OSS and Art. 9 EMOTA]. + +{empty}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. + +{empty}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.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.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.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.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.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.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.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 + +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 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 _[BITKOM2024]_ 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.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.pdf[Em002-3 OSS Licensing Guidelines]. + +== OSS procurement + +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'. + +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: + +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: + +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: + +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. + +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: 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.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.pdf[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 _[BITKOM2023]_. + +==== 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. +endif::[] + +ifeval::["{lang}" == "de"] +NOTE: 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 {url-repo}/tree/main[README]. + +== 1. Verwendung dieses Leitfadens + +Nach Artikel 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) ist der Bund verpflichtet, den Quellcode von Software offenzulegen, die er zur Erfüllung seiner Aufgaben entwickelt oder entwickeln lässt. footnote:[SR 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/de] Der Sektor DTI der Bundeskanzlei hat aus diesem gesetzlichen Auftrag in den Strategischen Leitlinien für Open-Source-Software übergeordnete Ziele abgeleitet. + +Dieses Dokument dient als Praxisleitfaden zu den rechtlichen und strategischen Vorgaben. Es soll die Verwaltungseinheiten des Bundes bei der Nutzung, Beschaffung und Freigabe von Open-Source-Software unterstützen. Es bietet allen Interessierten einen umfassenden Überblick über das Thema und verweist auf weiterführende Informationen in den übrigen Hilfsmitteln. + +Je nach Vorwissen und Bedarf können Sie die Leitfäden jedoch auch selektiv lesen, bevor Sie zu den anderen Hilfsmitteln übergehen. Die folgende Übersicht hilft Ihnen, den passenden Einstieg zu finden. Wenn Sie unsicher sind, empfiehlt es sich, zuerst den Leitfaden durchzulesen. + +=== Absicht / Anspruchsgruppen + +Allgemeine Einführung in Open-Source-Software + +* Kapitel Begriffe +* Kapitel Potenzial und Herausforderungen +* Kapitel Auffindbarkeit von OSS-Lösungen +* link:em002-5.pdf[Em002-5 Merkblatt OSS-Hilfsmittel] +* link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] +* link:em002-6.pdf[Em002-6 FAQ zu OSS] + +Allgemeine Einführung in das EMBAG für Entscheidungsträgerinnen und Entscheidungsträger + +* link:em002-5.pdf[Em002-5 Merkblatt OSS-Hilfsmittel] +* link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] + +Reine Beschaffung von zu nutzender Software + +* Kapitel Reifegrade für OSS in der Bundesverwaltung +* Kapitel Nutzung unveränderter Open-Source-Software +* link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und OSS] +* Merkblatt Softwarebeschaffung und Art. 9 EMBAG [KBB-MB] +* Wegleitung OSS in der Beschaffung [BBL-WL] + +Neue IT-Entwicklung und Freigabe + +* Kapitel Entwicklung mit Open-Source-Komponenten und Freigabe des Quellcodes +* Kapitel Mitarbeit in offenen Projekten (Contribution) +* link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] +* link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] + +Beschaffung von zu erstellender Software (Dienstleistung oder Werk) + +* Kapitel Reifegrade für OSS in der Bundesverwaltung +* Kapitel Entwicklung mit Open-Source-Komponenten und Freigabe des Quellcodes +* Kapitel Mitarbeit in offenen Projekten (Contribution) +* link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und OSS] +* Werkzeugkasten BBL, einschliesslich der Wegleitung Open Source in der Beschaffung +* Lern- und Vorlagenplattform der öffentlichen Verwaltung des KBB (www.perimap.admin.ch) einschliesslich Softwarebeschaffung und Art. 9 EMBAG [KBB-MB] +* Wegleitung OSS in der Beschaffung [BBL-WL] +* link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] +* link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] + +Rechtliche Abklärungen für die Freigabe + +* link:em002-6.pdf[Em002-6 Häufig gestellte Fragen zur Veröffentlichung von OSS (OSS-FAQ)] +* link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] + +Arbeitsgrundsätze für Projektleitende + +* https://www.hermes.admin.ch/[HERMES-Dokumente] +* link:em002-5.pdf[Em002-5 Merkblatt OSS-Hilfsmittel] + +Beiträge von Software an Dritte und Zusammenarbeit + +* link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] +* link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und OSS] +* link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] + +Die folgende Grafik gibt einen Überblick über die für OSS relevanten Dokumente in der Bundesverwaltung. + +include::partials/document-map.de.adoc[] + +Abbildung 1: Übersicht über die OSS-Hilfsmittel im Zusammenhang mit Art. 9 EMBAG + +== Begriffe + +Open-Source-Software:: +Software gilt als Open-Source-Software (OSS), wenn sie unter einer der rund 80 von der Open Source Initiative OSI anerkannten Lizenzen veröffentlicht wird _[OSI2024]_. Konkret legt die Definition von Open Source zehn Kriterien fest, die alle Open-Source-Lizenzen erfüllen müssen _[Pe1999]_. Diese lassen sich im Wesentlichen in vier Punkten zusammenfassen: ++ +. Die Software darf zu jedem Zweck genutzt werden. +. Der Quellcode der Software ist frei zugänglich. +. Die Software darf uneingeschränkt kopiert und verbreitet werden. +. Die Software darf unter bestimmten Bedingungen verändert und in veränderter Form verbreitet werden. + +Freie Software:: +Vor dem Begriff «Open Source» führte die Free Software Foundation (FSF) in den 1980er-Jahren das Konzept der «freien Software» ein. Im Kern erfüllt freie Software die Bedingungen von Open-Source-Software, zielt aber darauf ab, dass die Software stets frei zugänglich bleibt und nach Möglichkeit nicht in proprietäre Software integriert wird. footnote:[https://de.wikipedia.org/wiki/Freie_Software[Freie Software -- Wikipedia]] + +Proprietäre Software:: +Bei proprietärer Software entwickelt ein Anbieter Software und verkauft der Nutzerin oder dem Nutzer eine Nutzungslizenz. In der Regel kennen die Nutzenden den Softwarecode nicht und dürfen die Software weder weiterverbreiten noch verändern. Sie können die Software nur gemäss den Lizenzbedingungen (z. B. End-User Licence Agreement, EULA) gegen Bezahlung von Lizenzgebühren nutzen. So kann die Software beispielsweise nur für eine bestimmte Anzahl Nutzender oder eine bestimmte Anzahl Prozessoren zugelassen sein. footnote:[https://de.wikipedia.org/wiki/Proprietäre_Software[Proprietäre Software -- Wikipedia]] Im Gegenzug für die meist jährlichen Wartungsgebühren verpflichtet sich der Anbieter, Fehler innerhalb einer angemessenen Frist zu beheben und die Software laufend weiterzuentwickeln. + +Lizenz:: +Eine Lizenz ist ein Dokument, das verbindliche Vorgaben für die Nutzung und Verbreitung von Software enthält. Bei Open Source werden in der Regel Lizenzen verwendet, die der OSI entsprechen. footnote:[https://opensource.org/[Open Source Initiative]] + +Community:: +Eine Community im Kontext von Open-Source-Software ist breit definiert. Es kann sich um ein loses Ökosystem oder um eine Struktur mit Governance handeln, welche die Software entwickelt. Das Dokument link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] behandelt dieses Thema. Mitglieder der Community können das Produkt gemeinsam führen, entwickeln, testen, übersetzen, Rückmeldungen geben oder die Software einfach nutzen. + +Rechte Dritter:: +Auch bei Open-Source-Software können Schutzrechte bestehen (Urheberrecht, Markenrecht, Patentrecht) und von Dritten geltend gemacht werden, z. B. bei der Nutzung von Quellcode, der von Dritten erstellt wurde. + +Ausnahmen nach EMBAG:: +Ausnahmen nach Art. 9 Abs. 1 EMBAG sind Rechte Dritter und sicherheitsrelevante Gründe. Beide werden in Kapitel 3 von link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] behandelt. + +Quellcode:: +In der Informatik ist der Quellcode (oder Quelltext) der für Menschen lesbare Text eines Computerprogramms, der in einer Programmiersprache verfasst ist. footnote:[https://de.wikipedia.org/wiki/Quelltext[Quelltext -- Wikipedia]] + +Veröffentlichung:: +Veröffentlichung bezeichnet in erster Linie die Freigabe des Quellcodes unter einer offenen Lizenz nach OSI. Aus praktischen Gründen gehören dazu in der Regel auch die Dokumentation und automatisierte Anweisungen, um die Anwendung aus dem Quellcode zu erstellen. Automatisierte Tests und Testdokumente sind üblicherweise ebenfalls enthalten. Damit sich eine Community entwickeln kann, wird eine Plattform eingesetzt, die dann mehrere Funktionen einer Entwicklungsplattform übernimmt (Build, Test, Support). + +Digitale Souveränität:: +Wir verwenden die Definition aus dem Bericht zur digitalen Souveränität des EDA [St2024]: «Die digitale Souveränität eines Staates oder einer Organisation umfasst zwingend die vollständige Kontrolle über gespeicherte und verarbeitete Daten sowie die selbstständige Entscheidung darüber, wer darauf zugreifen darf. Sie umfasst weiter die Fähigkeit, technologische Komponenten und Systeme eigenständig zu entwickeln, zu verändern, zu kontrollieren und zu ergänzen.» + +Repository:: +Ein Repository ist ein Speicherort, den ein Versionsverwaltungswerkzeug für Dateien und Metadaten zur Codebasis nutzt. Repositories erlauben es mehreren Mitwirkenden, an denselben Dateien zu arbeiten und verschiedene Versionen abzulegen. Die meisten ermöglichen zudem Issue-Tracking, Release-Management, automatisierte Builds und Dokumentation. + +Fork:: +Ein Fork footnote:[https://de.wikipedia.org/wiki/Abspaltung_(Softwareentwicklung)[Abspaltung (Softwareentwicklung) -- Wikipedia]] eines Open-Source-Projekts ist der Vorgang, eine eigenständige Entwicklung des ursprünglichen Projekts aufzubauen. + +Contributor Licence Agreement (CLA):: +Ein Contributor Licence Agreement footnote:[https://en.wikipedia.org/wiki/Contributor_License_Agreement[Contributor License Agreement -- Wikipedia]] ist ein Dokument, das die Bedingungen beschreibt, unter denen geistiges Eigentum zu einem Projekt oder Vorhaben beigetragen werden kann. + +Source Code Management (SCM):: +Source Code Management footnote:[https://de.wikipedia.org/wiki/Versionsverwaltung[Versionsverwaltung -- Wikipedia]], auch Versionsverwaltung genannt, ist ein Werkzeug, das Änderungen und Versionsnummern insbesondere in der Softwareentwicklung wirksam verwaltet. Durchgesetzt hat sich die freie Software Git footnote:[https://de.wikipedia.org/wiki/Git[Git -- Wikipedia]] zur Verwaltung verteilter SCM. + +Open Source Software Development (OSSD):: +Bei der Open-Source-Softwareentwicklung (OSSD) footnote:[https://en.wikipedia.org/wiki/Open-source_software_development[Open-source software development -- Wikipedia]] wird zusätzlich zur Veröffentlichung des Quellcodes der gesamte Entwicklungsprozess öffentlich durchgeführt. Alles von den Anforderungen (Issues) bis zum Quellcode ist transparent. OSSD wird unterstützt durch öffentliche Kommunikationswerkzeuge (Mailinglisten, Foren usw.), ein Versionsverwaltungssystem (Git), Fehler- und Funktionslisten, eine Roadmap und Entwicklerwerkzeuge. + +Software Package Data Exchange (SPDX):: +Software Package Data Exchange (SPDX) footnote:[https://en.wikipedia.org/wiki/Software_Package_Data_Exchange[Software Package Data Exchange -- Wikipedia]] beschreibt ein Standardformat für Software Bill of Materials (SBOM) mit dem Ziel, den korrekten Umgang mit freier Software oder Open-Source-Software zu erleichtern. + +Copyleft-Effekt:: +Steht Software unter einer Lizenz mit Copyleft-Bestimmung, so muss jede Veränderung oder Erweiterung des Quellcodes wieder unter der Lizenz der veränderten Open-Source-Software freigegeben werden (siehe auch link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung]). + +== Potenzial und Herausforderungen + +In der heutigen IT-Welt besteht ein enormes Potenzial für Open-Source-Software. Gleichzeitig bringt der Einsatz von Open-Source-Lösungen auch Herausforderungen mit sich. Diese beiden Seiten werden im folgenden Abschnitt näher erläutert. Die Angaben beruhen unter anderem auf den Ergebnissen der Open Source Studie Schweiz 2018, 2021 und 2024 der Universität Bern, in der die Befragten Auskunft über die erkannten Vor- und Nachteile von Open-Source-Software gaben. + +=== Potenzial von Open-Source-Software + +Die folgenden Punkte beschreiben das Potenzial, das sich bei der Nutzung und Freigabe von Open-Source-Software realisieren lässt. + +{empty}1. Digitale Souveränität:: +Dabei geht es um die Fähigkeit, digitale Dienste zu nutzen und zu kontrollieren. Die digitale Souveränität erstreckt sich über den gesamten Lebenszyklus eines digitalen Systems. Open-Source-Software fördert die digitale Souveränität, da sie Austauschbarkeit, Gestaltungsfreiheit und Einfluss garantiert. footnote:[Wir verwenden die Definition aus _[St2024\]_: «Die digitale Souveränität eines Staates oder einer Organisation umfasst zwingend die vollständige Kontrolle über gespeicherte und verarbeitete Daten sowie die selbstständige Entscheidung darüber, wer darauf zugreifen darf. Sie umfasst weiter die Fähigkeit, technologische Komponenten und Systeme eigenständig zu entwickeln, zu verändern, zu kontrollieren und zu ergänzen.»] + +{empty}2. Keine Lizenzgebühren:: +Für die Nutzung von Open-Source-Software fallen keine Lizenzkosten an. Beim Bezug komplexer Open-Source-Standardsoftwarepakete kann es jedoch sinnvoll sein, kostenpflichtige Support-Subskriptionen zu erwerben. + +{empty}3. Kosteneinsparungen durch Zusammenarbeit mit anderen Nutzenden:: +Da Software unter einer Open-Source-Lizenz uneingeschränkt genutzt und weiterentwickelt werden darf, können Kosten von Weiterentwicklungen geteilt oder bestehende Zusatzentwicklungen anderer Verwaltungseinheiten nach dem Grundsatz «einmal entwickeln – mehrfach nutzen» übernommen werden. Gleichzeitig besteht die Möglichkeit, von den Erfahrungen und Entwicklungen anderer zu profitieren. + +{empty}4. Community-Aufbau und Wissensaustausch:: +Open-Source-Software erleichtert den Aufbau von Communities und den Wissensaustausch, beispielsweise zwischen den verschiedenen föderalen Ebenen der Schweiz. Software kann gemeinsam weiterentwickelt, Fehler können behoben und individuelle Erfahrungen geteilt werden. Der verstärkte Wissensaustausch zwischen verschiedenen Verwaltungseinheiten führt zu einem besseren Verständnis dafür, woran andere arbeiten, sodass Doppelspurigkeiten vermieden werden und sich die besten Lösungen verbreiten können. + +{empty}5. Geringere Herstellerabhängigkeit:: +Vendor-Lock-in (Abhängigkeit von Softwarelieferanten) gilt in der Informatik als sehr hoch. Der Einsatz von Software unter einer Open-Source-Lizenz verringert den Vendor-Lock-in, da Betrieb, Wartung, Support, Weiterentwicklung und weitere Dienstleistungen für Open-Source-Software offen ausgeschrieben werden können. Statt aufgrund eines Vendor-Lock-in ein ganzes System vollständig neu zu beschaffen, können Erweiterungen oder Lebenszyklusleistungen für eine OSS-Lösung auch separat ausgeschrieben werden. Dadurch lassen sich erhebliche Migrationskosten einsparen. + +{empty}6. Offene Standards und Interoperabilität:: +Bei Open-Source-Software ist die Kompatibilität mit anderen Softwarelösungen und IT-Systemen (Interoperabilität) in der Regel höher als bei proprietärer Software. Open-Source-Lösungen verwenden zudem fast ausschliesslich offene Datenformate, weshalb sie sich einfach mit anderen Systemen austauschen lassen. + +{empty}7. Transparenz über den Aufbau der Software:: +Da die Software auch in Form des Quellcodes vorliegt, kann ihre Qualität beispielsweise durch externe Reviews geprüft werden. Zudem lässt sich auf Basis des Quellcodes Dokumentation erstellen (z. B. im Hinblick auf neue Ausschreibungen für Weiterentwicklungsleistungen oder die Ablösung von Open-Source-Software am Ende ihrer Nutzungsdauer). + +{empty}8. Sicherheit und Vertrauen durch Transparenz:: +Aufgrund der Offenheit des Quellcodes kann die Sicherheit von Open-Source-Software höher sein als jene proprietärer Software. Zudem ist es deutlich schwieriger, Hintertüren und andere Lücken in Open-Source-Software einzubauen, was zu mehr Vertrauen in die Software führt. + +{empty}9. Höhere Qualität und Modularität des Codes:: +Die Qualität von Open-Source-Software kann höher sein als jene proprietärer Software, weil die Motivation, guten Code zu schreiben, grösser sein dürfte, wenn Entwicklerinnen und Entwickler wissen, dass ihr Quellcode veröffentlicht wird. Zudem sind Open-Source-Lösungen tendenziell stark modular aufgebaut, sodass sich einzelne Module leicht ersetzen und die übrigen Module weiterverwenden lassen. footnote:[Ein weiterer Sicherheitsaspekt ist, dass sich die verwendeten Bibliotheken (einschliesslich Abhängigkeiten) leichter dokumentieren lassen als bei proprietärer Software. Das wiederum bedeutet, dass Schwachstellen beim Auftreten rasch erkannt und behoben werden können (siehe auch SBOM).] + +{empty}10. Einfache Anpassung:: +Der Zugriff auf den Quellcode erlaubt es den Nutzenden, Weiterentwicklungen selbst oder durch externe Lieferanten vorzunehmen. So kann die Software rasch an die eigenen Bedürfnisse angepasst werden. + +{empty}11. Rasche Innovation und Integration:: +Open-Source-Software wird durch die Community rasch und kontinuierlich weiterentwickelt. So werden neue Technologien und Datenstandards häufig als Open-Source-Programmbibliotheken veröffentlicht. Dies ermöglicht die rasche Umsetzung innovativer Softwarelösungen. + +{empty}12. Arbeitgeberattraktivität:: +Der Einsatz moderner Open-Source-Technologien und die informelle Zusammenarbeit mit internationalen Communities fördern die Motivation der Mitarbeitenden und erhöhen damit die Arbeitgeberattraktivität, was wiederum die Rekrutierung junger, qualifizierter Fachpersonen erleichtert. + +=== Herausforderungen im Umgang mit OSS + +Im Folgenden werden die typischen Herausforderungen beschrieben, die in der Praxis mit Open-Source-Software auftreten, und einige Lösungsansätze skizziert. Auf allgemeine Herausforderungen, die sämtliche Software betreffen, gehen wir an dieser Stelle nicht ein (z. B. die Notwendigkeit der Prüfung auf Cybersicherheit und die Notwendigkeit, für kritische Software angemessenen Support sicherzustellen). + +{empty}1. Hohe Wechselkosten durch bestehende Abhängigkeiten:: +Die Ablösung proprietärer Software durch Open-Source-Lösungen kann sehr kostspielig sein, wenn die Anwendung durch Schnittstellenintegration oder andere Abhängigkeiten eng im bestehenden IT-System eingebettet ist. Diese Wechselkosten führen dazu, dass sich die Einführung von Open-Source-Software oft erst am Ende des Lebenszyklus der proprietären Software lohnt. + +{empty}2. Fehlende Funktionen oder keine passende Open-Source-Lösung:: +Bei der Beschaffung von Standardsoftware kann es vorkommen, dass es zur (bisherigen) proprietären Lösung keine Open-Source-Alternative gibt oder nur eine funktional unzureichende. Als Lösungsansatz besteht die Möglichkeit, die fehlenden Funktionen gemeinsam mit anderen Nutzenden der Open-Source-Software zu entwickeln und dem Open-Source-Projekt hinzuzufügen. footnote:[Für solche neuen Funktionen sind die Projekt- oder Applikationsverantwortlichen zuständig. Wie genau dies geschieht, bestimmt das Projekt. Em002-2 und Em002-4 helfen bei detaillierten Entscheiden. Je nach Umfang der Funktion kann es sinnvoll sein, die Anleitung nicht vollständig zu durchlaufen. Beschaffungsrechtliche Aspekte für Ressourcen sind zu beachten.] + +{empty}3. Höhere Integrationskosten:: +Kurzfristige Kosteneinsparungen durch wegfallende Lizenzen beim Einsatz von Open-Source-Software werden oft durch höhere Integrationskosten aufgewogen. Daher ist es wichtig zu erkennen, dass der professionelle Einsatz von Open-Source-Software nicht «gratis» ist, sondern tatsächlich interne oder externe Kosten verursacht. + +{empty}4. Unklare Verantwortlichkeiten und Support:: +Open-Source-Software wird häufig für den fehlenden Support und die fehlende Wartung durch externe Unternehmen kritisiert. Inzwischen gibt es jedoch eine Vielzahl von Anbietern, die kommerzielle Leistungen (Long-Term-Support, laufende Wartung, Weiterentwicklung, Haftung und Gewährleistung usw.) für Open-Source-Lösungen anbieten. Die verschiedenen Geschäftsmodelle mit Open-Source-Software werden in Anhang D und die verschiedenen Supportmodelle in Kapitel 8 erläutert. Eine aktuelle Übersicht über Open-Source-Dienstleister und ihre Leistungen findet sich im Open Source Directory (https://www.ossdirectory.com) oder in der OSS-Studie 2024 footnote:[https://www.oss-studie.ch/[OSS-Studie]] _[OSS2024]_. + +{empty}5. Kleiner Markt mit wenigen Anbietern:: +Da bestimmte Open-Source-Anwendungen, etwa Desktop-Anwendungen, in der Regel wenig oder keinen Support und keine Wartung benötigen, kann der Markt für Open-Source-Anbieter von Support und Wartung klein sein. In diesem Fall kann eine Ausschreibung für Open-Source-Softwaredienstleistungen dazu beitragen, einen Markt zu schaffen, der den Wettbewerb zwischen den Anbietern erhöht. Das Bestehen einer breiten Entwicklungs-Community für die betreffende Software und die Qualität der Entwicklungsdokumentation sind bei der Ausschreibung solcher Leistungen von praktischer Bedeutung. + +{empty}6. Geringe Sichtbarkeit:: +Communities von Open-Source-Projekten konzentrieren sich vor allem auf die Produktentwicklung und selten auf Marketing. Hersteller proprietärer Software investieren hingegen stark in die Vermarktung und den Verkauf ihrer Produkte. Diese fehlende Werbung für Open-Source-Software erweckt oft den falschen Eindruck, dass es zu proprietären Produkten keine Alternative gebe. Es gibt jedoch Plattformen wie alternativeTo footnote:[https://alternativeto.net/], die einen Überblick über Lösungen für bestimmte Aufgaben bieten (mehr zu OSS-Alternativen im Kapitel «Auffindbarkeit von OSS-Lösungen»). + +{empty}7. Fehlende Akzeptanz bei Endnutzenden:: +Aufgrund unterschiedlicher Benutzeroberflächen, fehlender Funktionen, geringer Benutzerfreundlichkeit und wenig Werbung für Open-Source-Software fehlt bei bestimmten Open-Source-Produkten die Akzeptanz der Endnutzenden. Geeignete Kommunikations-, Dokumentations- und Schulungsangebote können dieser Herausforderung entgegenwirken. Auch der Umstand, dass Open-Source-Software nach den Bedürfnissen der Nutzenden weiterentwickelt werden kann, kann zu höherer Akzeptanz führen. + +{empty}8. Wenig oder kein internes Fachwissen:: +Open-Source-Lösungen entwickeln sich rasch weiter und erfordern gleichzeitig ein vertieftes technisches Verständnis. So kann es vorkommen, dass interne Mitarbeitende wenig oder kein Fachwissen zu bestimmter Open-Source-Software haben. Internes OSS-Know-how lässt sich durch Weiterbildung und Möglichkeiten zum Selbststudium über Online-Quellen sowie durch den Aufbau interner Wikis usw. aufbauen. + +{empty}9. Schwierige Zukunftseinschätzung:: +Für Aussenstehende einer Open-Source-Community ist oft schwer erkennbar, wie sich das Projekt künftig entwickeln wird. Daher ist es wichtig, die künftige Entwicklung einer Open-Source-Lösung realistisch einschätzen zu können. Das Kapitel «Open Hub» stellt hierzu die Plattform Open Hub vor, die eine Einschätzung der Aktivität und Heterogenität der Entwickler-Community erlaubt. Dadurch lässt sich die künftige Entwicklung eines Open-Source-Projekts besser beurteilen. + +{empty}10. Rechtliche Unsicherheiten:: +Die Vielzahl unterschiedlicher Open-Source-Lizenzen und die bislang geringe Zahl von Gerichtsurteilen zu Auslegungsfragen können bei Open-Source-Software mitunter zu rechtlichen Unsicherheiten führen. Dieser Praxisleitfaden soll einen Überblick über die wichtigsten Open-Source-Lizenzen sowie deren Eigenschaften und Kompatibilitäten geben. Quellen für vertiefte Antworten auf rechtliche Fragen finden sich in den Dokumenten link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und link:em002-6.pdf[Em002-6 FAQ zu OSS und Art. 9 EMBAG]. + +{empty}11. Zu umfangreiches Angebot an Open-Source-Software:: +Die Zahl der Open-Source-Softwareprodukte hat in den letzten Jahren stark zugenommen. Potenzielle Nutzende von Open-Source-Software beklagen daher die Vielzahl bestehender Open-Source-Lösungen auf dem Markt. Aus diesem Grund stellt das Kapitel «Auffindbarkeit von …» zwei Plattformen vor, alternativeTo und Open Hub, die einen Vergleich von Open-Source-Lösungen ermöglichen. + +{empty}12. Koordinationsaufwand bei gemeinsamer Entwicklung:: +Wenn sich die Bundesverwaltung an gemeinsamen Projekten beteiligt und dazu beiträgt, entsteht innerhalb dieser Zusammenarbeit ein Koordinationsaufwand, aber auch dann, wenn eine Community ins Boot geholt werden muss. Idealerweise lohnt sich dieser Mehraufwand dennoch dank einer verbesserten Lösung, grösserer Akzeptanz oder verstärkter Beteiligung Dritter. + +== Konstellationen für die Nutzung von und die Arbeit mit OSS + +=== Reifegrade für OSS in der Bundesverwaltung + +Bei der Nutzung und Entwicklung von OSS in der Bundesverwaltung bestehen verschiedene Konstellationen hinsichtlich der Pflichten im Zusammenhang mit Open-Source-Lizenzen: Ein typisches Reifegradmodell footnote:[Reifegradmodell in Anlehnung an https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels] für die Einführung von Open Source in Organisationen kann folgendermassen aussehen: + +. Denial -- keine oder unbewusste Nutzung von Open-Source-Software +. Consumption -- passive Nutzung von Open-Source-Software +. Participation -- Engagement in Open-Source-Communities +. Contribution -- pragmatische Beiträge zu Open-Source-Projekten +. Leadership -- strategisches Engagement mit Open Source zur Steigerung des Geschäftswerts footnote:[Creation wird nicht erwähnt, da Art. 9 EMBAG dies direkt verlangt.] + +[options="header",cols="1,2a"] +|=== +|Konstellation |Auswirkung + +|Die blosse *Nutzung* bestehender Open-Source-Software (ohne Veränderung des Codes). +|Es besteht *keine Pflicht*, den Quellcode zu teilen. + +|Die *vollständige Neuentwicklung* von Software, die unter einer Open-Source-Lizenz veröffentlicht werden soll. +|*In diesem Fall besteht völlige Freiheit bezüglich der Lizenz, unter der die Software veröffentlicht wird.* Für den Bund ist das Dokument link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] heranzuziehen. Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind zu beachten. + +|*Weiterentwicklung* (intern oder extern) mit bestehenden Open-Source-Komponenten (mit oder ohne Copyleft-Effekt footnote:[Erläuterung des Begriffs «Copyleft» in link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung]]), solange die Software *ausschliesslich innerhalb derselben Organisation* genutzt und nicht weiterverbreitet wird. +|Die OSS-Komponenten können beliebig mit Drittkomponenten kombiniert werden. Aus der Lizenz ergibt sich grundsätzlich keine Veröffentlichungspflicht, solange die Software ausschliesslich innerhalb derselben Organisation genutzt und nicht verbreitet wird (Ausnahme: AGPL). Da rechtlich nicht abschliessend geklärt ist, wie weit der Begriff «Verbreitung innerhalb derselben Organisation» reicht, gilt dieses Szenario für OSS-Komponenten mit Copyleft-Effekt nur in Ausnahmefällen. Ziehen Sie in diesen Fällen den Rechtsdienst Ihrer Organisation bei. Siehe link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und link:em002-6.pdf[Em002-6 FAQ zu OSS und Art. 9 EMBAG]. Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind zu beachten. *Da nach Art. 9 EMBAG eine Veröffentlichungspflicht besteht, müssen die Änderungen erneut freigegeben werden. Am einfachsten geschieht dies als Änderungen am bestehenden Open-Source-Projekt.* + +|*Weiterentwicklung* (intern oder extern) *ausschliesslich mit* bestehenden Open-Source-*Komponenten ohne Copyleft-Effekt*, wenn die Software extern verbreitet werden soll (z. B. an Kantone). +|Die OSS-Komponenten können beliebig mit Drittkomponenten kombiniert werden, und aus den Lizenzen ergibt sich keine Veröffentlichungspflicht (siehe auch link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung]). *Im Rahmen von Art. 9 EMBAG ist die Freigabe jedoch obligatorisch. Idealerweise erfolgt die Freigabe über das bestehende Projekt (kein Fork).* Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind zu beachten. + +|*Weiterentwicklung* (intern oder extern) mit bestehenden Open-Source-Komponenten *mit Copyleft-Effekt*, wenn die Software extern verbreitet werden soll (z. B. an Kantone). +|*Aufgrund der Copyleft-Lizenz besteht eine Veröffentlichungspflicht* (siehe auch link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] zum Copyleft-Effekt). Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind zu beachten. + +|*Beitrag* zu einem bestehenden Open-Source-Projekt. +|*Nach EMBAG besteht grundsätzlich eine Veröffentlichungspflicht. Es gelten die Governance und die Lizenz des Projekts.* Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind zu beachten. + +|*Gemeinsame Entwicklung* eines neuen oder bestehenden Projekts mit einer Community und Kostenteilung. +|*Nach EMBAG besteht grundsätzlich eine Veröffentlichungspflicht.* Die Dokumente link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS], link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] dienen *dem Aufbau des Projekts und seiner Governance.* + +|*Sämtliche Varianten der Entwicklung oder Weiterentwicklung* erfolgen *über einen Lieferanten oder beauftragte Dritte.* +|*Nach EMBAG besteht grundsätzlich eine Veröffentlichungspflicht.* Grundlage bilden link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS], link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]. Wenn möglich sollten die Voraussetzungen für die Veröffentlichung bereits im Beschaffungsprozess geschaffen und nötigenfalls die Anforderungen an die Softwarefreigabe dem Lieferanten bzw. den Dritten mitgeteilt werden. +|=== + +=== Nutzung unveränderter Open-Source-Software + +Bei der Nutzung von Open-Source-Software ist grundsätzlich nicht relevant, unter welcher Open-Source-Lizenz sie veröffentlicht wird, da alle Open-Source-Lizenzen (siehe Kapitel 2 «Begriffe») die uneingeschränkte Nutzung von Open-Source-Software erlauben, unabhängig davon, auf wie vielen Arbeitsplätzen, mit wie vielen gleichzeitig angemeldeten Nutzenden, auf wie vielen Servern und Prozessoren usw. die Software eingesetzt wird. + +Bei der Nutzung unveränderter Open-Source-Software entstehen *keine Veröffentlichungspflichten*, auch nicht bei Programmen, die unter einer Lizenz mit striktem Copyleft-Effekt stehen (Ausnahme: AGPL-Lizenz, Affero General Public Licence). + +Solange Open-Source-Software durch interne Leistungserbringer des Bundes eingeführt und betrieben wird, kann dies *ohne öffentliches Beschaffungsverfahren* erfolgen, denn «die OSS-Lizenz allein kostet die Beschaffungsstelle in der Regel nichts und ist daher für sich genommen nicht beschaffungsrelevant». + +Wird ein externer Leistungserbringer für Wartung, Support und weitere Dienstleistungen für die Open-Source-Software beauftragt, so sind die Vorgaben des öffentlichen Beschaffungsrechts zu beachten. Verschiedene Supportvarianten werden in Kapitel 9 beschrieben. Wichtig ist zudem, bei der Beschaffung von Open-Source-Software geeignete Eignungs- und Zuschlagskriterien zu verwenden. Die Grundlagen dazu werden in Kapitel 8 erläutert. + +=== Entwicklung mit Open-Source-Komponenten und Freigabe des Quellcodes + +Mit der Veröffentlichungspflicht nach Art. 9 EMBAG ist hier das in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] beschriebene Vorgehen zu befolgen. +Die Dokumente link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] sind nötigenfalls ebenfalls beizuziehen. Ziel ist es, das Projekt anhand der drei Checklisten _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]_ kontrolliert freizugeben. + +=== Mitarbeit in offenen Projekten (Contribution) + +Mögliche Überlegungen zum Beitrag der Bundesverwaltung an offene, bereits bestehende Projekte sind im BITKOM-Leitfaden _[BITKOM2024]_ Kapitel 4.2 aufgeführt. footnote:[Siehe https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html, Kapitel 4.2.] Je nach Bedeutung des Projekts für die Bundesverwaltung ist zu prüfen, wie viel Verantwortung das jeweilige Amt übernehmen will und kann. + +Die Mitarbeit in offenen Projekten und die direkte Entwicklung in offenen Projekten können ebenfalls anhand der Dokumente für die Freigabe erfolgen. Im Mittelpunkt stehen link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] und die zugehörige Checkliste _link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]_. + +== Eigenschaften und Auswahl von Open-Source-Lizenzen + +Die Eigenschaften und die Auswahl von Open-Source-Lizenzen werden im Dokument link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] beschrieben. + +== OSS-Beschaffung + +Strategische Fragen zu Beschaffung und OSS werden in link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software] behandelt. + +Das Kompetenzzentrum Beschaffungswesen Bund (KBB) hat ein neues Merkblatt _Softwarebeschaffung und Art. 9 EMBAG https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ sowie zwei Dokumente «Musterkriterien – Beschaffung EMBAG und Open Source» und «Mustervertragstexte – Softwareentwicklung» veröffentlicht. + +Weitere Unterstützung steht im https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[BBL-Intranet] (nur im Bundesnetz zugänglich) mit der 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[_Wegleitung Open Source in der Beschaffung_] _[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]]_ und der 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[_Checkliste Integral-Ausnahme Art. 9 EMBAG_] _[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]]_ zur Verfügung. + +Die Enterprise-Tauglichkeit von Open Source findet sich im Dokument _Selection Criteria for Enterprise-Ready Open Source Software [Gu2024]_ footnote:[Siehe _[Gu2024\]_] oder im Bitkom-Leitfaden. footnote:[Siehe https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software[Praxisempfehlungen für Open-Source-Software | Leitfaden 2025 | Bitkom e. V.], Kapitel 3.3] + +== Auffindbarkeit von OSS-Lösungen + +Verschiedene Plattformen erlauben es interessierten Organisationen, Open-Source-Software vor der Nutzung oder Beschaffung zu finden und zu analysieren. Die daraus gewonnenen Daten bilden eine Grundlage für den Entscheid über den Einsatz oder die Beschaffung von Open-Source-Software. + +Eine Zusammenstellung von Mindestanforderungen und gegebenenfalls eine Marktanalyse sollten in jedem Fall dienen. + +=== OSS-Katalog + +Die Bundesbehörden sind verpflichtet, den Quellcode von Software offenzulegen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen. Der OSS-Katalog footnote:[https://www.opensource.admin.ch/] listet sämtliche Software auf, die seit dem 1. Januar 2024 von Bundesbehörden entwickelt und als Open Source freigegeben wurde. Er bietet einen Überblick über verfügbare Software und erleichtert das Auffinden und die Wiederverwendung von Open-Source-Lösungen. + +Wird ein neues Repository oder eine neue Organisation erstellt, so ist dies für die Aufnahme in den OSS-Katalog per E-Mail an opensource@bk.admin.ch zu melden. + +OSS-Katalog: https://www.opensource.admin.ch + +=== OSS Directory + +Das von CH Open betriebene OSS Directory footnote:[https://www.ossdirectory.com/de/home] erleichtert das Auffinden qualifizierter Anbieter, die professionellen Support für Open-Source-Software anbieten. + +Open-Source-Anbieter zeigen anhand von Erfolgsgeschichten, welchen Nutzenden (Kunden) sie bei der Einführung bestimmter Open-Source-Produkte geholfen haben. +Das Directory bietet zudem aktuelle Open-Source-News aus bestehenden Plattformen, kuratierte Top-News, Veranstaltungen, Communities, Stellenangebote und Artikel zum Wissensaustausch. Das OSS Directory ist auf Deutsch, Englisch, Französisch und Italienisch verfügbar. Sämtliche Einträge können von registrierten Nutzenden direkt hinzugefügt und aktualisiert werden. + +OSS Directory: https://www.ossdirectory.com + +=== alternativeTo + +Ein praktisches Werkzeug zum Auffinden von Alternativen zu Software ist «alternativeTo – Crowdsourced software recommendations». footnote:[https://alternativeto.net/] Wie der Name andeutet, sind die Alternativen und ihre Bewertungen durch Crowdsourcing entstanden, also durch die Eingaben vieler einzelner Nutzender. alternativeTo unterscheidet vier Arten von Softwarelösungen, von denen nur die erste als Open-Source-Software im Sinne von Art. 9 EMBAG gilt: + +Free open source:: +Software, die unter einer Open-Source-Lizenz veröffentlicht wird. + +Free:: +Kostenlose Software (Freeware), deren Quellcode jedoch nicht frei verfügbar ist und nicht verändert werden darf. + +Freemium:: +Solche Software bietet eine kostenlose und eine Premium-Version, wobei alle wichtigen Funktionen bereits in der kostenlosen Version verfügbar sind. Nicht zu dieser Kategorie gehört Software, die während einer bestimmten Zeit kostenlos getestet werden kann (z. B. eine 30-Tage-Testversion); diese fällt in die Kategorie «Commercial». + +Commercial:: +Dabei handelt es sich um proprietäre Software, für deren Nutzung Lizenzgebühren erhoben werden. + +=== Open-Source-Repositories + +Die derzeit weltweit beliebteste Open-Source-Entwicklungsplattform mit über 30 Millionen Nutzenden und über 100 Millionen Quellcode-Repositories ist GitHub. footnote:[https://octoverse.github.com] Heute haben praktisch alle IT-Unternehmen, insbesondere Hersteller proprietärer Software, sowie viele andere Arten von Unternehmen und Organisationen eine GitHub-Präsenz. Immer mehr Behörden – rund ein Dutzend aus der Schweiz footnote:[https://government.github.com/community/#switzerland] – veröffentlichen ihre eigene Open-Source-Software zudem auf «GitHub and Government» unter https://government.github.com. Dieser Vorgang lässt sich auch mit anderen Repositories durchführen. + +Beispiele für andere Repositories sind: + +* GitLab +* Bitbucket +* SourceForge +* LaunchPad + +Auf GitHub Insights lassen sich zahlreiche relevante Statistiken eines Open-Source-Projekts auf GitHub ablesen: + +Pulse:: +Überblick über die jüngsten Aktivitäten eines Open-Source-Projekts auf GitHub: Zusammenfassung der wichtigsten Informationen zu Entwicklungsintensität, Heterogenität der Community, offenen Meldungen, Verbesserungen (Pull Requests) usw. + +Contributors:: +Darstellung, welche Entwicklerinnen und Entwickler wann aktiv waren. Dies ist ein wichtiger Hinweis darauf, ob alles von einer Person abhängt oder ob eine grössere Community dahintersteht. + +Commits:: +Darstellung, welche Beiträge in welchem Zeitraum zu diesem Open-Source-Projekt geleistet wurden. + +Code frequency:: +Visualisierung, wie viel Quellcode wann hinzugefügt oder entfernt wurde. + +Dependency graph:: +Abhängigkeiten des Open-Source-Projekts von anderer Open-Source-Software (z. B. relevant für das Erkennen von Sicherheitslücken und Updates). + +Network:: +Darstellung, wann welche Entwicklerin bzw. welcher Entwickler zu welchem Entwicklungszweig beigetragen hat. + +Forks:: +Liste aller Kopien des Open-Source-Projekts auf GitHub. Indikator für die Beliebtheit und Verbreitung der Open-Source-Software. + +=== Open Hub + +Sollen Informationen zu einer Open-Source-Lösung gesammelt werden, die nicht zwingend auf GitHub entwickelt wird, bietet sich Open Hub von Black Duck an. footnote:[https://www.openhub.net/] Für rund eine halbe Million Open-Source-Projekte werden zahlreiche wichtige Informationen übersichtlich zusammengefasst: + +Project Summary:: +Eine kurze Beschreibung des Open-Source-Projekts. + +In a Nutshell:: +Die wichtigsten Fakten zu einem Open-Source-Projekt, etwa die Zahl der Commits, der Mitwirkenden und der Codezeilen sowie die meistverwendete Programmiersprache, der Zeitpunkt des ersten Commits und der letzten Änderung. Zudem wird eine Einschätzung der Codebasis und der Grösse des Entwicklungsteams aufgeführt (z. B. «Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits»). + +Quick Reference:: +Enthält Informationen zur Organisation, Links zum Projekt und zum Code sowie Hinweise auf ähnliche Projekte. + +Licences:: +Gibt an, unter welcher Lizenz bzw. welchen Lizenzen das Open-Source-Projekt lizenziert ist und welche Folgen damit verbunden sind. + +Project Security:: +Liefert Angaben zur Sicherheit und zu Schwachstellen des Open-Source-Projekts. + +Code:: +Eine Grafik, welche die Zahl der Codezeilen im Zeitverlauf zeigt, aufgeschlüsselt nach Programmiersprache. + +Activity:: +Eine Grafik, welche die Zahl der Commits pro Monat zeigt. Zusätzlich wird eine Zusammenfassung der letzten 30 Tage und 12 Monate bereitgestellt. + +Community:: +Eine Grafik, welche die Zahl der aktiven Mitwirkenden pro Monat zeigt. Zudem wird eine Bewertung des Projekts auf einer Fünf-Sterne-Skala angezeigt. + +Open Hub erlaubt es auch, verschiedene Open-Source-Projekte zu vergleichen. footnote:[https://www.openhub.net/p/_compare] Dies verschafft rasch einen Überblick darüber, welches Projekt die aktivste Community, die längste Entwicklungszeit oder die am besten geeignete Lizenz hat. + +=== Besondere Code-Repositories + +Grössere Organisationen verfügen über eigene Code-Repositories. Besonders zu erwähnen ist beispielsweise das deutsche Repository für Behörden opencode.de. footnote:[https://opencode.de/de/home] Von besonderem Interesse sind hier Repositories anderer öffentlicher Verwaltungen. + +== Supportmodelle für die OSS-Nutzung + +Bereits auf dem Markt verfügbare Open-Source-Software kann grundsätzlich auf drei Arten genutzt werden: + +. Nutzung ohne professionellen Support +. Nutzung mit internem Support +. Nutzung mit Support durch einen externen Lieferanten. + +Diese drei Nutzungsarten und ihre Vor- und Nachteile werden nachfolgend kurz erläutert. Welches dieser Szenarien im Einzelfall am sinnvollsten ist, muss fallweise entschieden werden. Welches Supportmodell geeignet ist, hängt von der strategischen Relevanz der Open-Source-Software, der technischen Integration und den verfügbaren Personalressourcen ab. + +Bei kritischer Software muss der Support in jedem Fall professionell erbracht werden, sei es intern oder extern. Auch der geplante Lebenszyklus sollte bei der Supportplanung eine Rolle spielen. Es kann auch sein, dass Support von mehreren Anbietern bezogen wird. + +=== Nutzung ohne professionellen Support + +Open-Source-Software steht im Internet zum kostenlosen Herunterladen, Installieren und Nutzen zur Verfügung. + +Vorteile:: +* Geringe Kosten +* Rasche Umsetzung + +Nachteile:: +* Kein garantierter Support +* Keine Haftungsansprüche + +Risiko und Absicherung:: +Hohes Risiko: Es bestehen keine Supportverträge oder Garantien und in der Organisation ist wenig oder kein Entwicklerwissen vorhanden. + +Typischer Anwendungsbereich:: +Open-Source-Standardsoftware, die unabhängig von anderen Systemen aktualisiert werden kann. + +=== Nutzung mit internem Support + +Ein Unternehmen oder eine Organisation der öffentlichen Hand baut für die langfristige Nutzung Fachwissen und Ressourcen zu bestimmten Open-Source-Lösungen auf. Dieser Ansatz ist besonders in geschäftskritischen Bereichen verbreitet. + +Vorteile:: +* Hohe Flexibilität dank internem Know-how +* Kein Lieferanten-Lock-in + +Nachteile:: +* Hoher Investitions- und Zeitaufwand für den Aufbau von Fachwissen +* Höhere interne Fixkosten für Personal + +Risiko und Absicherung:: +Mittleres Risiko: Der Support hängt vom Know-how und der Verfügbarkeit der internen IT ab. + +Typischer Anwendungsbereich:: +Eigenentwicklungen, strategisch eingesetzte Open-Source-Software, für die vertieftes Know-how vorhanden ist. + +=== Nutzung mit Support durch einen externen Lieferanten + +Ein externer Open-Source-Anbieter wird beigezogen, um die Einführung und Wartung der Open-Source-Software professionell zu begleiten. Dieser Ansatz wird vor allem in geschäftskritischen Bereichen eingesetzt, in denen vertieftes Know-how der Software sofort verfügbar sein muss. Dies kann auch Teile der Freigabe oder die gesamte Freigabe umfassen. + +Vorteile:: +* Direkter Zugang zum Know-how der Open-Source-Entwicklerinnen und -Entwickler +* Fehlerbehebungen und Erweiterungen auf Vertragsbasis +* Auswahl unter verschiedenen Open-Source-Lieferanten +* Verbindlichkeit, Absicherung gegen Compliance-Risiken + +Nachteile:: +* Externe Kosten durch Open-Source-Lieferanten +* Know-how-Abhängigkeit vom Open-Source-Lieferanten + +Risiko und Absicherung:: +Geringes Risiko: Die Gewährleistung erfolgt gemäss Pflichtenheft oder Service Level Agreement + +Typischer Anwendungsbereich:: +Geschäftskritische Open-Source-Software, für die wenig oder kein internes Entwicklungs-Know-how vorhanden ist + +== Anlaufstelle + +In der Bundesverwaltung gibt es keine zentrale Anlaufstelle, die als Open Source Programme Office tätig wäre. Grundsätzlich sind die Bundesämter für die Umsetzung selbst verantwortlich. + +Allgemeine Anfragen zu den OSS-Hilfsmitteln des Dokumentensatzes Em002 können an den Sektor DTI der Bundeskanzlei gerichtet werden: opensource@bk.admin.ch. + +== Anhänge + +=== Änderungen gegenüber der Vorversion + +* Kapitel 4.1: Reifegrade ergänzt +* Kapitel 6: Beschaffung von OSS ergänzt und mit den neuen BBL-Dokumenten angepasst +* Kapitel 7.1: Neuer OSS-Katalog des Bundes (opensource.admin.ch) +* Weitere kleinere redaktionelle Änderungen und Verbesserungen + +=== Referenzen + +Die Referenzen zum Dokumentensatz Em002 finden sich in den link:em002.pdf[Em002 Strategischen Leitlinien]. + +=== Abkürzungen + +Ein Abkürzungsverzeichnis findet sich im Hauptdokument Em002. +Ein Glossar findet sich im Dokument «link:em002-6.pdf[Em002-6 Häufig gestellte Fragen zur Veröffentlichung von OSS (FAQ-OSS)]». + +=== Geschäftsmodelle mit OSS + +Open-Source-Software ist an sich kein Geschäftsmodell, weil es – anders als bei proprietärer Software – nicht möglich ist, Software unter einer Open-Source-Lizenz zu verkaufen. Dennoch bestehen für Unternehmen verschiedene Möglichkeiten, Geschäftsmodelle auf Basis von Open-Source-Software zu betreiben. Soll etwa professioneller externer Support für eine Open-Source-Lösung bezogen werden, so ist die Beschaffung entsprechender kommerzieller Leistungen erforderlich. Die vier häufigsten Geschäftsmodelle für Open-Source-Software werden nachfolgend erläutert. Weitere Aspekte dieser und anderer Geschäftsmodelle werden im BITKOM-Leitfaden _[BITKOM2023]_ erläutert. + +==== Dienstleistungen und Produkte auf Basis von OSS + +Unternehmen können kommerzielle Dienstleistungen wie Webhosting oder Cloud Computing auf Basis von Open-Source-Software anbieten, die mit proprietärer Software wesentlich teurer wären. Deshalb bauen die meisten Start-ups, Onlineportale und E-Commerce-Anbieter ihre Plattformen heute auf Open-Source-Software auf. Andere Technologieunternehmen wie Telekommunikationsunternehmen, Streaminganbieter oder gar Hersteller proprietärer Software integrieren Open-Source-Software in ihre Software- und Hardwareprodukte sowie in Onlinedienste. Dies erlaubt es Unternehmen, weiterhin innovative Lösungen anzubieten, die mit proprietärer Software nur schwer zu erreichen wären. + +==== Dienstleistungen für OSS + +Open-Source-Anbieter erbringen Dienstleistungen für ausgewählte Open-Source-Software. Sie verfügen über erfahrene Open-Source-Entwicklerinnen und -Entwickler und können daher Support, Wartung, Betrieb, Entwicklung, Beratung, Schulung und weitere Leistungen für Open-Source-Software anbieten. Diese können beim Open-Source-Lieferanten im Auftrag oder im Rahmen eines Werkvertrags bezogen werden. Solche Dienstleistungen für Open-Source-Software können öffentlich ausgeschrieben werden, da kein Vendor-Lock-in besteht. Wichtig bei solchen Ausschreibungen ist die Berücksichtigung geeigneter Kriterien, damit tatsächlich kompetente Leistungserbringer ausgewählt werden (siehe Kapitel 0 und 8, _[BITKOM2023]_ Kapitel 3.3 und _[Gu2024]_). + +==== Subskriptionen + +Werden Dienstleistungen für Open-Source-Software in standardisierter, wiederkehrender Form als eine Art Service Level Agreement (SLA) erbracht, so spricht man von Subskriptionen. Im Rahmen solcher Subskriptionen garantieren Unternehmen beispielsweise laufende Sicherheitsupdates, Support per E-Mail oder Telefon, Kompatibilität mit anderen Software- und Hardwareprodukten durch Zertifizierungen, langfristige Wartungsleistungen und Absicherungen gegen rechtliche Ansprüche (Urheberrecht, Patente). Im Gegenzug bezahlen Kundinnen und Kunden Subskriptionen pro Arbeitsplatz oder CPU, ähnlich wie Lizenz- oder Nutzungsgebühren für proprietäre Software. Anders als bei proprietärer Software sind Subskriptionen für Open-Source-Software jedoch keine Voraussetzung für die Nutzung der Software, sondern lediglich eine Möglichkeit, den Mehrwert der vom Open-Source-Lieferanten erbrachten Leistungen abzugelten. + +==== Duale Lizenzierung + +Besitzt ein Unternehmen das geistige Eigentum an einer Softwarelösung und stehen alle integrierten Open-Source-Komponenten unter einer permissiven Lizenz, so kann eine duale oder mehrfache Lizenzierung angewendet werden. Dies erlaubt es dem entwickelnden Unternehmen, die Software unter einer Copyleft-Open-Source-Lizenz zu veröffentlichen und sie zugleich unter einer proprietären Lizenz zu verkaufen. Diese kommerzielle Version wird oft Enterprise-Version genannt und enthält typischerweise bestimmte Zusatzfunktionen, etwa exklusive Schnittstellenintegrationen oder die Erlaubnis für Käuferinnen und Käufer, die Software in eigene proprietäre Produkte zu integrieren. Je nach Ausmass der Einschränkungen der Open-Source-Version ist beim Einsatz dual lizenzierter Software Vorsicht geboten, da der Bezug der Enterprise-Version unumgänglich sein kann, womit der Vendor-Lock-in gleich hoch ist wie bei typischer proprietärer Software. +endif::[] + +ifeval::["{lang}" == "fr"] +NOTE: 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 {url-repo}/tree/main[README] principal. + +== 1. Utilisation du présent guide + +Conformément à l'article 9 de la loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA), la Confédération est tenue de publier le code source des logiciels qu'elle développe ou fait développer pour accomplir ses tâches. footnote:[RS 172.019 : https://www.fedlex.admin.ch/eli/cc/2023/682/fr] Le secteur TNI de la Chancellerie fédérale a déduit de ce mandat légal des objectifs généraux, exposés dans les Lignes directrices stratégiques pour les logiciels open source. + +Le présent document constitue un guide pratique relatif aux exigences juridiques et stratégiques. Il vise à soutenir les unités administratives fédérales dans l'utilisation, l'acquisition et la publication de logiciels open source. Il offre à toutes les personnes intéressées une vue d'ensemble complète du sujet et renvoie à des informations complémentaires figurant dans les autres outils. + +Selon vos connaissances préalables et vos besoins, vous pouvez toutefois lire les guides de manière sélective avant de passer aux autres outils. L'aperçu suivant vous aidera à trouver le point de départ approprié. En cas de doute, il est recommandé de lire d'abord le guide. + +=== Intention / parties prenantes + +Introduction générale aux logiciels open source + +* Chapitre Définitions +* Chapitre Potentiel et défis +* Chapitre Repérabilité des solutions OSS +* link:em002-5.pdf[Em002-5 Aide-mémoire Outils OSS] +* link:em002-3.pdf[Em002-3 Guide de licences OSS] +* link:em002-6.pdf[Em002-6 FAQ sur l'OSS] + +Introduction générale à la LMETA pour les décideurs + +* link:em002-5.pdf[Em002-5 Aide-mémoire Outils OSS] +* link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] + +Acquisition uniquement de logiciels destinés à être utilisés + +* Chapitre Degrés de maturité pour l'OSS dans l'administration fédérale +* Chapitre Utilisation de logiciels open source non modifiés +* link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et OSS] +* Aide-mémoire Acquisition de logiciels et art. 9 LMETA [KBB-MB] +* Directives OSS dans les acquisitions [BBL-WL] + +Nouveau développement informatique et publication + +* Chapitre Développement avec des composants open source et publication du code source +* Chapitre Participation à des projets ouverts (contribution) +* link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Liste de contrôle Évaluation préalable OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle Analyse et préparation OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Liste de contrôle Validation et publication OSS] +* link:em002-4.pdf[Em002-4 Guide des communautés OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle Communauté OSS] + +Acquisition de logiciels à créer (prestation de services ou ouvrage) + +* Chapitre Degrés de maturité pour l'OSS dans l'administration fédérale +* Chapitre Développement avec des composants open source et publication du code source +* Chapitre Participation à des projets ouverts (contribution) +* link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et OSS] +* Boîte à outils de l'OFCL, y compris les directives Open Source dans les acquisitions +* Plateforme d'apprentissage et de modèles de l'administration publique du CCMP (www.perimap.admin.ch), y compris Acquisition de logiciels et art. 9 LMETA [KBB-MB] +* Directives OSS dans les acquisitions [BBL-WL] +* link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Liste de contrôle Évaluation préalable OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle Analyse et préparation OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Liste de contrôle Validation et publication OSS] +* link:em002-4.pdf[Em002-4 Guide des communautés OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle Communauté OSS] + +Clarifications juridiques en vue de la publication + +* link:em002-6.pdf[Em002-6 Foire aux questions sur la publication d'OSS (FAQ-OSS)] +* link:em002-3.pdf[Em002-3 Guide de licences OSS] + +Principes de travail pour les cheffes et chefs de projet + +* https://www.hermes.admin.ch/[Documents HERMES] +* link:em002-5.pdf[Em002-5 Aide-mémoire Outils OSS] + +Contributions logicielles à des tiers et collaborations + +* link:em002-4.pdf[Em002-4 Guide des communautés OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle Communauté OSS] +* link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et OSS] +* link:em002-3.pdf[Em002-3 Guide de licences OSS] + +Le schéma suivant donne une vue d'ensemble des documents pertinents pour l'OSS au sein de l'administration fédérale. + +include::partials/document-map.fr.adoc[] + +Figure 1 : Vue d'ensemble des outils OSS en lien avec l'art. 9 LMETA + +== Définitions + +Logiciel open source:: +Un logiciel est considéré comme un logiciel open source (OSS) lorsqu'il est publié sous l'une des quelque 80 licences reconnues par l'Open Source Initiative OSI _[OSI2024]_. Concrètement, la définition de l'open source énonce dix critères que toutes les licences open source doivent remplir _[Pe1999]_. Ceux-ci peuvent pour l'essentiel se résumer en quatre points : ++ +. Le logiciel peut être utilisé à toutes fins. +. Le code source du logiciel est librement accessible. +. Le logiciel peut être copié et diffusé sans restriction. +. Le logiciel peut être modifié et diffusé sous forme modifiée à certaines conditions. + +Logiciel libre:: +Avant le terme « open source », la Free Software Foundation (FSF) a introduit dans les années 1980 la notion de « logiciel libre ». Sur le fond, le logiciel libre remplit les conditions du logiciel open source, mais vise à garantir que le logiciel reste toujours librement accessible et, dans la mesure du possible, ne soit pas intégré à des logiciels propriétaires. footnote:[https://fr.wikipedia.org/wiki/Logiciel_libre[Logiciel libre -- Wikipédia]] + +Logiciel propriétaire:: +Dans le cas d'un logiciel propriétaire, un fournisseur développe le logiciel et vend à l'utilisateur une licence d'utilisation. En règle générale, l'utilisateur ne connaît pas le code du logiciel et ne peut ni le rediffuser ni le modifier. Il peut uniquement utiliser le logiciel selon les conditions de licence (p. ex. End-User Licence Agreement, EULA) moyennant le paiement de redevances de licence. Le logiciel peut par exemple n'être autorisé que pour un certain nombre d'utilisateurs ou un certain nombre de processeurs. footnote:[https://fr.wikipedia.org/wiki/Logiciel_propriétaire[Logiciel propriétaire -- Wikipédia]] En contrepartie des frais de maintenance généralement annuels, le fournisseur s'engage à corriger les erreurs dans un délai raisonnable et à développer le logiciel en continu. + +Licence:: +Une licence est un document qui contient des prescriptions contraignantes relatives à l'utilisation et à la diffusion d'un logiciel. Dans le domaine de l'open source, on utilise généralement des licences conformes à l'OSI. footnote:[https://opensource.org/[Open Source Initiative]] + +Communauté:: +La notion de communauté dans le contexte des logiciels open source est définie largement. Il peut s'agir d'un écosystème informel ou d'une structure dotée d'une gouvernance qui développe le logiciel. Le document link:em002-4.pdf[Em002-4 Guide des communautés OSS] traite de ce sujet. Les membres de la communauté peuvent gérer le produit en commun, le développer, le tester, le traduire, donner leur avis ou simplement utiliser le logiciel. + +Droits de tiers:: +Même pour les logiciels open source, des droits de protection peuvent exister (droit d'auteur, droit des marques, droit des brevets) et être invoqués par des tiers, p. ex. lors de l'utilisation de code source créé par des tiers. + +Exceptions selon la LMETA:: +Les exceptions prévues à l'art. 9, al. 1, LMETA sont les droits de tiers et les motifs relevant de la sécurité. Les deux sont traités au chapitre 3 de link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +Code source:: +En informatique, le code source (ou texte source) est le texte lisible par l'être humain d'un programme informatique, rédigé dans un langage de programmation. footnote:[https://fr.wikipedia.org/wiki/Code_source[Code source -- Wikipédia]] + +Publication:: +La publication désigne en premier lieu la mise à disposition du code source sous une licence ouverte conforme à l'OSI. Pour des raisons pratiques, elle comprend généralement aussi la documentation et les instructions automatisées permettant de construire l'application à partir du code source. Les tests automatisés et les documents de test en font aussi habituellement partie. Pour qu'une communauté puisse se développer, une plateforme est utilisée, laquelle assume alors plusieurs fonctions d'une plateforme de développement (build, test, support). + +Souveraineté numérique:: +Nous utilisons la définition du rapport du DFAE sur la souveraineté numérique [St2024] : « La souveraineté numérique d'un État ou d'une organisation comprend nécessairement le contrôle complet des données stockées et traitées ainsi que la décision autonome de savoir qui peut y accéder. Elle comprend en outre la capacité de développer, de modifier, de contrôler et de compléter de manière autonome des composants et des systèmes technologiques. » + +Dépôt (repository):: +Un dépôt est un emplacement de stockage utilisé par un outil de gestion de versions pour les fichiers et les métadonnées relatives à la base de code. Les dépôts permettent à plusieurs contributeurs de travailler sur les mêmes fichiers et d'enregistrer différentes versions. La plupart permettent en outre le suivi des problèmes, la gestion des versions, les compilations automatisées et la documentation. + +Fork:: +Un fork footnote:[https://fr.wikipedia.org/wiki/Fork_(développement_logiciel)[Fork (développement logiciel) -- Wikipédia]] d'un projet open source est le fait de mettre en place un développement indépendant du projet initial. + +Contributor Licence Agreement (CLA):: +Un Contributor Licence Agreement footnote:[https://en.wikipedia.org/wiki/Contributor_License_Agreement[Contributor License Agreement -- Wikipédia]] est un document qui décrit les conditions auxquelles de la propriété intellectuelle peut être apportée à un projet ou à une entreprise. + +Source code management (SCM):: +La gestion du code source footnote:[https://fr.wikipedia.org/wiki/Gestion_de_versions[Gestion de versions -- Wikipédia]], également appelée gestion de versions, est un outil qui gère efficacement les modifications et les numéros de version, en particulier dans le développement logiciel. Le logiciel libre Git footnote:[https://fr.wikipedia.org/wiki/Git[Git -- Wikipédia]] s'est imposé pour la gestion des SCM distribués. + +Open source software development (OSSD):: +Dans le développement de logiciels open source (OSSD) footnote:[https://en.wikipedia.org/wiki/Open-source_software_development[Open-source software development -- Wikipédia]], outre la publication du code source, l'ensemble du processus de développement se déroule publiquement. Tout, des exigences (issues) au code source, est transparent. L'OSSD s'appuie sur des outils de communication publics (listes de diffusion, forums, etc.), un système de gestion de versions (Git), des listes d'erreurs et de fonctionnalités, une feuille de route et des outils de développement. + +Software Package Data Exchange (SPDX):: +Software Package Data Exchange (SPDX) footnote:[https://en.wikipedia.org/wiki/Software_Package_Data_Exchange[Software Package Data Exchange -- Wikipédia]] décrit un format standard pour les Software Bill of Materials (SBOM), dans le but de faciliter le traitement correct des logiciels libres ou open source. + +Effet copyleft:: +Si un logiciel est placé sous une licence comportant une clause de copyleft, toute modification ou extension du code source doit être publiée à nouveau sous la licence du logiciel open source modifié (voir aussi link:em002-3.pdf[Em002-3 Guide de licences OSS]). + +== Potentiel et défis + +Les logiciels open source recèlent un potentiel énorme dans le monde informatique actuel. Parallèlement, l'utilisation de solutions open source comporte aussi des défis. Ces deux aspects sont expliqués plus en détail dans la section suivante. Les indications se fondent notamment sur les résultats de l'Étude Open Source Suisse 2018, 2021 et 2024 de l'Université de Berne, dans laquelle les personnes interrogées ont donné des informations sur les avantages et les inconvénients reconnus des logiciels open source. + +=== Potentiel des logiciels open source + +Les points suivants décrivent le potentiel qui peut être réalisé lors de l'utilisation et de la publication de logiciels open source. + +{empty}1. Souveraineté numérique:: +Il s'agit ici de la capacité d'utiliser et de contrôler des services numériques. La souveraineté numérique s'étend sur l'ensemble du cycle de vie d'un système numérique. Les logiciels open source favorisent la souveraineté numérique, car ils garantissent l'interchangeabilité, la liberté de conception et l'influence. footnote:[Nous utilisons la définition de _[St2024\]_ : « La souveraineté numérique d'un État ou d'une organisation comprend nécessairement le contrôle complet des données stockées et traitées ainsi que la décision autonome de savoir qui peut y accéder. Elle comprend en outre la capacité de développer, de modifier, de contrôler et de compléter de manière autonome des composants et des systèmes technologiques. »] + +{empty}2. Pas de redevances de licence:: +L'utilisation de logiciels open source n'entraîne aucun coût de licence. Lors de l'acquisition de progiciels open source standard complexes, il peut toutefois être judicieux d'acheter des abonnements de support, qui sont payants. + +{empty}3. Économies grâce à la coopération avec d'autres utilisateurs:: +Comme un logiciel placé sous licence open source peut être utilisé et développé sans restriction, les coûts des développements ultérieurs peuvent être partagés ou des développements complémentaires existants d'autres unités administratives peuvent être repris selon le principe « développer une fois — utiliser plusieurs fois ». Il est en même temps possible de profiter de l'expérience et des développements des autres. + +{empty}4. Constitution de communautés et partage des connaissances:: +Les logiciels open source facilitent la constitution de communautés et le partage des connaissances, par exemple entre les différents niveaux fédéraux en Suisse. Les logiciels peuvent être développés en commun, les erreurs corrigées et les expériences individuelles partagées. L'échange accru de connaissances entre différentes unités administratives conduit à une meilleure compréhension de ce sur quoi travaillent les autres, de sorte que les doublons sont évités et que les meilleures solutions peuvent se diffuser. + +{empty}5. Moindre dépendance vis-à-vis des fabricants:: +Le vendor lock-in (dépendance envers les fournisseurs de logiciels) est considéré comme très élevé en informatique. L'utilisation de logiciels sous licence open source réduit le vendor lock-in, car l'exploitation, la maintenance, le support, le développement ultérieur et d'autres prestations pour les logiciels open source peuvent faire l'objet d'appels d'offres ouverts. Au lieu de réacquérir entièrement un système complet en raison d'un vendor lock-in, des extensions ou des prestations de cycle de vie pour une solution OSS peuvent aussi faire l'objet d'appels d'offres distincts. Cela permet d'économiser des coûts de migration considérables. + +{empty}6. Standards ouverts et interopérabilité:: +Avec les logiciels open source, la compatibilité avec d'autres solutions logicielles et systèmes informatiques (interopérabilité) est généralement plus élevée qu'avec les logiciels propriétaires. Les solutions open source utilisent en outre presque exclusivement des formats de données ouverts, ce qui permet de les échanger facilement avec d'autres systèmes. + +{empty}7. Transparence sur la structure du logiciel:: +Comme le logiciel est également disponible sous forme de code source, sa qualité peut être vérifiée, par exemple par des revues externes. De plus, de la documentation peut être créée à partir du code source (p. ex. en vue de nouveaux appels d'offres pour des prestations de développement ou du remplacement d'un logiciel open source en fin de vie). + +{empty}8. Sécurité et confiance grâce à la transparence:: +En raison du caractère ouvert du code source, la sécurité des logiciels open source peut être supérieure à celle des logiciels propriétaires. En outre, il est nettement plus difficile d'intégrer des portes dérobées et d'autres failles dans un logiciel open source, ce qui accroît la confiance dans le logiciel. + +{empty}9. Qualité et modularité accrues du code:: +La qualité des logiciels open source peut être supérieure à celle des logiciels propriétaires, car la motivation d'écrire du bon code est probablement plus grande lorsque les développeurs savent que leur code source sera publié. De plus, les solutions open source tendent à être fortement modulaires, de sorte que des modules individuels peuvent être facilement remplacés et les autres modules continuer à être utilisés. footnote:[Un autre aspect de sécurité est qu'il est plus facile de documenter les bibliothèques utilisées (y compris les dépendances) que dans un logiciel propriétaire. Cela signifie à son tour que, lorsque des vulnérabilités apparaissent, elles peuvent être rapidement identifiées et corrigées (voir aussi SBOM).] + +{empty}10. Adaptation aisée:: +L'accès au code source permet aux utilisateurs de réaliser eux-mêmes des développements ultérieurs ou de les confier à des fournisseurs externes. Le logiciel peut ainsi être rapidement adapté à leurs propres besoins. + +{empty}11. Innovation et intégration rapides:: +Les logiciels open source font l'objet d'un développement rapide et continu par la communauté. Ainsi, les nouvelles technologies et les nouveaux standards de données sont souvent publiés sous forme de bibliothèques de programmation open source. Cela permet la réalisation rapide de solutions logicielles innovantes. + +{empty}12. Attractivité de l'employeur:: +L'utilisation de technologies open source modernes et la collaboration informelle avec des communautés internationales favorisent la motivation des collaborateurs et accroissent ainsi l'attractivité de l'employeur, ce qui facilite à son tour le recrutement de jeunes professionnels qualifiés. + +=== Défis liés à l'OSS + +Sont décrits ci-après les défis typiques rencontrés dans la pratique avec les logiciels open source, ainsi que quelques pistes de solution. Nous n'abordons pas ici les défis généraux qui concernent tous les logiciels (p. ex. la nécessité de vérifier la cybersécurité et d'assurer un support approprié pour les logiciels critiques). + +{empty}1. Coûts de migration élevés dus aux dépendances existantes:: +Le remplacement d'un logiciel propriétaire par une solution open source peut être très coûteux si l'application est étroitement intégrée au système informatique existant par des interfaces ou d'autres dépendances. Ces coûts de migration font que l'introduction d'un logiciel open source n'est souvent rentable qu'à la fin du cycle de vie du logiciel propriétaire. + +{empty}2. Fonctionnalités manquantes ou absence de solution open source adaptée:: +Lors de l'acquisition de logiciels standard, il peut arriver qu'il n'existe aucune alternative open source à la solution propriétaire (précédente), ou seulement une alternative fonctionnellement insuffisante. Comme piste de solution, il est possible de développer les fonctionnalités manquantes conjointement avec d'autres utilisateurs du logiciel open source et de les ajouter au projet open source. footnote:[Les responsables de projet ou d'application sont compétents pour de telles nouvelles fonctionnalités. Le projet détermine exactement comment procéder. Em002-2 et Em002-4 aident à prendre des décisions détaillées. Selon l'ampleur de la fonctionnalité, il peut ne pas être judicieux de parcourir les instructions dans leur intégralité. Les aspects du droit des marchés publics relatifs aux ressources doivent être respectés.] + +{empty}3. Coûts d'intégration plus élevés:: +Les économies à court terme résultant de l'absence de licences lors de l'utilisation de logiciels open source sont souvent compensées par des coûts d'intégration plus élevés. Il est donc important de reconnaître que l'utilisation professionnelle de logiciels open source n'est pas « gratuite », mais génère bel et bien des coûts internes ou externes. + +{empty}4. Responsabilités et support peu clairs:: +Les logiciels open source sont souvent critiqués pour l'absence de support et de maintenance assurés par des entreprises externes. Il existe toutefois désormais une multitude de fournisseurs proposant des prestations commerciales (support à long terme, maintenance continue, développement ultérieur, responsabilité et garantie, etc.) pour les solutions open source. Les différents modèles d'affaires liés aux logiciels open source sont expliqués à l'annexe D et les différents modèles de support au chapitre 8. Une vue d'ensemble actuelle des prestataires open source et de leurs services figure dans l'Open Source Directory (https://www.ossdirectory.com) ou dans l'Étude OSS 2024 footnote:[https://www.oss-studie.ch/[Étude OSS]] _[OSS2024]_. + +{empty}5. Marché restreint avec peu de fournisseurs:: +Comme certaines applications open source, telles que les applications de bureau, ne nécessitent généralement que peu ou pas de support et de maintenance, le marché des fournisseurs open source de support et de maintenance peut être restreint. Dans ce cas, un appel d'offres portant sur des prestations de services pour logiciels open source peut contribuer à créer un marché qui accroît la concurrence entre les fournisseurs. L'existence d'une large communauté de développement pour le logiciel concerné et la qualité de la documentation de développement revêtent une importance pratique lors de l'appel d'offres pour de telles prestations. + +{empty}6. Faible visibilité:: +Les communautés des projets open source se concentrent avant tout sur le développement du produit et rarement sur le marketing. À l'inverse, les fabricants de logiciels propriétaires investissent massivement dans la commercialisation et la vente de leurs produits. Ce manque de publicité pour les logiciels open source donne souvent la fausse impression qu'il n'existe pas d'alternative aux produits propriétaires. Il existe cependant des plateformes telles qu'alternativeTo footnote:[https://alternativeto.net/] qui offrent une vue d'ensemble des solutions répondant à des tâches précises (plus d'informations sur les alternatives OSS au chapitre « Repérabilité des solutions OSS »). + +{empty}7. Manque d'acceptation par les utilisateurs finaux:: +En raison d'interfaces utilisateur différentes, de fonctions manquantes, d'une faible convivialité et du peu de publicité pour les logiciels open source, certains produits open source souffrent d'un manque d'acceptation de la part des utilisateurs finaux. Des offres appropriées de communication, de documentation et de formation peuvent contrer ce défi. Le fait qu'un logiciel open source puisse être développé selon les besoins des utilisateurs peut également conduire à une meilleure acceptation. + +{empty}8. Expertise interne faible ou inexistante:: +Les solutions open source évoluent rapidement et exigent en même temps une compréhension technique approfondie. Il peut donc arriver que les collaborateurs internes disposent de peu ou pas d'expertise sur certains logiciels open source. Le savoir-faire OSS interne peut être développé par la formation continue et des possibilités d'auto-apprentissage via des sources en ligne, la constitution de wikis internes, etc. + +{empty}9. Évaluation difficile de l'avenir:: +Il est souvent difficile, pour une personne extérieure à une communauté open source, de reconnaître comment le projet évoluera à l'avenir. Il est donc important de pouvoir évaluer de manière réaliste le développement futur d'une solution open source. Le chapitre « Open Hub » présente à cet égard la plateforme Open Hub, qui permet d'évaluer l'activité et l'hétérogénéité de la communauté de développement. Cela permet de mieux apprécier le développement futur d'un projet open source. + +{empty}10. Incertitudes juridiques:: +La multitude de licences open source différentes et le faible nombre de décisions judiciaires rendues à ce jour sur des questions d'interprétation peuvent parfois engendrer des incertitudes juridiques avec les logiciels open source. Le présent guide pratique vise à donner une vue d'ensemble des principales licences open source ainsi que de leurs caractéristiques et compatibilités. Des sources pour des réponses approfondies à des questions juridiques figurent dans les documents link:em002-3.pdf[Em002-3 Guide de licences OSS] et link:em002-6.pdf[Em002-6 FAQ sur l'OSS et l'art. 9 LMETA]. + +{empty}11. Offre trop vaste de logiciels open source:: +Le nombre de produits logiciels open source a fortement augmenté ces dernières années. Les utilisateurs potentiels de logiciels open source déplorent dès lors la multitude de solutions open source existant sur le marché. C'est pourquoi le chapitre « Repérabilité de… » présente deux plateformes, alternativeTo et Open Hub, qui permettent de comparer les solutions open source. + +{empty}12. Charge de coordination liée au développement conjoint:: +Lorsque l'administration fédérale participe à des projets communs et y contribue, il en résulte une charge de coordination au sein de ces collaborations, mais aussi lorsqu'une communauté doit être associée. Idéalement, cette charge supplémentaire doit malgré tout en valoir la peine grâce à une solution améliorée, une meilleure acceptation ou une participation accrue de tiers. + +== Constellations d'utilisation et de travail avec l'OSS + +=== Degrés de maturité pour l'OSS dans l'administration fédérale + +Lors de l'utilisation et du développement d'OSS au sein de l'administration fédérale, il existe différentes constellations concernant les obligations liées aux licences open source. Un modèle de maturité typique footnote:[Modèle de maturité inspiré de https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels] pour l'introduction de l'open source dans les organisations peut se présenter ainsi : + +. Denial — aucune utilisation de logiciels open source, ou utilisation inconsciente +. Consumption — utilisation passive de logiciels open source +. Participation — engagement auprès des communautés open source +. Contribution — contributions pragmatiques à des projets open source +. Leadership — engagement stratégique en faveur de l'open source pour créer de la valeur footnote:[La création n'est pas mentionnée, car l'art. 9 LMETA l'exige directement.] + +[options="header",cols="1,2a"] +|=== +|Constellation |Conséquence + +|La simple *utilisation* de logiciels open source existants (sans modification du code). +|Il n'existe *aucune obligation* de partager le code source. + +|Le *développement entièrement nouveau* d'un logiciel destiné à être publié sous une licence open source. +|*Dans ce cas, il existe une liberté totale quant à la licence sous laquelle le logiciel est publié.* Pour la Confédération, il convient de se référer au document link:em002-3.pdf[Em002-3 Guide de licences OSS]. Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent être respectés. + +|*Développement ultérieur* (interne ou externe) avec des composants open source existants (avec ou sans effet copyleft footnote:[Explication du terme « copyleft » dans link:em002-3.pdf[Em002-3 Guide de licences OSS]]), tant que le logiciel est utilisé *exclusivement au sein de la même organisation* et n'est pas rediffusé. +|Les composants OSS peuvent être combinés à volonté avec des composants tiers. La licence n'entraîne en principe aucune obligation de publication, tant que le logiciel est utilisé exclusivement au sein de la même organisation et n'est pas diffusé (exception : AGPL). Comme il n'est pas juridiquement établi de manière définitive jusqu'où s'étend la notion de « diffusion au sein de la même organisation », ce scénario ne s'applique aux composants OSS à effet copyleft que dans des cas exceptionnels. Dans ces cas, consultez le service juridique de votre organisation. Voir link:em002-3.pdf[Em002-3 Guide de licences OSS] et link:em002-6.pdf[Em002-6 FAQ sur l'OSS et l'art. 9 LMETA]. Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent être respectés. *Comme une obligation de publication découle de l'art. 9 LMETA, les modifications doivent être publiées à nouveau. Le plus simple est de le faire sous forme de modifications du projet open source existant.* + +|*Développement ultérieur* (interne ou externe) *exclusivement avec* des *composants* open source existants *sans effet copyleft*, lorsque le logiciel doit être diffusé à l'extérieur (p. ex. aux cantons). +|Les composants OSS peuvent être combinés à volonté avec des composants tiers, et les licences n'entraînent aucune obligation de publication (voir aussi link:em002-3.pdf[Em002-3 Guide de licences OSS]). *La publication est toutefois obligatoire dans le cadre de l'art. 9 LMETA. Idéalement, elle devrait se faire via le projet existant (pas de fork).* Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent être respectés. + +|*Développement ultérieur* (interne ou externe) avec des composants open source existants *à effet copyleft*, lorsque le logiciel doit être diffusé à l'extérieur (p. ex. aux cantons). +|*Il existe une obligation de publication* en raison de la licence copyleft (voir aussi link:em002-3.pdf[Em002-3 Guide de licences OSS] concernant l'effet copyleft). Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent être respectés. + +|*Contribution* à un projet open source existant. +|*Il existe en principe une obligation de publication selon la LMETA. La gouvernance et la licence du projet s'appliquent.* Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent être respectés. + +|*Développement conjoint* d'un projet nouveau ou existant avec une communauté et partage des coûts. +|*Il existe en principe une obligation de publication selon la LMETA.* Les documents link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS], link:em002-3.pdf[Em002-3 Guide de licences OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] servent *à mettre en place le projet et sa gouvernance.* + +|*Toutes les variantes de développement ou de développement ultérieur* sont réalisées *par un fournisseur ou un tiers mandaté.* +|*Il existe en principe une obligation de publication selon la LMETA.* Sur la base de link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS], link:em002-3.pdf[Em002-3 Guide de licences OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS]. Si possible, les conditions de la publication devraient être créées dès le processus d'acquisition et, au besoin, les exigences relatives à la validation du logiciel communiquées au fournisseur ou au tiers. +|=== + +=== Utilisation de logiciels open source non modifiés + +Lors de l'utilisation de logiciels open source, il n'est en principe pas déterminant de savoir sous quelle licence open source ils sont publiés, car toutes les licences open source (voir chapitre 2 « Définitions ») autorisent l'utilisation illimitée des logiciels open source, indépendamment du nombre de postes de travail, d'utilisateurs connectés simultanément, de serveurs et de processeurs, etc. sur lesquels le logiciel est utilisé. + +Lors de l'utilisation de logiciels open source non modifiés, *aucune obligation de publication* ne naît, même pour les programmes placés sous une licence à effet copyleft strict (exception : licence AGPL, Affero General Public Licence). + +Tant que le logiciel open source est introduit et exploité par des prestataires internes à la Confédération, cela peut se faire *sans procédure de marché public*, car « la licence OSS à elle seule ne coûte en règle générale rien au service acquéreur et n'est donc pas en soi pertinente du point de vue des marchés publics ». + +Si un prestataire externe est mandaté pour la maintenance, le support et d'autres prestations relatives au logiciel open source, les exigences du droit des marchés publics doivent être respectées. Différentes variantes de support sont décrites au chapitre 9. Il est en outre important d'utiliser des critères d'aptitude et d'adjudication appropriés lors de l'acquisition de logiciels open source. Les bases à ce sujet sont exposées au chapitre 8. + +=== Développement avec des composants open source et publication du code source + +Compte tenu de l'obligation de publication prévue à l'art. 9 LMETA, il convient de suivre ici la procédure décrite dans link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS]. +Les documents link:em002-3.pdf[Em002-3 Guide de licences OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS] doivent également être consultés si nécessaire. L'objectif est de publier le projet de manière contrôlée à l'aide des trois listes de contrôle _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]_. + +=== Participation à des projets ouverts (contribution) + +Les réflexions possibles concernant la contribution de l'administration fédérale à des projets ouverts déjà existants sont exposées au chapitre 4.2 du guide BITKOM _[BITKOM2024]_. footnote:[Voir https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html, chapitre 4.2.] Selon l'importance du projet pour l'administration fédérale, il convient d'examiner quelle part de responsabilité l'office concerné veut et peut assumer. + +La participation à des projets ouverts et le développement direct dans des projets ouverts peuvent également s'appuyer sur les documents relatifs à la publication. L'accent est mis sur link:em002-4.pdf[Em002-4 Guide des communautés OSS] et la liste de contrôle correspondante _link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]_. + +== Caractéristiques et choix des licences open source + +Les caractéristiques et le choix des licences open source sont décrits dans le document link:em002-3.pdf[Em002-3 Guide de licences OSS]. + +== Acquisition d'OSS + +Les questions stratégiques relatives aux acquisitions et à l'OSS sont traitées dans link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et des logiciels open source]. + +Le Centre de compétence des marchés publics de la Confédération (CCMP) a publié un nouvel aide-mémoire intitulé _Acquisition de logiciels et art. 9 LMETA https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ ainsi que deux documents « Critères types — acquisition LMETA et open source » et « Textes contractuels types — développement logiciel ». + +Une aide supplémentaire est disponible sur l'https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[intranet de l'OFCL] (accessible uniquement sur le réseau fédéral) avec les 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[_directives Open Source dans les acquisitions_] _[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]]_ et la 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[_liste de contrôle pour l'exception forfaitaire selon l'art. 9 LMETA_] _[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]]_. + +L'aptitude de l'open source à un usage en entreprise est traitée dans le document _Selection Criteria for Enterprise-Ready Open Source Software [Gu2024]_ footnote:[Voir _[Gu2024\]_] ou dans le guide Bitkom. footnote:[Voir https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software[Recommandations pratiques pour les logiciels open source | Guide 2025 | Bitkom e. V.], chapitre 3.3] + +== Repérabilité des solutions OSS + +Différentes plateformes permettent aux organisations intéressées de trouver et d'analyser des logiciels open source avant leur utilisation ou leur acquisition. Les données ainsi obtenues constituent une base pour décider de l'utilisation ou de l'acquisition d'un logiciel open source. + +Une compilation des exigences minimales et, le cas échéant, une analyse de marché devraient servir dans tous les cas. + +=== Catalogue OSS + +Les autorités fédérales sont tenues de publier le code source des logiciels qu'elles développent ou font développer pour accomplir leurs tâches. Le catalogue OSS footnote:[https://www.opensource.admin.ch/] recense tous les logiciels développés par des autorités fédérales depuis le 1er janvier 2024 et publiés en open source. Il offre une vue d'ensemble des logiciels disponibles et facilite la recherche et la réutilisation de solutions open source. + +Si un nouveau dépôt ou une nouvelle organisation est créé, cela doit être annoncé par courriel à opensource@bk.admin.ch en vue de l'inscription au catalogue OSS. + +Catalogue OSS : https://www.opensource.admin.ch + +=== OSS Directory + +L'OSS Directory exploité par CH Open footnote:[https://www.ossdirectory.com/fr/home] facilite la recherche de fournisseurs qualifiés offrant un support professionnel pour les logiciels open source. + +Les fournisseurs open source montrent, au moyen de témoignages de réussite, quels utilisateurs (clients) ils ont aidés à mettre en œuvre des produits open source déterminés. +Le Directory propose en outre des actualités open source issues de plateformes existantes, des actualités phares sélectionnées, des événements, des communautés, des offres d'emploi et des articles de partage de connaissances. L'OSS Directory est disponible en allemand, anglais, français et italien. Toutes les entrées peuvent être ajoutées et mises à jour directement par les utilisateurs enregistrés. + +OSS Directory : https://www.ossdirectory.com + +=== alternativeTo + +Un outil pratique pour trouver des alternatives à un logiciel est « alternativeTo - Crowdsourced software recommendations ». footnote:[https://alternativeto.net/] Comme son nom l'indique, les alternatives et leurs évaluations ont été créées par crowdsourcing, c'est-à-dire par les contributions de nombreux utilisateurs individuels. alternativeTo distingue quatre types de solutions logicielles, dont seul le premier est considéré comme un logiciel open source au sens de l'art. 9 LMETA : + +Free open source:: +Logiciel publié sous une licence open source. + +Free:: +Logiciel gratuit (freeware) dont le code source n'est toutefois pas librement disponible et ne peut pas être modifié. + +Freemium:: +Ce type de logiciel propose une version gratuite et une version premium, toutes les fonctionnalités importantes étant déjà disponibles dans la version gratuite. Cette catégorie ne comprend pas les logiciels pouvant être testés gratuitement pendant une période déterminée (p. ex. une version d'essai de 30 jours), qui relèvent de la catégorie « Commercial ». + +Commercial:: +Il s'agit de logiciels propriétaires pour lesquels des redevances de licence sont perçues en cas d'utilisation. + +=== Dépôts open source + +La plateforme de développement open source la plus populaire au monde à l'heure actuelle, avec plus de 30 millions d'utilisateurs et plus de 100 millions de dépôts de code source, est GitHub. footnote:[https://octoverse.github.com] Aujourd'hui, pratiquement toutes les entreprises informatiques, en particulier les fabricants de logiciels propriétaires, ainsi que de nombreux autres types d'entreprises et d'organisations, sont présents sur GitHub. De plus en plus d'autorités publiques — une douzaine environ en Suisse footnote:[https://government.github.com/community/#switzerland] — publient en outre leurs propres logiciels open source sur « GitHub and Government » à l'adresse https://government.github.com. Cette démarche peut également être réalisée avec d'autres dépôts. + +Exemples d'autres dépôts : + +* GitLab +* Bitbucket +* SourceForge +* LaunchPad + +GitHub Insights permet de consulter de nombreuses statistiques pertinentes d'un projet open source sur GitHub : + +Pulse:: +Vue d'ensemble des activités récentes d'un projet open source sur GitHub : résumé des principales informations sur l'intensité du développement, l'hétérogénéité de la communauté, les signalements ouverts, les améliorations (pull requests), etc. + +Contributors:: +Affichage des développeurs qui ont été actifs et à quel moment. Il s'agit d'un indicateur important pour savoir si tout dépend d'une seule personne ou si une communauté plus large se trouve derrière le projet. + +Commits:: +Affichage des contributions apportées à ce projet open source et de la période concernée. + +Code frequency:: +Visualisation de la quantité de code source ajoutée ou supprimée et du moment où cela s'est produit. + +Dependency graph:: +Dépendances du projet open source vis-à-vis d'autres logiciels open source (p. ex. pertinent pour identifier les failles de sécurité et les mises à jour). + +Network:: +Affichage indiquant quand quel développeur a contribué à quelle branche de développement. + +Forks:: +Liste de toutes les copies du projet open source sur GitHub. Indicateur de la popularité et de la diffusion du logiciel open source. + +=== Open Hub + +S'il s'agit de collecter des informations sur une solution open source qui n'est pas nécessairement développée sur GitHub, Open Hub de Black Duck constitue une bonne option. footnote:[https://www.openhub.net/] Pour environ un demi-million de projets open source, une multitude d'informations importantes sont résumées de manière claire : + +Project Summary:: +Une brève description du projet open source. + +In a Nutshell:: +Les faits les plus importants sur un projet open source, tels que le nombre de commits, de contributeurs et de lignes de code, ainsi que le langage de programmation le plus utilisé, la date du premier commit et de la dernière modification. Une appréciation de la base de code et de la taille de l'équipe de développement est en outre indiquée (p. ex. « Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits »). + +Quick Reference:: +Contient des informations sur l'organisation, des liens vers le projet et le code, ainsi que des renvois vers des projets similaires. + +Licences:: +Indique sous quelle(s) licence(s) le projet open source est placé et quelles conséquences y sont associées. + +Project Security:: +Fournit des indications sur la sécurité et les vulnérabilités du projet open source. + +Code:: +Un graphique montrant le nombre de lignes de code au fil du temps, ventilé par langage de programmation. + +Activity:: +Un graphique montrant le nombre de commits par mois. Un résumé des 30 derniers jours et des 12 derniers mois est également fourni. + +Community:: +Un graphique montrant le nombre de contributeurs actifs par mois. Une évaluation du projet sur une échelle de cinq étoiles est également affichée. + +Open Hub permet également de comparer différents projets open source. footnote:[https://www.openhub.net/p/_compare] Cela donne rapidement une vue d'ensemble du projet qui a la communauté la plus active, la durée de développement la plus longue ou la licence la plus appropriée. + +=== Dépôts de code particuliers + +Les grandes organisations disposent de leurs propres dépôts de code. Il convient de mentionner en particulier le dépôt allemand destiné aux autorités, opencode.de. footnote:[https://opencode.de/en/home] Les dépôts d'autres administrations publiques présentent ici un intérêt particulier. + +== Modèles de support pour l'utilisation de l'OSS + +Les logiciels open source déjà disponibles sur le marché peuvent en principe être utilisés de trois manières : + +. Utilisation sans support professionnel +. Utilisation avec support interne +. Utilisation avec support d'un fournisseur externe. + +Ces trois types d'utilisation et leurs avantages et inconvénients sont brièvement expliqués ci-après. Lequel de ces scénarios est le plus judicieux dans un cas donné doit être décidé au cas par cas. Le modèle de support approprié dépend de la pertinence stratégique du logiciel open source, de l'intégration technique et des ressources en personnel disponibles. + +Pour les logiciels critiques, le support doit dans tous les cas être assuré de manière professionnelle, en interne ou en externe. Le cycle de vie prévu devrait également jouer un rôle dans la planification du support. Il se peut aussi que le support soit obtenu auprès de plusieurs fournisseurs. + +=== Utilisation sans support professionnel + +Les logiciels open source sont disponibles sur Internet et peuvent être téléchargés, installés et utilisés gratuitement. + +Avantages:: +* Faibles coûts +* Mise en œuvre rapide + +Inconvénients:: +* Aucun support garanti +* Aucune prétention en responsabilité + +Risque et couverture:: +Risque élevé : il n'existe ni contrats de support ni garanties, et l'organisation dispose de peu ou pas de compétences en développement. + +Domaine d'application typique:: +Logiciels open source standard pouvant être mis à jour indépendamment d'autres systèmes. + +=== Utilisation avec support interne + +Une entreprise ou une organisation du secteur public développe des compétences et des ressources sur des solutions open source déterminées en vue d'une utilisation à long terme. Cette approche est particulièrement répandue dans les domaines critiques pour l'activité. + +Avantages:: +* Grande flexibilité grâce au savoir-faire interne +* Pas de dépendance envers un fournisseur + +Inconvénients:: +* Investissement et temps importants pour développer les compétences +* Coûts fixes internes plus élevés pour le personnel + +Risque et couverture:: +Risque moyen : le support dépend du savoir-faire et de la disponibilité de l'informatique interne. + +Domaine d'application typique:: +Développements propres, logiciels open source utilisés de manière stratégique et pour lesquels un savoir-faire approfondi est disponible. + +=== Utilisation avec support d'un fournisseur externe + +Un fournisseur open source externe est associé afin d'accompagner de manière professionnelle le déploiement et la maintenance du logiciel open source. Cette approche est surtout utilisée dans les domaines critiques pour l'activité, où un savoir-faire approfondi du logiciel doit être immédiatement disponible. Cela peut aussi englober une partie ou l'intégralité de la publication. + +Avantages:: +* Accès direct au savoir-faire des développeurs open source +* Corrections et extensions sur une base contractuelle +* Choix entre différents fournisseurs open source +* Engagement, couverture contre les risques de conformité + +Inconvénients:: +* Coûts externes liés aux fournisseurs open source +* Dépendance en matière de savoir-faire envers le fournisseur open source + +Risque et couverture:: +Risque faible : la garantie est fournie selon le cahier des charges ou le service level agreement + +Domaine d'application typique:: +Logiciels open source critiques pour l'activité, pour lesquels peu ou pas de compétences internes de développement sont disponibles + +== Point de contact + +Il n'existe au sein de l'administration fédérale aucun point de contact unique faisant office d'Open Source Programme Office. En principe, les offices fédéraux sont eux-mêmes responsables de la mise en œuvre. + +Les demandes générales concernant les outils OSS du jeu de documents Em002 peuvent être adressées au secteur TNI de la Chancellerie fédérale : opensource@bk.admin.ch. + +== Annexes + +=== Modifications par rapport à la version précédente + +* Chapitre 4.1 : degrés de maturité ajoutés +* Chapitre 6 : acquisition d'OSS complétée et adaptée avec les nouveaux documents de l'OFCL +* Chapitre 7.1 : nouveau catalogue OSS de la Confédération (opensource.admin.ch) +* Autres modifications et améliorations rédactionnelles mineures + +=== Références + +Les références relatives au jeu de documents Em002 figurent dans les link:em002.pdf[Em002 Lignes directrices stratégiques]. + +=== Abréviations + +Une liste d'abréviations figure dans le document principal Em002. +Un glossaire figure dans le document « link:em002-6.pdf[Em002-6 Foire aux questions sur la publication d'OSS (FAQ-OSS)] ». + +=== Modèles d'affaires avec l'OSS + +Le logiciel open source n'est pas en soi un modèle d'affaires car, contrairement au logiciel propriétaire, il n'est pas possible de vendre un logiciel placé sous licence open source. Il existe néanmoins différentes possibilités pour les entreprises d'exploiter des modèles d'affaires fondés sur les logiciels open source. Ainsi, si un support externe professionnel doit être obtenu pour une solution open source, l'acquisition des prestations commerciales correspondantes est nécessaire. Les quatre modèles d'affaires les plus courants pour les logiciels open source sont expliqués ci-après. D'autres aspects de ces modèles et d'autres encore sont exposés dans le guide BITKOM _[BITKOM2023]_. + +==== Services et produits fondés sur l'OSS + +Les entreprises peuvent proposer des services commerciaux tels que l'hébergement web ou le cloud computing sur la base de logiciels open source, ce qui serait nettement plus coûteux avec des logiciels propriétaires. C'est pourquoi la plupart des start-up, des portails en ligne et des fournisseurs de commerce électronique construisent aujourd'hui leurs plateformes sur des logiciels open source. D'autres entreprises technologiques, telles que les entreprises de télécommunications, les fournisseurs de streaming ou même les fabricants de logiciels propriétaires, intègrent des logiciels open source dans leurs produits logiciels et matériels ainsi que dans leurs services en ligne. Cela permet aux entreprises de continuer à proposer des solutions innovantes, difficilement réalisables avec des logiciels propriétaires. + +==== Services pour l'OSS + +Les fournisseurs open source fournissent des prestations pour des logiciels open source sélectionnés. Ils disposent de développeurs open source expérimentés et peuvent donc proposer du support, de la maintenance, de l'exploitation, du développement, du conseil, de la formation et d'autres prestations pour les logiciels open source. Celles-ci peuvent être obtenues auprès du fournisseur open source dans le cadre d'un mandat ou d'un contrat d'entreprise. De telles prestations pour logiciels open source peuvent faire l'objet d'appels d'offres publics, car il n'y a pas de vendor lock-in. Ce qui importe pour de tels appels d'offres, c'est la prise en compte de critères appropriés afin que les prestataires réellement compétents soient sélectionnés (voir chapitres 0 et 8, _[BITKOM2023]_ chapitre 3.3 et _[Gu2024]_). + +==== Abonnements + +Lorsque des prestations pour logiciels open source sont fournies sous une forme standardisée et récurrente, à la manière d'un service level agreement (SLA), on parle d'abonnements. Dans le cadre de tels abonnements, les entreprises garantissent par exemple des mises à jour de sécurité continues, un support par courriel ou par téléphone, la compatibilité avec d'autres produits logiciels et matériels au moyen de certifications, des prestations de maintenance à long terme et une protection contre les prétentions juridiques (droit d'auteur, brevets). En contrepartie, les clients paient des abonnements par poste de travail ou par CPU, à l'instar des redevances de licence ou d'utilisation pour les logiciels propriétaires. Contrairement aux logiciels propriétaires, les abonnements pour les logiciels open source ne constituent toutefois pas une condition d'utilisation du logiciel, mais simplement un moyen de rémunérer la valeur ajoutée des prestations fournies par le fournisseur open source. + +==== Double licence + +Si une entreprise détient la propriété intellectuelle d'une solution logicielle et que tous les composants open source intégrés sont placés sous une licence permissive, une double licence ou une licence multiple peut être appliquée. Cela permet à l'entreprise qui développe de publier le logiciel sous une licence open source copyleft et de le vendre en même temps sous une licence propriétaire. Cette version commerciale est souvent appelée version Enterprise et comprend généralement certaines fonctionnalités supplémentaires, telles que des intégrations d'interfaces exclusives ou l'autorisation pour les acheteurs d'intégrer le logiciel dans leurs propres produits propriétaires. Selon l'ampleur des restrictions de la version open source, la prudence est de mise lors de l'utilisation de logiciels sous double licence, car l'acquisition de la version Enterprise peut s'avérer inévitable, le vendor lock-in devenant alors aussi élevé qu'avec un logiciel propriétaire classique. +endif::[] + +ifeval::["{lang}" == "it"] +NOTE: 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 {url-repo}/tree/main[README] principale. + +== 1. Utilizzo della presente guida + +Secondo l'articolo 9 della legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA), la Confederazione è tenuta a pubblicare il codice sorgente del software che sviluppa o fa sviluppare per adempiere i suoi compiti. footnote:[RS 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/it] Il settore TDT della Cancelleria federale ha dedotto da questo mandato legale obiettivi generali, esposti nelle Linee guida strategiche per il software open source. + +Il presente documento funge da guida pratica alle prescrizioni giuridiche e strategiche. Intende sostenere le unità amministrative della Confederazione nell'utilizzo, nell'acquisto e nella pubblicazione di software open source. Offre a tutte le persone interessate una panoramica completa del tema e rinvia a informazioni approfondite contenute negli altri strumenti. + +A seconda delle conoscenze pregresse e delle esigenze potete tuttavia leggere le guide in modo selettivo prima di passare agli altri strumenti. La panoramica seguente vi aiuta a individuare il punto di partenza adeguato. In caso di dubbio si raccomanda di leggere dapprima la guida. + +=== Intento / parti interessate + +Introduzione generale al software open source + +* Capitolo Definizioni +* Capitolo Potenziale e sfide +* Capitolo Reperibilità delle soluzioni OSS +* link:em002-5.pdf[Em002-5 Promemoria Strumenti OSS] +* link:em002-3.pdf[Em002-3 Guida alle licenze OSS] +* link:em002-6.pdf[Em002-6 FAQ sull'OSS] + +Introduzione generale alla LMeCA per i decisori + +* link:em002-5.pdf[Em002-5 Promemoria Strumenti OSS] +* link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] + +Semplice acquisto di software destinato all'uso + +* Capitolo Livelli di maturità per l'OSS nell'Amministrazione federale +* Capitolo Utilizzo di software open source non modificato +* link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e OSS] +* Promemoria Acquisto di software e art. 9 LMeCA [KBB-MB] +* Direttive OSS negli acquisti [BBL-WL] + +Nuovo sviluppo informatico e pubblicazione + +* Capitolo Sviluppo con componenti open source e pubblicazione del codice sorgente +* Capitolo Collaborazione in progetti aperti (contribution) +* link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Lista di controllo Valutazione preliminare OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo Analisi e preparazione OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS] +* link:em002-4.pdf[Em002-4 Guida alle community OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo Community OSS] + +Acquisto di software da realizzare (prestazione di servizi o appalto) + +* Capitolo Livelli di maturità per l'OSS nell'Amministrazione federale +* Capitolo Sviluppo con componenti open source e pubblicazione del codice sorgente +* Capitolo Collaborazione in progetti aperti (contribution) +* link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e OSS] +* Cassetta degli attrezzi dell'UFCL, comprese le direttive Open Source negli acquisti +* Piattaforma di apprendimento e modelli dell'amministrazione pubblica del CCAP (www.perimap.admin.ch), compreso Acquisto di software e art. 9 LMeCA [KBB-MB] +* Direttive OSS negli acquisti [BBL-WL] +* link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Lista di controllo Valutazione preliminare OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo Analisi e preparazione OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS] +* link:em002-4.pdf[Em002-4 Guida alle community OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo Community OSS] + +Accertamenti giuridici in vista della pubblicazione + +* link:em002-6.pdf[Em002-6 Domande frequenti sulla pubblicazione di OSS (FAQ-OSS)] +* link:em002-3.pdf[Em002-3 Guida alle licenze OSS] + +Principi di lavoro per i capiprogetto + +* https://www.hermes.admin.ch/[Documenti HERMES] +* link:em002-5.pdf[Em002-5 Promemoria Strumenti OSS] + +Contributi di software a terzi e collaborazioni + +* link:em002-4.pdf[Em002-4 Guida alle community OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo Community OSS] +* link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e OSS] +* link:em002-3.pdf[Em002-3 Guida alle licenze OSS] + +Il grafico seguente offre una panoramica dei documenti rilevanti per l'OSS nell'Amministrazione federale. + +include::partials/document-map.it.adoc[] + +Figura 1: Panoramica degli strumenti OSS in relazione all'art. 9 LMeCA + +== Definizioni + +Software open source:: +Un software è considerato software open source (OSS) quando è pubblicato sotto una delle circa 80 licenze riconosciute dall'Open Source Initiative OSI _[OSI2024]_. Concretamente, la definizione di open source stabilisce dieci criteri che tutte le licenze open source devono soddisfare _[Pe1999]_. Essi possono essere sostanzialmente riassunti in quattro punti: ++ +. Il software può essere utilizzato per qualsiasi scopo. +. Il codice sorgente del software è liberamente accessibile. +. Il software può essere copiato e diffuso senza restrizioni. +. Il software può essere modificato e diffuso in forma modificata a determinate condizioni. + +Software libero:: +Prima del termine «open source», negli anni Ottanta la Free Software Foundation (FSF) ha introdotto il concetto di «software libero». Nella sostanza il software libero soddisfa le condizioni del software open source, ma mira a garantire che il software resti sempre liberamente accessibile e, per quanto possibile, non venga integrato in software proprietario. footnote:[https://it.wikipedia.org/wiki/Software_libero[Software libero -- Wikipedia]] + +Software proprietario:: +Nel caso del software proprietario un fornitore sviluppa il software e vende all'utente una licenza d'uso. Di regola l'utente non conosce il codice del software e non può né ridistribuirlo né modificarlo. Può utilizzare il software soltanto secondo le condizioni di licenza (p. es. End-User Licence Agreement, EULA) dietro pagamento di tasse di licenza. Il software può ad esempio essere autorizzato soltanto per un determinato numero di utenti o un determinato numero di processori. footnote:[https://it.wikipedia.org/wiki/Software_proprietario[Software proprietario -- Wikipedia]] In cambio delle spese di manutenzione, di regola annuali, il fornitore si impegna a correggere gli errori entro un termine adeguato e a sviluppare continuamente il software. + +Licenza:: +Una licenza è un documento che contiene prescrizioni vincolanti per l'utilizzo e la diffusione di un software. Nell'ambito open source si utilizzano di regola licenze conformi all'OSI. footnote:[https://opensource.org/[Open Source Initiative]] + +Community:: +Il concetto di community nel contesto del software open source è definito in senso ampio. Può trattarsi di un ecosistema informale o di una struttura dotata di governance che sviluppa il software. Il documento link:em002-4.pdf[Em002-4 Guida alle community OSS] tratta questo tema. I membri della community possono gestire congiuntamente il prodotto, svilupparlo, testarlo, tradurlo, fornire riscontri o semplicemente utilizzare il software. + +Diritti di terzi:: +Anche per il software open source possono esistere diritti di protezione (diritto d'autore, diritto dei marchi, diritto dei brevetti), che possono essere fatti valere da terzi, p. es. utilizzando codice sorgente creato da terzi. + +Eccezioni secondo la LMeCA:: +Le eccezioni secondo l'art. 9 cpv. 1 LMeCA sono i diritti di terzi e i motivi rilevanti per la sicurezza. Entrambi sono trattati nel capitolo 3 di link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +Codice sorgente:: +In informatica il codice sorgente (o testo sorgente) è il testo leggibile dall'essere umano di un programma per computer, redatto in un linguaggio di programmazione. footnote:[https://it.wikipedia.org/wiki/Codice_sorgente[Codice sorgente -- Wikipedia]] + +Pubblicazione:: +Per pubblicazione si intende in primo luogo la messa a disposizione del codice sorgente sotto una licenza aperta conforme all'OSI. Per ragioni pratiche essa comprende di regola anche la documentazione e le istruzioni automatizzate per costruire l'applicazione a partire dal codice sorgente. Anche i test automatizzati e i documenti di test ne fanno solitamente parte. Affinché una community possa svilupparsi si utilizza una piattaforma che assume poi diverse funzioni di una piattaforma di sviluppo (build, test, supporto). + +Sovranità digitale:: +Utilizziamo la definizione contenuta nel rapporto del DFAE sulla sovranità digitale [St2024]: «La sovranità digitale di uno Stato o di un'organizzazione comprende necessariamente il controllo completo dei dati memorizzati ed elaborati nonché la decisione autonoma su chi possa accedervi. Essa comprende inoltre la capacità di sviluppare, modificare, controllare e completare autonomamente componenti e sistemi tecnologici.» + +Repository:: +Un repository è un luogo di archiviazione utilizzato da uno strumento di gestione delle versioni per i file e i metadati relativi alla base di codice. I repository consentono a più collaboratori di lavorare sugli stessi file e di archiviare diverse versioni. La maggior parte consente inoltre l'issue tracking, la gestione delle release, le build automatizzate e la documentazione. + +Fork:: +Un fork footnote:[https://it.wikipedia.org/wiki/Fork_(sviluppo_software)[Fork (sviluppo software) -- Wikipedia]] di un progetto open source è il processo di avviare uno sviluppo indipendente del progetto originario. + +Contributor Licence Agreement (CLA):: +Un Contributor Licence Agreement footnote:[https://en.wikipedia.org/wiki/Contributor_License_Agreement[Contributor License Agreement -- Wikipedia]] è un documento che descrive le condizioni alle quali è possibile apportare proprietà intellettuale a un progetto o a un'iniziativa. + +Source code management (SCM):: +La gestione del codice sorgente footnote:[https://it.wikipedia.org/wiki/Controllo_versione[Controllo versione -- Wikipedia]], detta anche gestione delle versioni, è uno strumento che gestisce efficacemente modifiche e numeri di versione, in particolare nello sviluppo software. Si è affermato il software libero Git footnote:[https://it.wikipedia.org/wiki/Git[Git -- Wikipedia]] per la gestione di SCM distribuiti. + +Open source software development (OSSD):: +Nello sviluppo di software open source (OSSD) footnote:[https://en.wikipedia.org/wiki/Open-source_software_development[Open-source software development -- Wikipedia]], oltre alla pubblicazione del codice sorgente, l'intero processo di sviluppo si svolge pubblicamente. Tutto, dai requisiti (issue) al codice sorgente, è trasparente. L'OSSD è supportato da strumenti di comunicazione pubblici (mailing list, forum ecc.), da un sistema di gestione delle versioni (Git), da elenchi di errori e funzionalità, da una roadmap e da strumenti per sviluppatori. + +Software Package Data Exchange (SPDX):: +Software Package Data Exchange (SPDX) footnote:[https://en.wikipedia.org/wiki/Software_Package_Data_Exchange[Software Package Data Exchange -- Wikipedia]] descrive un formato standard per la Software Bill of Materials (SBOM), con l'obiettivo di agevolare la corretta gestione del software libero o open source. + +Effetto copyleft:: +Se un software è soggetto a una licenza con clausola di copyleft, ogni modifica o estensione del codice sorgente deve essere nuovamente pubblicata sotto la licenza del software open source modificato (cfr. anche link:em002-3.pdf[Em002-3 Guida alle licenze OSS]). + +== Potenziale e sfide + +Nell'odierno mondo informatico il software open source presenta un potenziale enorme. Al tempo stesso l'impiego di soluzioni open source comporta anche sfide. Questi due aspetti sono illustrati più in dettaglio nella sezione seguente. Le indicazioni si basano tra l'altro sui risultati dello Studio Open Source Svizzera 2018, 2021 e 2024 dell'Università di Berna, nel quale gli interpellati hanno fornito informazioni sui vantaggi e sugli svantaggi riconosciuti del software open source. + +=== Potenziale del software open source + +I punti seguenti descrivono il potenziale che può essere realizzato impiegando e pubblicando software open source. + +{empty}1. Sovranità digitale:: +Si tratta della capacità di utilizzare e controllare i servizi digitali. La sovranità digitale si estende all'intero ciclo di vita di un sistema digitale. Il software open source promuove la sovranità digitale, poiché garantisce intercambiabilità, libertà di configurazione e influenza. footnote:[Utilizziamo la definizione di _[St2024\]_: «La sovranità digitale di uno Stato o di un'organizzazione comprende necessariamente il controllo completo dei dati memorizzati ed elaborati nonché la decisione autonoma su chi possa accedervi. Essa comprende inoltre la capacità di sviluppare, modificare, controllare e completare autonomamente componenti e sistemi tecnologici.»] + +{empty}2. Nessuna tassa di licenza:: +Per l'utilizzo di software open source non sorgono costi di licenza. Nell'acquisire pacchetti standard open source complessi può tuttavia essere opportuno acquistare abbonamenti di supporto a pagamento. + +{empty}3. Risparmi grazie alla cooperazione con altri utenti:: +Poiché un software soggetto a una licenza open source può essere utilizzato e sviluppato senza restrizioni, i costi degli sviluppi ulteriori possono essere condivisi oppure è possibile riprendere sviluppi aggiuntivi esistenti di altre unità amministrative secondo il principio «sviluppare una volta — utilizzare più volte». Al tempo stesso si può beneficiare dell'esperienza e degli sviluppi altrui. + +{empty}4. Costituzione di community e condivisione delle conoscenze:: +Il software open source facilita la costituzione di community e la condivisione delle conoscenze, per esempio tra i diversi livelli federali in Svizzera. Il software può essere sviluppato congiuntamente, gli errori possono essere corretti e le esperienze individuali condivise. L'accresciuto scambio di conoscenze tra diverse unità amministrative porta a una migliore comprensione di ciò a cui lavorano gli altri, così da evitare doppioni e permettere alle soluzioni migliori di diffondersi. + +{empty}5. Minore dipendenza dai fabbricanti:: +Il vendor lock-in (dipendenza dai fornitori di software) è considerato molto elevato in informatica. L'impiego di software soggetto a licenza open source riduce il vendor lock-in, poiché esercizio, manutenzione, supporto, sviluppo ulteriore e altre prestazioni per il software open source possono essere messi a concorso pubblicamente. Invece di riacquistare integralmente un intero sistema a causa di un vendor lock-in, è possibile mettere a concorso separatamente anche estensioni o prestazioni del ciclo di vita per una soluzione OSS. Ciò consente di risparmiare notevoli costi di migrazione. + +{empty}6. Standard aperti e interoperabilità:: +Con il software open source la compatibilità con altre soluzioni software e sistemi informatici (interoperabilità) è di regola maggiore rispetto al software proprietario. Le soluzioni open source utilizzano inoltre quasi esclusivamente formati di dati aperti, per cui possono essere facilmente scambiate con altri sistemi. + +{empty}7. Trasparenza sulla struttura del software:: +Poiché il software è disponibile anche sotto forma di codice sorgente, la sua qualità può essere verificata, per esempio mediante revisioni esterne. Inoltre, sulla base del codice sorgente è possibile creare documentazione (p. es. in vista di nuovi bandi per prestazioni di sviluppo o della sostituzione di software open source al termine della sua vita utile). + +{empty}8. Sicurezza e fiducia grazie alla trasparenza:: +Data l'apertura del codice sorgente, la sicurezza del software open source può essere superiore a quella del software proprietario. È inoltre molto più difficile inserire backdoor e altre falle nel software open source, il che accresce la fiducia nel software. + +{empty}9. Maggiore qualità e modularità del codice:: +La qualità del software open source può essere superiore a quella del software proprietario, poiché la motivazione a scrivere codice di qualità è verosimilmente maggiore quando gli sviluppatori sanno che il loro codice sorgente sarà pubblicato. Inoltre le soluzioni open source tendono a essere fortemente modulari, per cui singoli moduli possono essere facilmente sostituiti e i restanti continuare a essere utilizzati. footnote:[Un ulteriore aspetto di sicurezza è che le librerie utilizzate (comprese le dipendenze) sono più facili da documentare rispetto al software proprietario. Ciò significa a sua volta che, quando emergono vulnerabilità, esse possono essere individuate e corrette rapidamente (cfr. anche SBOM).] + +{empty}10. Adattamento semplice:: +L'accesso al codice sorgente consente agli utenti di effettuare sviluppi ulteriori autonomamente o tramite fornitori esterni. Il software può così essere adattato rapidamente alle proprie esigenze. + +{empty}11. Innovazione e integrazione rapide:: +Il software open source viene sviluppato rapidamente e continuamente dalla community. Nuove tecnologie e nuovi standard di dati vengono per esempio spesso pubblicati come librerie di programmazione open source. Ciò consente la rapida realizzazione di soluzioni software innovative. + +{empty}12. Attrattiva del datore di lavoro:: +L'impiego di moderne tecnologie open source e la collaborazione informale con community internazionali favoriscono la motivazione dei collaboratori e accrescono così l'attrattiva del datore di lavoro, il che agevola a sua volta il reclutamento di giovani professionisti qualificati. + +=== Sfide nella gestione dell'OSS + +Di seguito sono descritte le sfide tipiche che si incontrano nella pratica con il software open source e sono delineate alcune possibili soluzioni. Non trattiamo in questa sede le sfide generali che riguardano tutti i software (p. es. la necessità di verificare la cibersicurezza e di assicurare un supporto adeguato per il software critico). + +{empty}1. Elevati costi di passaggio dovuti a dipendenze esistenti:: +La sostituzione di software proprietario con soluzioni open source può risultare molto onerosa se l'applicazione è strettamente integrata nel sistema informatico esistente mediante interfacce o altre dipendenze. Questi costi di passaggio fanno sì che l'introduzione di software open source sia spesso conveniente soltanto al termine del ciclo di vita del software proprietario. + +{empty}2. Funzionalità mancanti o assenza di una soluzione open source adeguata:: +Nell'acquisto di software standard può accadere che non esista alcuna alternativa open source alla soluzione proprietaria (precedente), oppure soltanto una funzionalmente insufficiente. Come possibile soluzione vi è la facoltà di sviluppare le funzionalità mancanti insieme ad altri utenti del software open source e di aggiungerle al progetto open source. footnote:[Per tali nuove funzionalità sono competenti i responsabili di progetto o di applicazione. Le modalità precise sono stabilite dal progetto. Em002-2 ed Em002-4 aiutano nelle decisioni di dettaglio. A seconda dell'entità della funzionalità può non essere opportuno percorrere integralmente le istruzioni. Vanno osservati gli aspetti del diritto degli acquisti pubblici relativi alle risorse.] + +{empty}3. Maggiori costi d'integrazione:: +I risparmi a breve termine derivanti dalle licenze non dovute nell'impiego di software open source sono spesso compensati da maggiori costi d'integrazione. È quindi importante riconoscere che l'impiego professionale di software open source non è «gratuito», ma genera effettivamente costi interni o esterni. + +{empty}4. Responsabilità e supporto poco chiari:: +Il software open source è spesso criticato per la mancanza di supporto e manutenzione da parte di imprese esterne. Esiste tuttavia ormai una molteplicità di fornitori che offrono prestazioni commerciali (supporto a lungo termine, manutenzione continua, sviluppo ulteriore, responsabilità e garanzia ecc.) per le soluzioni open source. I diversi modelli di business con il software open source sono illustrati nell'allegato D e i diversi modelli di supporto nel capitolo 8. Una panoramica aggiornata dei fornitori di servizi open source e delle loro prestazioni figura nell'Open Source Directory (https://www.ossdirectory.com) o nello Studio OSS 2024 footnote:[https://www.oss-studie.ch/[Studio OSS]] _[OSS2024]_. + +{empty}5. Mercato ristretto con pochi fornitori:: +Poiché determinate applicazioni open source, come quelle desktop, richiedono di regola poco o nessun supporto e manutenzione, il mercato dei fornitori open source di supporto e manutenzione può essere ristretto. In tal caso un bando per prestazioni di servizi relative a software open source può contribuire a creare un mercato che accresca la concorrenza tra i fornitori. L'esistenza di un'ampia community di sviluppo per il software in questione e la qualità della documentazione di sviluppo rivestono importanza pratica nel mettere a concorso tali prestazioni. + +{empty}6. Scarsa visibilità:: +Le community dei progetti open source si concentrano soprattutto sullo sviluppo del prodotto e raramente sul marketing. Per contro i fabbricanti di software proprietario investono massicciamente nella commercializzazione e nella vendita dei loro prodotti. Questa mancanza di pubblicità per il software open source crea spesso la falsa impressione che non esistano alternative ai prodotti proprietari. Vi sono però piattaforme come alternativeTo footnote:[https://alternativeto.net/] che offrono una panoramica delle soluzioni per compiti specifici (maggiori informazioni sulle alternative OSS nel capitolo «Reperibilità delle soluzioni OSS»). + +{empty}7. Mancanza di accettazione da parte degli utenti finali:: +A causa di interfacce utente differenti, funzioni mancanti, scarsa facilità d'uso e poca pubblicità per il software open source, determinati prodotti open source soffrono di una mancanza di accettazione da parte degli utenti finali. Adeguate offerte di comunicazione, documentazione e formazione possono contrastare questa sfida. Anche il fatto che il software open source possa essere sviluppato secondo le esigenze degli utenti può portare a una maggiore accettazione. + +{empty}8. Competenze interne scarse o inesistenti:: +Le soluzioni open source evolvono rapidamente e richiedono al tempo stesso una profonda comprensione tecnica. Può quindi accadere che i collaboratori interni dispongano di poche o nessuna competenza su determinati software open source. Il know-how OSS interno può essere sviluppato mediante il perfezionamento e possibilità di autoapprendimento tramite fonti online, la creazione di wiki interni ecc. + +{empty}9. Difficile valutazione del futuro:: +Per chi è esterno a una community open source è spesso difficile riconoscere come il progetto si svilupperà in futuro. È quindi importante poter valutare realisticamente lo sviluppo futuro di una soluzione open source. Il capitolo «Open Hub» presenta a tal fine la piattaforma Open Hub, che consente di valutare l'attività e l'eterogeneità della community di sviluppo. Ciò permette di apprezzare meglio lo sviluppo futuro di un progetto open source. + +{empty}10. Incertezze giuridiche:: +La molteplicità di licenze open source diverse e il numero finora esiguo di sentenze giudiziarie su questioni interpretative possono talvolta generare incertezze giuridiche con il software open source. La presente guida pratica intende offrire una panoramica delle principali licenze open source nonché delle loro caratteristiche e compatibilità. Fonti per risposte approfondite a questioni giuridiche figurano nei documenti link:em002-3.pdf[Em002-3 Guida alle licenze OSS] e link:em002-6.pdf[Em002-6 FAQ sull'OSS e l'art. 9 LMeCA]. + +{empty}11. Offerta troppo ampia di software open source:: +Il numero di prodotti software open source è fortemente aumentato negli ultimi anni. I potenziali utenti di software open source lamentano pertanto la molteplicità di soluzioni open source presenti sul mercato. Per questo motivo il capitolo «Reperibilità di…» presenta due piattaforme, alternativeTo e Open Hub, che consentono di confrontare le soluzioni open source. + +{empty}12. Onere di coordinamento nello sviluppo congiunto:: +Quando l'Amministrazione federale partecipa a progetti comuni e vi contribuisce, ne deriva un onere di coordinamento all'interno di tali collaborazioni, ma anche quando occorre coinvolgere una community. Idealmente questo onere supplementare dovrebbe comunque risultare conveniente grazie a una soluzione migliore, a una maggiore accettazione o a una partecipazione accresciuta di terzi. + +== Costellazioni per l'utilizzo e il lavoro con l'OSS + +=== Livelli di maturità per l'OSS nell'Amministrazione federale + +Nell'impiego e nello sviluppo di OSS nell'Amministrazione federale esistono diverse costellazioni riguardo agli obblighi connessi alle licenze open source. Un tipico modello di maturità footnote:[Modello di maturità ispirato a https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels] per l'introduzione dell'open source nelle organizzazioni può presentarsi così: + +. Denial — nessun impiego di software open source, o impiego inconsapevole +. Consumption — impiego passivo di software open source +. Participation — impegno nelle community open source +. Contribution — contributi pragmatici a progetti open source +. Leadership — impegno strategico con l'open source per creare valore footnote:[La creazione non è menzionata, poiché l'art. 9 LMeCA la esige direttamente.] + +[options="header",cols="1,2a"] +|=== +|Costellazione |Conseguenza + +|Il semplice *utilizzo* di software open source esistente (senza modifica del codice). +|Non sussiste *alcun obbligo* di condividere il codice sorgente. + +|Lo *sviluppo interamente nuovo* di software destinato a essere pubblicato sotto una licenza open source. +|*In tal caso sussiste piena libertà quanto alla licenza sotto la quale il software viene pubblicato.* Per la Confederazione va consultato il documento link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. Vanno osservati i documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +|*Sviluppo ulteriore* (interno o esterno) con componenti open source esistenti (con o senza effetto copyleft footnote:[Spiegazione del termine «copyleft» in link:em002-3.pdf[Em002-3 Guida alle licenze OSS]]), fintanto che il software è utilizzato *esclusivamente all'interno della stessa organizzazione* e non è ridistribuito. +|I componenti OSS possono essere combinati a piacimento con componenti di terzi. Dalla licenza non deriva in linea di principio alcun obbligo di pubblicazione, fintanto che il software è utilizzato esclusivamente all'interno della stessa organizzazione e non è diffuso (eccezione: AGPL). Poiché non è giuridicamente chiarito in modo definitivo fin dove si estenda il concetto di «diffusione all'interno della stessa organizzazione», questo scenario si applica ai componenti OSS con effetto copyleft soltanto in casi eccezionali. In tali casi consultate il servizio giuridico della vostra organizzazione. Cfr. link:em002-3.pdf[Em002-3 Guida alle licenze OSS] ed link:em002-6.pdf[Em002-6 FAQ sull'OSS e l'art. 9 LMeCA]. Vanno osservati i documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. *Poiché secondo l'art. 9 LMeCA sussiste un obbligo di pubblicazione, le modifiche devono essere nuovamente pubblicate. Il modo più semplice è farlo come modifiche al progetto open source esistente.* + +|*Sviluppo ulteriore* (interno o esterno) *esclusivamente con* componenti open source esistenti *senza effetto copyleft*, se il software deve essere diffuso all'esterno (p. es. ai Cantoni). +|I componenti OSS possono essere combinati a piacimento con componenti di terzi e dalle licenze non deriva alcun obbligo di pubblicazione (cfr. anche link:em002-3.pdf[Em002-3 Guida alle licenze OSS]). *Nel quadro dell'art. 9 LMeCA la pubblicazione è tuttavia obbligatoria. Idealmente essa dovrebbe avvenire tramite il progetto esistente (nessun fork).* Vanno osservati i documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +|*Sviluppo ulteriore* (interno o esterno) con componenti open source esistenti *con effetto copyleft*, se il software deve essere diffuso all'esterno (p. es. ai Cantoni). +|*Sussiste un obbligo di pubblicazione* in virtù della licenza copyleft (cfr. anche link:em002-3.pdf[Em002-3 Guida alle licenze OSS] riguardo all'effetto copyleft). Vanno osservati i documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +|*Contributo* a un progetto open source esistente. +|*Secondo la LMeCA sussiste di regola un obbligo di pubblicazione. Si applicano la governance e la licenza del progetto.* Vanno osservati i documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +|*Sviluppo congiunto* di un progetto nuovo o esistente con una community e ripartizione dei costi. +|*Secondo la LMeCA sussiste di regola un obbligo di pubblicazione.* I documenti link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS], link:em002-3.pdf[Em002-3 Guida alle licenze OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS] servono *a impostare il progetto e la sua governance.* + +|*Tutte le varianti di sviluppo o di sviluppo ulteriore* sono realizzate *tramite un fornitore o terzi incaricati.* +|*Secondo la LMeCA sussiste di regola un obbligo di pubblicazione.* Sulla base di link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS], link:em002-3.pdf[Em002-3 Guida alle licenze OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. Se possibile, i presupposti per la pubblicazione andrebbero creati già nel processo d'acquisto e, se necessario, i requisiti per il rilascio del software andrebbero comunicati al fornitore o ai terzi. +|=== + +=== Utilizzo di software open source non modificato + +Nell'utilizzo di software open source non è in linea di principio determinante sapere sotto quale licenza open source esso sia pubblicato, poiché tutte le licenze open source (cfr. capitolo 2 «Definizioni») consentono l'uso illimitato del software open source, indipendentemente dal numero di postazioni di lavoro, di utenti collegati simultaneamente, di server e processori ecc. su cui il software è impiegato. + +Nell'utilizzo di software open source non modificato non sorge *alcun obbligo di pubblicazione*, nemmeno per i programmi soggetti a una licenza con effetto copyleft rigoroso (eccezione: licenza AGPL, Affero General Public Licence). + +Fintanto che il software open source è introdotto ed esercito da fornitori di prestazioni interni alla Confederazione, ciò può avvenire *senza procedura di acquisto pubblico*, poiché «la sola licenza OSS di regola non costa nulla al servizio acquirente e non è quindi di per sé rilevante sotto il profilo degli acquisti pubblici». + +Se per la manutenzione, il supporto e altre prestazioni relative al software open source è incaricato un fornitore esterno, vanno osservate le prescrizioni del diritto degli acquisti pubblici. Diverse varianti di supporto sono descritte nel capitolo 9. È inoltre importante utilizzare criteri di idoneità e di aggiudicazione adeguati nell'acquisto di software open source. Le basi al riguardo sono illustrate nel capitolo 8. + +=== Sviluppo con componenti open source e pubblicazione del codice sorgente + +Con l'obbligo di pubblicazione secondo l'art. 9 LMeCA occorre qui seguire la procedura descritta in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS]. +Se necessario vanno consultati anche i documenti link:em002-3.pdf[Em002-3 Guida alle licenze OSS] ed link:em002-4.pdf[Em002-4 Guida alle community OSS]. L'obiettivo è pubblicare il progetto in modo controllato sulla base delle tre liste di controllo _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]_. + +=== Collaborazione in progetti aperti (contribution) + +Le possibili riflessioni sul contributo dell'Amministrazione federale a progetti aperti già esistenti sono esposte nel capitolo 4.2 della guida BITKOM _[BITKOM2024]_. footnote:[Cfr. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html, capitolo 4.2.] A seconda dell'importanza del progetto per l'Amministrazione federale occorre valutare quanta responsabilità il rispettivo ufficio intenda e possa assumere. + +La collaborazione in progetti aperti e lo sviluppo diretto in progetti aperti possono parimenti avvenire sulla base dei documenti per la pubblicazione. Al centro figurano link:em002-4.pdf[Em002-4 Guida alle community OSS] e la relativa lista di controllo _link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]_. + +== Caratteristiche e scelta delle licenze open source + +Le caratteristiche e la scelta delle licenze open source sono descritte nel documento link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. + +== Acquisto di OSS + +Le questioni strategiche relative agli acquisti e all'OSS sono trattate in link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e del software open source]. + +Il Centro di competenza per gli acquisti pubblici della Confederazione (CCAP) ha pubblicato un nuovo promemoria intitolato _Acquisto di software e art. 9 LMeCA https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ nonché due documenti «Criteri tipo — acquisto LMeCA e open source» e «Testi contrattuali tipo — sviluppo software». + +Ulteriore sostegno è disponibile sull'https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[intranet dell'UFCL] (accessibile soltanto dalla rete federale) con le 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[_direttive Open Source negli acquisti_] _[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]]_ e la 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[_lista di controllo per l'eccezione forfettaria secondo l'art. 9 LMeCA_] _[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]]_. + +L'idoneità dell'open source all'uso aziendale è trattata nel documento _Selection Criteria for Enterprise-Ready Open Source Software [Gu2024]_ footnote:[Cfr. _[Gu2024\]_] o nella guida Bitkom. footnote:[Cfr. https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software[Raccomandazioni pratiche per il software open source | Guida 2025 | Bitkom e. V.], capitolo 3.3] + +== Reperibilità delle soluzioni OSS + +Diverse piattaforme consentono alle organizzazioni interessate di trovare e analizzare software open source prima dell'utilizzo o dell'acquisto. I dati così ottenuti costituiscono una base per decidere in merito all'impiego o all'acquisto di software open source. + +Una raccolta di requisiti minimi e, se del caso, un'analisi di mercato dovrebbero in ogni caso essere d'ausilio. + +=== Catalogo OSS + +Le autorità federali sono tenute a pubblicare il codice sorgente del software che sviluppano o fanno sviluppare per adempiere i loro compiti. Il catalogo OSS footnote:[https://www.opensource.admin.ch/] elenca tutto il software sviluppato dalle autorità federali dal 1° gennaio 2024 e pubblicato come open source. Offre una panoramica del software disponibile e agevola il reperimento e il riutilizzo di soluzioni open source. + +Se viene creato un nuovo repository o una nuova organizzazione, ciò va segnalato per l'inserimento nel catalogo OSS all'indirizzo e-mail opensource@bk.admin.ch. + +Catalogo OSS: https://www.opensource.admin.ch + +=== OSS Directory + +L'OSS Directory gestito da CH Open footnote:[https://www.ossdirectory.com/it/home] agevola il reperimento di fornitori qualificati che offrono supporto professionale per il software open source. + +I fornitori open source mostrano, mediante casi di successo, quali utenti (clienti) hanno aiutato a introdurre determinati prodotti open source. +Il Directory propone inoltre notizie open source aggiornate provenienti da piattaforme esistenti, notizie di rilievo selezionate, eventi, community, offerte di lavoro e articoli per la condivisione delle conoscenze. L'OSS Directory è disponibile in tedesco, inglese, francese e italiano. Tutte le voci possono essere aggiunte e aggiornate direttamente dagli utenti registrati. + +OSS Directory: https://www.ossdirectory.com + +=== alternativeTo + +Uno strumento pratico per trovare alternative a un software è «alternativeTo - Crowdsourced software recommendations». footnote:[https://alternativeto.net/] Come suggerisce il nome, le alternative e le relative valutazioni sono nate tramite crowdsourcing, ossia grazie ai contributi di molti singoli utenti. alternativeTo distingue quattro tipi di soluzioni software, di cui soltanto il primo è considerato software open source ai sensi dell'art. 9 LMeCA: + +Free open source:: +Software pubblicato sotto una licenza open source. + +Free:: +Software gratuito (freeware) il cui codice sorgente non è però liberamente disponibile e non può essere modificato. + +Freemium:: +Tale software offre una versione gratuita e una premium, con tutte le funzionalità importanti già disponibili nella versione gratuita. Non rientra in questa categoria il software che può essere testato gratuitamente per un periodo determinato (p. es. una versione di prova di 30 giorni), che ricade nella categoria «Commercial». + +Commercial:: +Si tratta di software proprietario per il cui utilizzo sono riscosse tasse di licenza. + +=== Repository open source + +Attualmente la piattaforma di sviluppo open source più popolare al mondo, con oltre 30 milioni di utenti e oltre 100 milioni di repository di codice sorgente, è GitHub. footnote:[https://octoverse.github.com] Oggi praticamente tutte le imprese informatiche, in particolare i fabbricanti di software proprietario, nonché molti altri tipi di imprese e organizzazioni sono presenti su GitHub. Sempre più autorità pubbliche — una dozzina circa dalla Svizzera footnote:[https://government.github.com/community/#switzerland] — pubblicano inoltre il proprio software open source su «GitHub and Government» all'indirizzo https://government.github.com. Questa procedura può essere svolta anche con altri repository. + +Esempi di altri repository sono: + +* GitLab +* Bitbucket +* SourceForge +* LaunchPad + +Su GitHub Insights è possibile consultare numerose statistiche rilevanti di un progetto open source su GitHub: + +Pulse:: +Panoramica delle attività recenti di un progetto open source su GitHub: sintesi delle informazioni principali su intensità di sviluppo, eterogeneità della community, segnalazioni aperte, miglioramenti (pull request) ecc. + +Contributors:: +Indicazione di quali sviluppatori sono stati attivi e quando. È un indicatore importante per sapere se tutto dipende da una sola persona o se dietro vi è una community più ampia. + +Commits:: +Indicazione di quali contributi sono stati apportati a questo progetto open source e in quale periodo. + +Code frequency:: +Visualizzazione di quanto codice sorgente è stato aggiunto o rimosso e quando. + +Dependency graph:: +Dipendenze del progetto open source da altro software open source (p. es. rilevante per individuare vulnerabilità di sicurezza e aggiornamenti). + +Network:: +Indicazione di quando quale sviluppatore ha contribuito a quale ramo di sviluppo. + +Forks:: +Elenco di tutte le copie del progetto open source su GitHub. Indicatore della popolarità e della diffusione del software open source. + +=== Open Hub + +Se occorre raccogliere informazioni su una soluzione open source che non è necessariamente sviluppata su GitHub, Open Hub di Black Duck rappresenta una buona opzione. footnote:[https://www.openhub.net/] Per circa mezzo milione di progetti open source vengono riassunte in modo chiaro numerose informazioni importanti: + +Project Summary:: +Una breve descrizione del progetto open source. + +In a Nutshell:: +I fatti più importanti su un progetto open source, quali il numero di commit, di collaboratori e di righe di codice, nonché il linguaggio di programmazione più utilizzato, la data del primo commit e dell'ultima modifica. È inoltre indicata una valutazione della base di codice e delle dimensioni del team di sviluppo (p. es. «Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits»). + +Quick Reference:: +Contiene informazioni sull'organizzazione, collegamenti al progetto e al codice nonché rinvii a progetti analoghi. + +Licences:: +Indica sotto quale licenza o quali licenze il progetto open source è licenziato e quali conseguenze ne derivano. + +Project Security:: +Fornisce indicazioni sulla sicurezza e sulle vulnerabilità del progetto open source. + +Code:: +Un grafico che mostra il numero di righe di codice nel tempo, suddiviso per linguaggio di programmazione. + +Activity:: +Un grafico che mostra il numero di commit al mese. È inoltre fornita una sintesi degli ultimi 30 giorni e 12 mesi. + +Community:: +Un grafico che mostra il numero di collaboratori attivi al mese. È inoltre visualizzata una valutazione del progetto su una scala a cinque stelle. + +Open Hub consente anche di confrontare diversi progetti open source. footnote:[https://www.openhub.net/p/_compare] Ciò fornisce rapidamente una panoramica di quale progetto abbia la community più attiva, il tempo di sviluppo più lungo o la licenza più adeguata. + +=== Repository di codice particolari + +Le organizzazioni di maggiori dimensioni dispongono di propri repository di codice. Merita menzione in particolare il repository tedesco per le autorità opencode.de. footnote:[https://opencode.de/en/home] Rivestono qui particolare interesse i repository di altre amministrazioni pubbliche. + +== Modelli di supporto per l'utilizzo dell'OSS + +Il software open source già disponibile sul mercato può essere utilizzato fondamentalmente in tre modi: + +. Utilizzo senza supporto professionale +. Utilizzo con supporto interno +. Utilizzo con supporto di un fornitore esterno. + +Questi tre tipi di utilizzo e i relativi vantaggi e svantaggi sono illustrati brevemente qui di seguito. Quale di questi scenari sia il più opportuno in un caso concreto va deciso caso per caso. Il modello di supporto adeguato dipende dalla rilevanza strategica del software open source, dall'integrazione tecnica e dalle risorse di personale disponibili. + +Per il software critico il supporto deve in ogni caso essere fornito in modo professionale, internamente o esternamente. Anche il ciclo di vita previsto dovrebbe avere un ruolo nella pianificazione del supporto. Può anche darsi che il supporto sia ottenuto da più fornitori. + +=== Utilizzo senza supporto professionale + +Il software open source è disponibile su Internet per essere scaricato, installato e utilizzato gratuitamente. + +Vantaggi:: +* Costi contenuti +* Attuazione rapida + +Svantaggi:: +* Nessun supporto garantito +* Nessuna pretesa di responsabilità + +Rischio e copertura:: +Rischio elevato: non esistono contratti di supporto né garanzie e nell'organizzazione vi sono poche o nessuna competenza di sviluppo. + +Ambito d'applicazione tipico:: +Software open source standard che può essere aggiornato indipendentemente da altri sistemi. + +=== Utilizzo con supporto interno + +Un'impresa o un'organizzazione dell'ente pubblico sviluppa competenze e risorse su determinate soluzioni open source per un utilizzo a lungo termine. Questo approccio è particolarmente diffuso negli ambiti critici per l'attività. + +Vantaggi:: +* Elevata flessibilità grazie al know-how interno +* Nessun lock-in del fornitore + +Svantaggi:: +* Elevato investimento e tempo necessari per sviluppare le competenze +* Maggiori costi fissi interni per il personale + +Rischio e copertura:: +Rischio medio: il supporto dipende dal know-how e dalla disponibilità dell'informatica interna. + +Ambito d'applicazione tipico:: +Sviluppi propri, software open source impiegato strategicamente e per il quale è disponibile un know-how approfondito. + +=== Utilizzo con supporto di un fornitore esterno + +Viene coinvolto un fornitore open source esterno per accompagnare professionalmente l'introduzione e la manutenzione del software open source. Questo approccio è impiegato soprattutto negli ambiti critici per l'attività, in cui un know-how approfondito del software deve essere immediatamente disponibile. Ciò può comprendere anche parti della pubblicazione o l'intera pubblicazione. + +Vantaggi:: +* Accesso diretto al know-how degli sviluppatori open source +* Correzioni ed estensioni su base contrattuale +* Scelta tra diversi fornitori open source +* Vincolatività, copertura contro i rischi di conformità + +Svantaggi:: +* Costi esterni dovuti ai fornitori open source +* Dipendenza dal know-how del fornitore open source + +Rischio e copertura:: +Rischio ridotto: la garanzia è prestata secondo il capitolato d'oneri o il service level agreement + +Ambito d'applicazione tipico:: +Software open source critico per l'attività, per il quale sono disponibili poche o nessuna competenza interna di sviluppo + +== Punto di contatto + +Nell'Amministrazione federale non esiste un punto di contatto unico che funga da Open Source Programme Office. In linea di principio gli uffici federali sono responsabili essi stessi dell'attuazione. + +Le richieste generali relative agli strumenti OSS della serie di documenti Em002 possono essere rivolte al settore TDT della Cancelleria federale: opensource@bk.admin.ch. + +== Allegati + +=== Modifiche rispetto alla versione precedente + +* Capitolo 4.1: aggiunti i livelli di maturità +* Capitolo 6: acquisto di OSS completato e adeguato con i nuovi documenti dell'UFCL +* Capitolo 7.1: nuovo catalogo OSS della Confederazione (opensource.admin.ch) +* Ulteriori modifiche e miglioramenti redazionali minori + +=== Riferimenti + +I riferimenti alla serie di documenti Em002 figurano nelle link:em002.pdf[Em002 Linee guida strategiche]. + +=== Abbreviazioni + +Un elenco delle abbreviazioni figura nel documento principale Em002. +Un glossario figura nel documento «link:em002-6.pdf[Em002-6 Domande frequenti sulla pubblicazione di OSS (FAQ-OSS)]». + +=== Modelli di business con l'OSS + +Il software open source non è di per sé un modello di business perché, diversamente dal software proprietario, non è possibile vendere un software soggetto a licenza open source. Esistono nondimeno diverse possibilità per le imprese di gestire modelli di business fondati sul software open source. Se ad esempio occorre ottenere un supporto esterno professionale per una soluzione open source, è necessario acquistare le corrispondenti prestazioni commerciali. I quattro modelli di business più diffusi per il software open source sono illustrati qui di seguito. Ulteriori aspetti di questi e di altri modelli di business sono esposti nella guida BITKOM _[BITKOM2023]_. + +==== Servizi e prodotti basati sull'OSS + +Le imprese possono offrire servizi commerciali quali il web hosting o il cloud computing sulla base di software open source, che con software proprietario sarebbero molto più costosi. Per questo motivo la maggior parte delle start-up, dei portali online e dei fornitori di commercio elettronico costruisce oggi le proprie piattaforme su software open source. Altre imprese tecnologiche, come le imprese di telecomunicazione, i fornitori di streaming o persino i fabbricanti di software proprietario, integrano software open source nei loro prodotti software e hardware nonché nei servizi online. Ciò consente alle imprese di continuare a offrire soluzioni innovative, difficilmente realizzabili con software proprietario. + +==== Servizi per l'OSS + +I fornitori open source erogano prestazioni per software open source selezionati. Dispongono di sviluppatori open source esperti e possono quindi offrire supporto, manutenzione, esercizio, sviluppo, consulenza, formazione e altre prestazioni per il software open source. Esse possono essere ottenute dal fornitore open source su mandato o nel quadro di un contratto d'appalto. Tali prestazioni per software open source possono essere messe a concorso pubblicamente, poiché non sussiste alcun vendor lock-in. Ciò che conta in tali bandi è la considerazione di criteri adeguati, affinché siano selezionati fornitori di prestazioni effettivamente competenti (cfr. capitoli 0 e 8, _[BITKOM2023]_ capitolo 3.3 e _[Gu2024]_). + +==== Abbonamenti + +Quando le prestazioni per software open source sono fornite in forma standardizzata e ricorrente, alla stregua di un service level agreement (SLA), si parla di abbonamenti. Nel quadro di tali abbonamenti le imprese garantiscono per esempio aggiornamenti di sicurezza continui, supporto via e-mail o telefono, compatibilità con altri prodotti software e hardware mediante certificazioni, prestazioni di manutenzione a lungo termine e coperture contro pretese giuridiche (diritto d'autore, brevetti). In cambio i clienti pagano abbonamenti per postazione di lavoro o per CPU, analogamente alle tasse di licenza o d'uso del software proprietario. Diversamente dal software proprietario, gli abbonamenti per il software open source non costituiscono tuttavia un presupposto per l'utilizzo del software, bensì soltanto un modo di remunerare il valore aggiunto delle prestazioni fornite dal fornitore open source. + +==== Doppia licenza + +Se un'impresa detiene la proprietà intellettuale di una soluzione software e tutti i componenti open source integrati sono soggetti a una licenza permissiva, è possibile applicare una doppia o multipla licenza. Ciò consente all'impresa che sviluppa di pubblicare il software sotto una licenza open source copyleft e al contempo di venderlo sotto una licenza proprietaria. Questa versione commerciale è spesso chiamata versione Enterprise e comprende tipicamente determinate funzionalità supplementari, quali integrazioni di interfacce esclusive o l'autorizzazione per gli acquirenti a integrare il software nei propri prodotti proprietari. A seconda dell'entità delle restrizioni della versione open source, è consigliabile prudenza nell'impiego di software a doppia licenza, poiché l'acquisto della versione Enterprise può risultare inevitabile, con un vendor lock-in pari a quello del tipico software proprietario. +endif::[] + +ifeval::["{lang}" == "rm"] +NOTE: 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 {url-repo}/tree/main[README] principal. + +== 1. Utilisaziun da questa guida + +Tenor l'artitgel 9 da la lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG) è la Confederaziun obligada da publitgar il code da funtauna dal software ch'ella sviluppa u fa sviluppar per ademplir sias incumbensas. footnote:[CS 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/rm] Il sectur TDT da la Chanzlia federala ha deducì da quest'incumbensa legala finamiras surordinadas en las Directivas strategicas per software open source. + +Quest document serva sco guida pratica per las prescripziuns giuridicas e strategicas. El duai sustegnair las unitads administrativas da la Confederaziun en l'utilisaziun, l'acquist e la relaschada da software open source. El porscha a tut ils interessads ina survista cumplessiva dal tema e renviescha ad infurmaziuns supplementaras en ils auters meds. + +Tut tenor la savida preliminara ed il basegn pudais Vus dentant era leger las guidas selectivamain, avant che passar als auters meds. La survista suandanta As gida da chattar l'access adattà. Sche Vus n'essas betg segirs, è recumandabel da leger l'emprima giada la guida. + +=== Intenziun / gruppas d'interess + +Introducziun generala en il software open source + +* Chapitel Concepts +* Chapitel Potenzial e sfidas +* Chapitel Chattabladad da soluziuns OSS +* link:em002-5.pdf[Em002-5 Fegl d'infurmaziun Meds OSS] +* link:em002-3.pdf[Em002-3 Guida da licenzas OSS] +* link:em002-6.pdf[Em002-6 FAQ davart OSS] + +Introducziun generala en l'EMBAG per persunas che prendan decisiuns + +* link:em002-5.pdf[Em002-5 Fegl d'infurmaziun Meds OSS] +* link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] + +Mo acquist da software da utilisar + +* Chapitel Grads da madirezza per OSS en l'administraziun federala +* Chapitel Utilisaziun da software open source nunmidà +* link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist ed OSS] +* Fegl d'infurmaziun Acquist da software ed art. 9 EMBAG [KBB-MB] +* Directiva OSS en l'acquist [BBL-WL] + +Nov svilup d'informatica e relaschada + +* Chapitel Svilup cun cumponentas open source e relaschada dal code da funtauna +* Chapitel Collavuraziun en projects averts (contribution) +* link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Glista da controlla Evaluaziun preliminara OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla Analisa e preparaziun OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Glista da controlla Relaschada e publicaziun OSS] +* link:em002-4.pdf[Em002-4 Guida da communitads OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla Communitad OSS] + +Acquist da software da crear (prestaziun u ovra) + +* Chapitel Grads da madirezza per OSS en l'administraziun federala +* Chapitel Svilup cun cumponentas open source e relaschada dal code da funtauna +* Chapitel Collavuraziun en projects averts (contribution) +* link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist ed OSS] +* Chascha d'utensilis dal UFCL, inclusiv la directiva Open Source en l'acquist +* Plattafurma d'emprender e da models da l'administraziun publica dal CCA (www.perimap.admin.ch) inclusiv Acquist da software ed art. 9 EMBAG [KBB-MB] +* Directiva OSS en l'acquist [BBL-WL] +* link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Glista da controlla Evaluaziun preliminara OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla Analisa e preparaziun OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Glista da controlla Relaschada e publicaziun OSS] +* link:em002-4.pdf[Em002-4 Guida da communitads OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla Communitad OSS] + +Scleridas giuridicas per la relaschada + +* link:em002-6.pdf[Em002-6 Dumondas frequentas davart la publicaziun da l'OSS (OSS-FAQ)] +* link:em002-3.pdf[Em002-3 Guida da licenzas OSS] + +Princips da lavur per manadras e manaders da project + +* https://www.hermes.admin.ch/[Documents HERMES] +* link:em002-5.pdf[Em002-5 Fegl d'infurmaziun Meds OSS] + +Contribuziuns da software a terzas persunas e collavuraziuns + +* link:em002-4.pdf[Em002-4 Guida da communitads OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla Communitad OSS] +* link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist ed OSS] +* link:em002-3.pdf[Em002-3 Guida da licenzas OSS] + +La grafica suandanta dat ina survista dals documents relevants per l'OSS en l'administraziun federala. + +include::partials/document-map.rm.adoc[] + +Illustraziun 1: Survista dals meds OSS en connex cun l'art. 9 EMBAG + +== Concepts + +Software open source:: +In software vala sco software open source (OSS), sch'el vegn publitgà sut ina da las var 80 licenzas renconuschidas da l'Open Source Initiative OSI _[OSI2024]_. Concretamain fixescha la definiziun d'open source diesch criteris che tuttas licenzas open source ston ademplir _[Pe1999]_. Quels sa laschan resumar en il fund en quatter puncts: ++ +. Il software dastga vegnir utilisà per mintga intent. +. Il code da funtauna dal software è accessibel libramain. +. Il software dastga vegnir copià e derasà senza restricziuns. +. Il software dastga vegnir midà e derasà en furma midada sut tschertas cundiziuns. + +Software liber:: +Avant il term «open source» ha la Free Software Foundation (FSF) introducì en ils onns 1980 il concept dal «software liber». En il fund adempla il software liber las cundiziuns dal software open source, ma mira a quai che il software restia adina accessibel libramain e na vegnia, sche pussaivel, betg integrà en software proprietar. footnote:[https://de.wikipedia.org/wiki/Freie_Software[Freie Software -- Wikipedia]] + +Software proprietar:: +Tar il software proprietar sviluppa in purschider il software e venda a l'utilisader ina licenza d'utilisaziun. Per ordinari na conuscha l'utilisader betg il code dal software e na dastga ni il derasar vinavant ni il midar. El po utilisar il software mo tenor las cundiziuns da licenza (p.ex. End-User Licence Agreement, EULA) cunter pajament da taxas da licenza. Il software po per exempel esser permess mo per in tschert dumber d'utilisaders u per in tschert dumber da processurs. footnote:[https://de.wikipedia.org/wiki/Proprietäre_Software[Proprietäre Software -- Wikipedia]] En cuntrachamb per las taxas da mantenziun, per ordinari annualas, s'oblighescha il purschider da reparar sbagls entaifer in termin adequat e da sviluppar cuntinuadamain il software. + +Licenza:: +Ina licenza è in document che cuntegna prescripziuns liantas per l'utilisaziun e la derasaziun dal software. Tar l'open source vegnan per ordinari utilisadas licenzas che correspundan a l'OSI. footnote:[https://opensource.org/[Open Source Initiative]] + +Communitad:: +Ina communitad en il context dal software open source è definida amplamain. I po sa tractar d'in ecosistem liber u d'ina structura cun governanza che sviluppa il software. Il document link:em002-4.pdf[Em002-4 Guida da communitads OSS] tracta quest tema. Ils commembers da la communitad pon manar cuminaivlamain il product, il sviluppar, il testar, il translatar, dar resuns u simplamain utilisar il software. + +Dretgs da terzas persunas:: +Era tar software open source pon exister dretgs da protecziun (dretg d'autur, dretg da marcas, dretg da patents) che pon vegnir fatgs valair da terzas persunas, p.ex. tar l'utilisaziun da code da funtauna creà da terzas persunas. + +Excepziuns tenor l'EMBAG:: +Excepziuns tenor l'art. 9 al. 1 EMBAG èn dretgs da terzas persunas e motivs relevants per la segirezza. Omadus vegnan tractads en il chapitel 3 da link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source]. + +Code da funtauna:: +En l'informatica è il code da funtauna (u text da funtauna) il text ch'è legibel per umans d'in program da computer, scrit en ina lingua da programmaziun. footnote:[https://de.wikipedia.org/wiki/Quelltext[Quelltext -- Wikipedia]] + +Publicaziun:: +Publicaziun designescha en emprima lingia la relaschada dal code da funtauna sut ina licenza averta tenor l'OSI. Per motivs pratics appartegnan a quai per ordinari era la documentaziun ed instrucziuns automatisadas per crear l'applicaziun a partir dal code da funtauna. Tests automatisads e documents da test èn usitadamain era cuntegnids. Per che ina communitad possia sa sviluppar, vegn duvrada ina plattafurma che surpiglia lura pliras funcziuns d'ina plattafurma da svilup (build, test, support). + +Suveranitad digitala:: +Nus utilisain la definiziun dal rapport davart la suveranitad digitala dal DFAE [St2024]: «La suveranitad digitala d'in stadi u d'ina organisaziun cumpiglia obligatoriamain la controlla cumpletta davart datas memorisadas ed elavuradas sco er la decisiun autonoma davart tgi che dastga acceder a quellas. Ella cumpiglia vinavant la abilitad da sviluppar, midar, controllar e cumplettar autonomamain cumponentas e sistems tecnologics.» + +Repositori:: +In repositori è in lieu da memorisaziun ch'in utensil da gestiun da versiuns utilisescha per datotecas e metadatas davart la basa dal code. Repositoris permettan a plirs collavuraturs da lavurar a las medemas datotecas e da memorisar differentas versiuns. La gronda part permetta ultra da quai l'issue-tracking, il management da releases, builds automatisads e la documentaziun. + +Fork:: +In fork footnote:[https://de.wikipedia.org/wiki/Abspaltung_(Softwareentwicklung)[Abspaltung (Softwareentwicklung) -- Wikipedia]] d'in project open source è il process da construir in svilup independent dal project original. + +Contributor Licence Agreement (CLA):: +In Contributor Licence Agreement footnote:[https://en.wikipedia.org/wiki/Contributor_License_Agreement[Contributor License Agreement -- Wikipedia]] è in document che descriva las cundiziuns, sut las qualas proprietad intellectuala po vegnir contribuida ad in project u ad in'interpresa. + +Source Code Management (SCM):: +Il source code management footnote:[https://de.wikipedia.org/wiki/Versionsverwaltung[Versionsverwaltung -- Wikipedia]], numnà era gestiun da versiuns, è in utensil che administrescha effizientamain midadas e numers da versiun, en spezial en il svilup da software. S'ha imponì il software liber Git footnote:[https://de.wikipedia.org/wiki/Git[Git -- Wikipedia]] per administrar SCM distribuids. + +Open Source Software Development (OSSD):: +Tar il svilup da software open source (OSSD) footnote:[https://en.wikipedia.org/wiki/Open-source_software_development[Open-source software development -- Wikipedia]] vegn, supplementarmain a la publicaziun dal code da funtauna, l'entir process da svilup exequì publicamain. Tut, da las pretensiuns (issues) fin al code da funtauna, è transparent. L'OSSD vegn sustegnì tras utensilis da communicaziun publics (glistas da mail, forums etc.), in sistem da gestiun da versiuns (Git), glistas da sbagls e da funcziuns, ina roadmap ed utensilis per sviluppaders. + +Software Package Data Exchange (SPDX):: +Software Package Data Exchange (SPDX) footnote:[https://en.wikipedia.org/wiki/Software_Package_Data_Exchange[Software Package Data Exchange -- Wikipedia]] descriva in format standard per la Software Bill of Materials (SBOM) cun la finamira da facilitar il tractament correct da software liber u da software open source. + +Effect copyleft:: +Sch'in software stat sut ina licenza cun ina disposiziun copyleft, sto mintga midada u extensiun dal code da funtauna vegnir relaschada puspè sut la licenza dal software open source midà (vesair era link:em002-3.pdf[Em002-3 Guida da licenzas OSS]). + +== Potenzial e sfidas + +En il mund informatic dad oz exista in potenzial enorm per software open source. Al medem temp porta l'utilisaziun da soluziuns open source era sfidas. Questas duas varts vegnan explitgadas pli detagliadamain en la secziun suandanta. Las indicaziuns sa basan tranter auter sin ils resultats dal Studi Open Source Svizra 2018, 2021 e 2024 da l'Universitad da Berna, en il qual las persunas interrogadas han dà infurmaziuns davart ils avantatgs ed ils dischavantatgs renconuschids dal software open source. + +=== Potenzial dal software open source + +Ils puncts suandants descrivan il potenzial che sa lascha realisar tar l'utilisaziun e la relaschada da software open source. + +{empty}1. Suveranitad digitala:: +Qua sa tracti da la abilitad d'utilisar e da controllar servetschs digitals. La suveranitad digitala s'extenda sur l'entir ciclus da vita d'in sistem digital. Software open source promova la suveranitad digitala, perquai ch'el garantescha la substituibilitad, la libertad da configuraziun e l'influenza. footnote:[Nus utilisain la definiziun da _[St2024\]_: «La suveranitad digitala d'in stadi u d'ina organisaziun cumpiglia obligatoriamain la controlla cumpletta davart datas memorisadas ed elavuradas sco er la decisiun autonoma davart tgi che dastga acceder a quellas. Ella cumpiglia vinavant la abilitad da sviluppar, midar, controllar e cumplettar autonomamain cumponentas e sistems tecnologics.»] + +{empty}2. Naginas taxas da licenza:: +Per l'utilisaziun da software open source na resultan nagins custs da licenza. Tar l'obtegniment da pachets da software standard open source cumplexs po dentant esser raschunaivel da cumprar abunaments da support cun custs. + +{empty}3. Spargnas da custs tras la collavuraziun cun auters utilisaders:: +Perquai che software sut ina licenza open source dastga vegnir utilisà e sviluppà vinavant senza restricziuns, pon ils custs da svilups vinavant vegnir dividids u pon svilups supplementars existents d'autras unitads administrativas vegnir surpigliads tenor il princip «sviluppar ina giada – utilisar pliras giadas». Al medem temp exista la pussaivladad da profitar da las experientschas e dals svilups dad auters. + +{empty}4. Construcziun da communitads e barat da savida:: +Software open source facilitescha la construcziun da communitads ed il barat da savida, per exempel tranter ils differents nivels federals en Svizra. Software po vegnir sviluppà vinavant cuminaivlamain, sbagls pon vegnir reparads ed experientschas individualas vegnir cundivididas. Il barat augmentà da savida tranter differentas unitads administrativas maina ad ina meglra chapientscha da quai ch'ils auters fan, uschia ch'i vegn evità dubladuras e che las meglras soluziuns pon sa derasar. + +{empty}5. Pli pitschna dependenza dals fabricants:: +Il vendor lock-in (dependenza da furniturs da software) vala en l'informatica sco fitg aut. L'utilisaziun da software sut ina licenza open source reducescha il vendor lock-in, perquai che manaschi, mantenziun, support, svilup vinavant ed ulteriuras prestaziuns per software open source pon vegnir mess a concurs avertamain. Empè da acquistar da nov in entir sistem pervia d'in vendor lock-in, pon extensiuns u prestaziuns dal ciclus da vita per ina soluziun OSS era vegnir messas a concurs separadamain. Uschia sa laschan spargnar custs da migraziun considerabels. + +{empty}6. Standards averts ed interoperabilitad:: +Tar software open source è la cumpatibilitad cun autras soluziuns da software e sistems informatics (interoperabilitad) per ordinari pli auta che tar software proprietar. Soluziuns open source utiliseschan ultra da quai bunamain exclusivamain formats da datas averts, perquai sa laschan ellas barattar simplamain cun auters sistems. + +{empty}7. Transparenza davart la construcziun dal software:: +Perquai che il software è era avant maun en furma dal code da funtauna, po sia qualitad vegnir controllada, per exempel tras reviews externas. Ultra da quai sa lascha crear documentaziun sin la basa dal code da funtauna (p.ex. en vista a novs concurs per prestaziuns da svilup u a la remplazzada da software open source a la fin da sia durada d'utilisaziun). + +{empty}8. Segirezza e fidanza tras la transparenza:: +Pervia da l'avertadad dal code da funtauna po la segirezza dal software open source esser pli auta che quella dal software proprietar. Ultra da quai è quai bler pli difficil da construir portas davos e autras largias en software open source, quai che maina a dapli fidanza en il software. + +{empty}9. Pli auta qualitad e modularitad dal code:: +La qualitad dal software open source po esser pli auta che quella dal software proprietar, perquai che la motivaziun da scriver bun code è probablamain pli gronda, sche las sviluppadras ed ils sviluppaders san che lur code da funtauna vegn publitgà. Ultra da quai èn las soluziuns open source tendenzialmain fitg modularas, uschia che moduls singuls sa laschan remplazzar simplamain ed ils ulteriurs moduls pon vegnir utilisads vinavant. footnote:[In ulteriur aspect da segirezza è che las bibliotecas utilisadas (inclusiv las dependenzas) sa laschan documentar pli simplamain che tar software proprietar. Quai munta puspè che debilitads pon vegnir renconuschidas e reparadas svelt, sch'ellas cumparan (vesair era SBOM).] + +{empty}10. Adattaziun simpla:: +L'access al code da funtauna permetta als utilisaders da far svilups vinavant sezs u tras furniturs externs. Uschia po il software vegnir adattà svelt als agens basegns. + +{empty}11. Innovaziun ed integraziun spertas:: +Software open source vegn sviluppà vinavant svelt e cuntinuadamain da la communitad. Uschia vegnan novas tecnologias e novs standards da datas publitgads savens sco bibliotecas da programmaziun open source. Quai pussibilitescha la realisaziun sperta da soluziuns da software innovativas. + +{empty}12. Attractivitad dal patrun:: +L'utilisaziun da tecnologias open source modernas e la collavuraziun informala cun communitads internaziunalas promovan la motivaziun dals collaboraturs ed augmentan uschia l'attractivitad dal patrun, quai che facilitescha puspè la reclutaziun da giuvens professiunals qualifitgads. + +=== Sfidas en il tractament da l'OSS + +Sutvart vegnan descrittas las sfidas tipicas ch'i dat en la pratica cun software open source e vegnan schizzadas intginas pussaivladads da soluziun. Sfidas generalas che pertutgan tut il software n'anfain nus betg a quest lieu (p.ex. la necessitad da controllar la cybersegirezza e la necessitad da garantir in support adequat per software critic). + +{empty}1. Auts custs da midada pervia da dependenzas existentas:: +La remplazzada da software proprietar cun soluziuns open source po esser fitg custaivla, sche l'applicaziun è integrada stretgamain en il sistem informatic existent tras interfatschas u autras dependenzas. Quests custs da midada mainan a quai che l'introducziun da software open source paja savens pir a la fin dal ciclus da vita dal software proprietar. + +{empty}2. Funcziuns mancantas u nagina soluziun open source adattada:: +Tar l'acquist da software standard po capitar ch'i na dettia nagina alternativa open source a la soluziun proprietara (fin qua), u mo ina insuffizienta dal puntg da vista funcziunal. Sco pussaivladad da soluziun exista la pussaivladad da sviluppar las funcziuns mancantas ensemen cun auters utilisaders dal software open source e da las agiuntar al project open source. footnote:[Per talas novas funcziuns èn responsabels ils responsabels dal project u da l'applicaziun. Co quai capita exactamain, determinescha il project. Em002-2 ed Em002-4 gidan tar decisiuns detagliadas. Tut tenor l'extensiun da la funcziun po esser nunraschunaivel da percurrer cumplettamain las instrucziuns. Aspects dal dretg d'acquist per resursas ston vegnir resguardads.] + +{empty}3. Custs d'integraziun pli auts:: +Spargnas da custs a curt termin pervia da licenzas che croda davent tar l'utilisaziun da software open source vegnan savens cumpensadas tras custs d'integraziun pli auts. Perquai è impurtant da renconuscher che l'utilisaziun professiunala da software open source n'è betg «gratuita», mabain chaschuna effectivamain custs interns u externs. + +{empty}4. Responsabladads e support nunclers:: +Software open source vegn savens criticà per il manient da support e da mantenziun tras interpresas externas. I dat dentant ozendi ina multiplitad da purschiders che porschan prestaziuns commerzialas (long-term-support, mantenziun currenta, svilup vinavant, responsabladad e garanzia etc.) per soluziuns open source. Ils differents models da fatschenta cun software open source vegnan explitgads en l'agiunta D ed ils differents models da support en il chapitel 8. Ina survista actuala dals purschiders da prestaziuns open source e da lur prestaziuns sa chatta en l'Open Source Directory (https://www.ossdirectory.com) u en il Studi OSS 2024 footnote:[https://www.oss-studie.ch/[Studi OSS]] _[OSS2024]_. + +{empty}5. Pitschen martgà cun paucs purschiders:: +Perquai che tschertas applicaziuns open source, sco applicaziuns desktop, dovran per ordinari pauc u nagin support e nagina mantenziun, po il martgà per purschiders open source da support e mantenziun esser pitschen. En quest cas po in concurs per prestaziuns da software open source contribuir a crear in martgà ch'augmenta la concurrenza tranter ils purschiders. L'existenza d'ina vasta communitad da svilup per il software respectiv e la qualitad da la documentaziun da svilup èn d'impurtanza pratica tar il concurs da talas prestaziuns. + +{empty}6. Pitschna visibladad:: +Las communitads da projects open source sa concentreschan surtut sin il svilup dal product e mo darar sin il marketing. Fabricants da software proprietar investeschan percunter ferm en la commercialisaziun ed en la vendita da lur products. Questa publicitad mancanta per software open source dat savens la fallida impressiun ch'i na dettia nagina alternativa als products proprietars. I dat dentant plattafurmas sco alternativeTo footnote:[https://alternativeto.net/] che porschan ina survista da soluziuns per incumbensas specificas (dapli davart alternativas OSS en il chapitel «Chattabladad da soluziuns OSS»). + +{empty}7. Acceptanza mancanta tar ils utilisaders finals:: +Pervia da differentas interfatschas d'utilisader, funcziuns mancantas, ina pitschna facilitad d'utilisaziun e pauca publicitad per software open source manca tar tscherts products open source l'acceptanza dals utilisaders finals. Purschidas adequatas da communicaziun, documentaziun e scolaziun pon cuntrastar questa sfida. Era il fatg che software open source po vegnir sviluppà vinavant tenor ils basegns dals utilisaders po manar ad ina pli gronda acceptanza. + +{empty}8. Pauca u nagina cumpetenza interna:: +Soluziuns open source sa sviluppan svelt vinavant e pretendan al medem temp ina chapientscha tecnica profunda. Uschia po capitar che collaboraturs interns hajan pauca u nagina cumpetenza davart tscherts software open source. La savida interna davart l'OSS sa lascha construir tras la furmaziun supplementara e pussaivladads da studi autonom via funtaunas online sco er tras la construcziun da wikis interns etc. + +{empty}9. Evaluaziun difficila dal futur:: +Per persunas ordaifer ina communitad open source è savens difficil da renconuscher, co che il project sa sviluppa en il futur. Perquai è impurtant da pudair evaluar realisticamain il svilup futur d'ina soluziun open source. Il chapitel «Open Hub» preschenta a quest reguard la plattafurma Open Hub che permetta d'evaluar l'activitad e l'eterogeneitad da la communitad da sviluppaders. Uschia sa lascha giuditgar meglier il svilup futur d'in project open source. + +{empty}10. Inscuritads giuridicas:: +La multiplitad da differentas licenzas open source ed il dumber fin ussa pitschen da sentenzias giudizialas davart dumondas d'interpretaziun pon manar a temps ad inscuritads giuridicas tar software open source. Questa guida pratica duai dar ina survista da las licenzas open source las pli impurtantas sco er da lur caracteristicas e cumpatibilitads. Funtaunas per respostas profundas a dumondas giuridicas sa chattan en ils documents link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed link:em002-6.pdf[Em002-6 FAQ davart OSS e l'art. 9 EMBAG]. + +{empty}11. Purschida memia vasta da software open source:: +Il dumber dals products da software open source è creschì ferm en ils ultims onns. Utilisaders potenzials da software open source sa lamentan perquai davart la multiplitad da soluziuns open source existentas sin il martgà. Perquai preschenta il chapitel «Chattabladad da …» duas plattafurmas, alternativeTo ed Open Hub, che pussibiliteschan ina cumparegliaziun da soluziuns open source. + +{empty}12. Lavur da coordinaziun tar il svilup cuminaivel:: +Sche l'administraziun federala sa participescha a projects cuminaivels e contribuescha ad els, resulta entaifer questas collavuraziuns ina lavur da coordinaziun, ma era, sch'ina communitad sto vegnir integrada. Idealmain paja questa lavur supplementara tuttina grazia ad ina soluziun meglierada, ina pli gronda acceptanza u ina participaziun augmentada da terzas persunas. + +== Constellaziuns per l'utilisaziun da e la lavur cun l'OSS + +=== Grads da madirezza per OSS en l'administraziun federala + +Tar l'utilisaziun ed il svilup da l'OSS en l'administraziun federala existan differentas constellaziuns areguard las obligaziuns en connex cun licenzas open source. In model da madirezza tipic footnote:[Model da madirezza en adherenza a https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#maturity-levels] per l'introducziun da l'open source en organisaziuns po vesair or uschia: + +. Denial -- nagina u inconscienta utilisaziun da software open source +. Consumption -- utilisaziun passiva da software open source +. Participation -- engaschament en communitads open source +. Contribution -- contribuziuns pragmaticas a projects open source +. Leadership -- engaschament strategic cun l'open source per augmentar il valur da fatschenta footnote:[Creation na vegn betg menziunà, perquai che l'art. 9 EMBAG pretenda quai directamain.] + +[options="header",cols="1,2a"] +|=== +|Constellaziun |Consequenza + +|La pura *utilisaziun* da software open source existent (senza midar il code). +|I n'exista *nagina obligaziun* da cundivider il code da funtauna. + +|Il *svilup cumplettamain nov* da software che duai vegnir publitgà sut ina licenza open source. +|*En quest cas exista ina libertad cumpletta areguard la licenza, sut la quala il software vegn publitgà.* Per la Confederaziun sto vegnir consultà il document link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston vegnir resguardads. + +|*Svilup vinavant* (intern u extern) cun cumponentas open source existentas (cun u senza effect copyleft footnote:[Explicaziun dal term «copyleft» en link:em002-3.pdf[Em002-3 Guida da licenzas OSS]]), uschè ditg che il software vegn utilisà *exclusivamain entaifer la medema organisaziun* e betg derasà vinavant. +|Las cumponentas OSS pon vegnir cumbinadas a giavisch cun cumponentas da terzas persunas. Da la licenza na resulta fundamentalmain nagina obligaziun da publicaziun, uschè ditg che il software vegn utilisà exclusivamain entaifer la medema organisaziun e betg derasà (excepziun: AGPL). Perquai ch'i n'è betg scleri definitivamain dal puntg da vista giuridic, quant lunsch ch'il concept da la «derasaziun entaifer la medema organisaziun» va, vala quest scenari per cumponentas OSS cun effect copyleft mo en cas excepziunals. Consultai en quests cas il servetsch giuridic da Vossa organisaziun. Vesair link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed link:em002-6.pdf[Em002-6 FAQ davart OSS e l'art. 9 EMBAG]. Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston vegnir resguardads. *Perquai ch'i exista tenor l'art. 9 EMBAG in'obligaziun da publicaziun, ston las midadas vegnir relaschadas danovamain. Il pli simpel è quai sco midadas al project open source existent.* + +|*Svilup vinavant* (intern u extern) *exclusivamain cun* cumponentas open source existentas *senza effect copyleft*, sche il software duai vegnir derasà externamain (p.ex. als chantuns). +|Las cumponentas OSS pon vegnir cumbinadas a giavisch cun cumponentas da terzas persunas, e da las licenzas na resulta nagina obligaziun da publicaziun (vesair era link:em002-3.pdf[Em002-3 Guida da licenzas OSS]). *En il rom da l'art. 9 EMBAG è la relaschada dentant obligatorica. Idealmain ha la relaschada lieu via il project existent (nagin fork).* Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston vegnir resguardads. + +|*Svilup vinavant* (intern u extern) cun cumponentas open source existentas *cun effect copyleft*, sche il software duai vegnir derasà externamain (p.ex. als chantuns). +|*Pervia da la licenza copyleft exista in'obligaziun da publicaziun* (vesair era link:em002-3.pdf[Em002-3 Guida da licenzas OSS] concernent l'effect copyleft). Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston vegnir resguardads. + +|*Contribuziun* ad in project open source existent. +|*Tenor l'EMBAG exista fundamentalmain in'obligaziun da publicaziun. I valan la governanza e la licenza dal project.* Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston vegnir resguardads. + +|*Svilup cuminaivel* d'in project nov u existent cun ina communitad e partiziun dals custs. +|*Tenor l'EMBAG exista fundamentalmain in'obligaziun da publicaziun.* Ils documents link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS], link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] servan *a la construcziun dal project e da sia governanza.* + +|*Tuttas variantas dal svilup u dal svilup vinavant* han lieu *via in furnitur u terzas persunas incumbensadas.* +|*Tenor l'EMBAG exista fundamentalmain in'obligaziun da publicaziun.* Sin la basa da link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS], link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS]. Sche pussaivel duessan las premissas per la publicaziun vegnir creadas gia en il process d'acquist e duessan las pretensiuns per la relaschada dal software vegnir communitgadas sche necessari al furnitur resp. a las terzas persunas. +|=== + +=== Utilisaziun da software open source nunmidà + +Tar l'utilisaziun da software open source n'è fundamentalmain betg relevant, sut tge licenza open source ch'el vegn publitgà, perquai che tuttas licenzas open source (vesair chapitel 2 «Concepts») permettan l'utilisaziun illimitada da software open source, independentamain da quants plazzas da lavur, quants utilisaders annunziads a medem temp, quants servers e processurs etc. che il software vegn duvrà. + +Tar l'utilisaziun da software open source nunmidà na resultan *naginas obligaziuns da publicaziun*, era betg tar programs che stattan sut ina licenza cun in effect copyleft strict (excepziun: licenza AGPL, Affero General Public Licence). + +Uschè ditg che software open source vegn introducì e manà tras purschiders da prestaziuns interns da la Confederaziun, po quai capitar *senza in process d'acquist public*, perquai che «la licenza OSS sula na custa per ordinari nagut al post d'acquist e n'è perquai per sasezza betg relevanta per l'acquist». + +Sch'in purschider da prestaziuns extern vegn incumbensà cun la mantenziun, il support ed ulteriuras prestaziuns per il software open source, ston vegnir resguardadas las prescripziuns dal dretg d'acquist public. Differentas variantas da support vegnan descrittas en il chapitel 9. Impurtant è ultra da quai da duvrar criteris d'aptitude e d'attribuziun adattads tar l'acquist da software open source. Las basas per quai vegnan explitgadas en il chapitel 8. + +=== Svilup cun cumponentas open source e relaschada dal code da funtauna + +Cun l'obligaziun da publicaziun tenor l'art. 9 EMBAG sto vegnir suandà qua il proceder descrit en link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS]. +Ils documents link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed link:em002-4.pdf[Em002-4 Guida da communitads OSS] ston sche necessari era vegnir consultads. La finamira è da relaschar il project en moda controllada cun agid da las trais glistas da controlla _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]_. + +=== Collavuraziun en projects averts (contribution) + +Reflexiuns pussaivlas davart la contribuziun da l'administraziun federala a projects averts gia existents èn inditgadas en la guida BITKOM _[BITKOM2024]_ chapitel 4.2. footnote:[Vesair https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html, chapitel 4.2.] Tut tenor l'impurtanza dal project per l'administraziun federala sto vegnir examinà, quanta responsabladad che l'uffizi respectiv vul e po surpigliar. + +La collavuraziun en projects averts ed il svilup direct en projects averts pon era avair lieu cun agid dals documents per la relaschada. En il center stattan link:em002-4.pdf[Em002-4 Guida da communitads OSS] e la glista da controlla appartegnenta _link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]_. + +== Caracteristicas e tscherna da licenzas open source + +Las caracteristicas e la tscherna da licenzas open source vegnan descrittas en il document link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. + +== Acquist da l'OSS + +Dumondas strategicas davart l'acquist e l'OSS vegnan tractadas en link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source]. + +Il Center da cumpetenza per l'acquist public da la Confederaziun (CCA) ha publitgà in nov fegl d'infurmaziun cun il titel _Acquist da software ed art. 9 EMBAG https://perimap.admin.ch/goto_perimap_file_46835_download.html[[KBB-MB]]_ sco er dus documents «Criteris models – acquist EMBAG ed open source» e «Texts da contract models – svilup da software». + +Ulteriur sustegn stat a disposiziun sin l'https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[intranet da l'UFCL] (accessibel mo en la rait da la Confederaziun) cun la 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[_directiva Open Source en l'acquist_] _[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]]_ e la 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[_glista da controlla excepziun integrala art. 9 EMBAG_] _[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]]_. + +L'aptitude da l'open source per l'utilisaziun en interpresas sa chatta en il document _Selection Criteria for Enterprise-Ready Open Source Software [Gu2024]_ footnote:[Vesair _[Gu2024\]_] u en la guida Bitkom. footnote:[Vesair https://www.bitkom.org/Bitkom/Publikationen/Praxisempfehlungen-fuer-Open-Source-Software[Recumandaziuns praticas per software open source | Guida 2025 | Bitkom e. V.], chapitel 3.3] + +== Chattabladad da soluziuns OSS + +Differentas plattafurmas permettan ad organisaziuns interessadas da chattar e d'analisar software open source avant l'utilisaziun u l'acquist. Las datas uschia obtegnidas furman ina basa per la decisiun davart l'utilisaziun u l'acquist da software open source. + +Ina cumpilaziun da pretensiuns minimalas ed eventualmain in'analisa dal martgà duessan en mintga cas servir. + +=== Catalog OSS + +Las autoritads federalas èn obligadas da publitgar il code da funtauna dal software ch'ellas sviluppan u fan sviluppar per ademplir lur incumbensas. Il catalog OSS footnote:[https://www.opensource.admin.ch/] renumbra tut il software sviluppà da las autoritads federalas dapi il 1. da schaner 2024 e relaschà sco open source. El porscha ina survista dal software disponibel e facilitescha il chattar ed il reutilisar da soluziuns open source. + +Sch'in nov repositori u ina nova organisaziun vegn creà, sto quai vegnir annunzià per l'admissiun en il catalog OSS per e-mail a opensource@bk.admin.ch. + +Catalog OSS: https://www.opensource.admin.ch + +=== OSS Directory + +L'OSS Directory manà da CH Open footnote:[https://www.ossdirectory.com/de/home] facilitescha il chattar da purschiders qualifitgads che porschan in support professiunal per software open source. + +Purschiders open source mussan cun agid da istorgias da success, a tge utilisaders (clients) ch'els han gidà tar l'introducziun da tscherts products open source. +Il Directory porscha ultra da quai novitads open source actualas da plattafurmas existentas, top-novitads tschernidas, occurrenzas, communitads, offertas da lavur ed artitgels per il barat da savida. L'OSS Directory è disponibel per tudestg, englais, franzos e talian. Tuttas endataziuns pon vegnir agiuntadas ed actualisadas directamain dals utilisaders registrads. + +OSS Directory: https://www.ossdirectory.com + +=== alternativeTo + +In utensil pratic per chattar alternativas a software è «alternativeTo - Crowdsourced software recommendations». footnote:[https://alternativeto.net/] Sco che il num inditgescha, èn las alternativas e lur valitaziuns naschidas tras crowdsourcing, pia tras las endataziuns da blers utilisaders singuls. alternativeTo distingua quatter geners da soluziuns da software, dals quals mo il emprim vala sco software open source en il senn da l'art. 9 EMBAG: + +Free open source:: +Software che vegn publitgà sut ina licenza open source. + +Free:: +Software gratuit (freeware), dal qual il code da funtauna n'è dentant betg disponibel libramain e na dastga betg vegnir midà. + +Freemium:: +Tal software porscha ina versiun gratuita ed ina versiun premium, per che tuttas funcziuns impurtantas èn gia disponiblas en la versiun gratuita. Betg en questa categoria appartegna software che po vegnir testà gratuitamain durant in tschert temp (p.ex. ina versiun da test da 30 dis); quel croda en la categoria «Commercial». + +Commercial:: +Qua sa tracti da software proprietar, per il qual vegnan incassadas taxas da licenza tar l'utilisaziun. + +=== Repositoris open source + +La plattafurma da svilup open source actualmain la pli populara dal mund cun passa 30 milliuns d'utilisaders e passa 100 milliuns da repositoris da code da funtauna è GitHub. footnote:[https://octoverse.github.com] Oz han bunamain tuttas interpresas informaticas, en spezial fabricants da software proprietar, sco er bleras autras sorts d'interpresas ed organisaziuns ina preschientscha sin GitHub. Adina dapli autoritads publicas – var ina dutscheina da la Svizra footnote:[https://government.github.com/community/#switzerland] – publitgeschan ultra da quai lur agen software open source sin «GitHub and Government» sut https://government.github.com. Quest process sa lascha era exequir cun auters repositoris. + +Exempels dad auters repositoris èn: + +* GitLab +* Bitbucket +* SourceForge +* LaunchPad + +Sin GitHub Insights sa laschan leger numerusas statisticas relevantas d'in project open source sin GitHub: + +Pulse:: +Survista da las activitads las pli novas d'in project open source sin GitHub: resumaziun da las infurmaziuns las pli impurtantas davart l'intensitad da svilup, l'eterogeneitad da la communitad, annunzias avertas, meglieraziuns (pull requests) etc. + +Contributors:: +Preschentaziun da las sviluppadras e dals sviluppaders ch'èn stads activs e cura. Quai è in indizi impurtant, sche tut dependa d'ina persuna u sch'i stat ina pli gronda communitad davos. + +Commits:: +Preschentaziun da las contribuziuns ch'èn vegnidas fatgas a quest project open source ed en tge perioda. + +Code frequency:: +Visualisaziun da quant code da funtauna ch'è vegnì agiuntà u allontanà e cura. + +Dependency graph:: +Dependenzas dal project open source dad auter software open source (p.ex. relevant per renconuscher largias da segirezza ed actualisaziuns). + +Network:: +Preschentaziun da cura che tge sviluppadra u sviluppader ha contribuì a tge branca da svilup. + +Forks:: +Glista da tuttas copias dal project open source sin GitHub. Indicatur per la popularitad e la derasaziun dal software open source. + +=== Open Hub + +Sch'i duain vegnir rimnadas infurmaziuns davart ina soluziun open source che na vegn betg necessariamain sviluppada sin GitHub, s'offra Open Hub da Black Duck. footnote:[https://www.openhub.net/] Per var mez milliun projects open source vegnan resumadas cleramain numerusas infurmaziuns impurtantas: + +Project Summary:: +Ina curta descripziun dal project open source. + +In a Nutshell:: +Ils fatgs ils pli impurtants davart in project open source, sco il dumber dals commits, dals collavuraturs e da las lingias da code sco er la lingua da programmaziun la pli duvrada, il mument dal emprim commit e da l'ultima midada. Ultra da quai vegn inditgada ina valitaziun da la basa dal code e da la grondezza dal team da svilup (p.ex. «Mozilla Firefox has a well-established, mature codebase maintained by a very large development team with stable Y-O-Y commits»). + +Quick Reference:: +Cuntegna infurmaziuns davart l'organisaziun, links al project ed al code sco er indicaziuns davart projects sumegliants. + +Licences:: +Inditgescha, sut tge licenza u licenzas che il project open source è licenzià e tge consequenzas ch'èn colliadas cun quai. + +Project Security:: +Furnescha indicaziuns davart la segirezza e las debilitads dal project open source. + +Code:: +Ina grafica che mussa il dumber da las lingias da code en il decurs dal temp, repartì tenor lingua da programmaziun. + +Activity:: +Ina grafica che mussa il dumber dals commits per mais. Supplementarmain vegn messa a disposiziun ina resumaziun dals ultims 30 dis e 12 mais. + +Community:: +Ina grafica che mussa il dumber dals collavuraturs activs per mais. Ultra da quai vegn mussada ina valitaziun dal project sin ina scala da tschintg stailas. + +Open Hub permetta era da cumparegliar differents projects open source. footnote:[https://www.openhub.net/p/_compare] Quai dat svelt ina survista, tge project ch'ha la communitad la pli activa, il temp da svilup il pli lung u la licenza la pli adattada. + +=== Repositoris da code particulars + +Organisaziuns pli grondas disponan d'agens repositoris da code. Spezialmain da menziunar è per exempel il repositori tudestg per autoritads opencode.de. footnote:[https://opencode.de/en/home] Da spezial interess èn qua repositoris d'autras administraziuns publicas. + +== Models da support per l'utilisaziun da l'OSS + +Software open source gia disponibel sin il martgà po vegnir utilisà fundamentalmain en trais moda: + +. Utilisaziun senza support professiunal +. Utilisaziun cun support intern +. Utilisaziun cun support d'in furnitur extern. + +Quests trais geners d'utilisaziun e lur avantatgs e dischavantatgs vegnan explitgads curtamain sutvart. Tge da quests scenaris ch'è il pli raschunaivel en il cas concret, sto vegnir decidì da cas a cas. Tge model da support ch'è adattà, dependa da la relevanza strategica dal software open source, da l'integraziun tecnica e da las resursas da persunal disponiblas. + +Tar software critic sto il support vegnir furnì en mintga cas professiunalmain, saja quai internamain u externamain. Era il ciclus da vita planisà duess giugar in rol en la planisaziun dal support. I po era esser che il support vegnia obtegnì da plirs purschiders. + +=== Utilisaziun senza support professiunal + +Software open source stat a disposiziun en l'internet per telechargiar, installar ed utilisar gratuitamain. + +Avantatgs:: +* Custs bass +* Realisaziun sperta + +Dischavantatgs:: +* Nagin support garantì +* Naginas pretensiuns da responsabladad + +Ristg ed assicuranza:: +Aut ristg: I n'existan nagins contracts da support u garanzias ed en l'organisaziun è pauca u nagina savida da sviluppaders avant maun. + +Sectur d'applicaziun tipic:: +Software standard open source che po vegnir actualisà independentamain dad auters sistems. + +=== Utilisaziun cun support intern + +In'interpresa u in'organisaziun dal maun public construescha per l'utilisaziun a lunga vista savida e resursas davart tschertas soluziuns open source. Quest access è derasà en spezial en secturs critics per la fatschenta. + +Avantatgs:: +* Auta flexibilitad grazia a la savida interna +* Nagin lock-in dal furnitur + +Dischavantatgs:: +* Auta investiziun e grond temp per construir la savida +* Custs fixs interns pli auts per il persunal + +Ristg ed assicuranza:: +Ristg mesaun: Il support dependa da la savida e da la disponibladad da l'informatica interna. + +Sectur d'applicaziun tipic:: +Svilups agens, software open source duvrà strategicamain, per il qual è avant maun ina savida profunda. + +=== Utilisaziun cun support d'in furnitur extern + +In purschider open source extern vegn integrà per accumpagnar professiunalmain l'introducziun e la mantenziun dal software open source. Quest access vegn duvrà surtut en secturs critics per la fatschenta, nua ch'ina savida profunda dal software sto esser disponibla immediatamain. Quai po era cumpigliar parts da la relaschada u l'entira relaschada. + +Avantatgs:: +* Access direct a la savida da las sviluppadras e dals sviluppaders open source +* Reparaziuns ed extensiuns sin basa contractuala +* Tscherna tranter differents furniturs open source +* Obligatoriadad, assicuranza cunter ristgs da conformitad + +Dischavantatgs:: +* Custs externs tras furniturs open source +* Dependenza da savida dal furnitur open source + +Ristg ed assicuranza:: +Pitschen ristg: La garanzia vegn furnida tenor il pflichtenheft u il service level agreement + +Sectur d'applicaziun tipic:: +Software open source critic per la fatschenta, per il qual è avant maun pauca u nagina savida interna da svilup + +== Post da contact + +En l'administraziun federala n'exista nagin post da contact central che funcziunass sco Open Source Programme Office. Fundamentalmain èn ils uffizis federals sezs responsabels per la realisaziun. + +Dumondas generalas davart ils meds OSS da la seria da documents Em002 pon vegnir drizzadas al sectur TDT da la Chanzlia federala: opensource@bk.admin.ch. + +== Agiuntas + +=== Midadas envers la versiun precedenta + +* Chapitel 4.1: Grads da madirezza agiuntads +* Chapitel 6: Acquist da l'OSS cumplettà ed adattà cun ils novs documents da l'UFCL +* Chapitel 7.1: Nov catalog OSS da la Confederaziun (opensource.admin.ch) +* Ulteriuras midadas e meglieraziuns redacziunalas pitschnas + +=== Referenzas + +Las referenzas a la seria da documents Em002 sa chattan en las link:em002.pdf[Em002 Directivas strategicas]. + +=== Abreviaziuns + +Ina glista d'abreviaziuns sa chatta en il document principal Em002. +In glossari sa chatta en il document «link:em002-6.pdf[Em002-6 Dumondas frequentas davart la publicaziun da l'OSS (FAQ-OSS)]». + +=== Models da fatschenta cun l'OSS + +Software open source n'è per sasez nagin model da fatschenta, perquai ch'igl è – cuntrari al software proprietar – betg pussaivel da vender software sut ina licenza open source. Tuttina existan per interpresas differentas pussaivladads da manar models da fatschenta sin la basa da software open source. Sch'i duai per exempel vegnir obtegnì in support extern professiunal per ina soluziun open source, è l'acquist da las prestaziuns commerzialas correspundentas necessari. Ils quatter models da fatschenta ils pli frequents per software open source vegnan explitgads sutvart. Ulteriurs aspects da quests e dad auters models da fatschenta vegnan explitgads en la guida BITKOM _[BITKOM2023]_. + +==== Prestaziuns e products sin la basa da l'OSS + +Interpresas pon purscher prestaziuns commerzialas sco webhosting u cloud computing sin la basa da software open source, che fissan bler pli custaivlas cun software proprietar. Perquai construeschan la gronda part da las start-ups, dals portals online e dals purschiders d'e-commerce oz lur plattafurmas sin software open source. Autras interpresas da tecnologia sco interpresas da telecommunicaziun, purschiders da streaming u schizunt fabricants da software proprietar integreschan software open source en lur products da software e da hardware sco er en servetschs online. Quai permetta a las interpresas da purscher vinavant soluziuns innovativas che fissan grev da realisar cun software proprietar. + +==== Prestaziuns per l'OSS + +Purschiders open source furneschan prestaziuns per software open source tschernì. Els disponan da sviluppadras e sviluppaders open source experimentads e pon perquai purscher support, mantenziun, manaschi, svilup, cussegliaziun, scolaziun ed ulteriuras prestaziuns per software open source. Quellas pon vegnir obtegnidas tar il furnitur open source en incumbensa u en il rom d'in contract d'ovra. Talas prestaziuns per software open source pon vegnir messas a concurs publicamain, perquai ch'i n'exista nagin vendor lock-in. Impurtant tar tals concurs è il resguard da criteris adattads, per che vegnian tschernids purschiders da prestaziuns effectivamain cumpetents (vesair chapitels 0 ed 8, _[BITKOM2023]_ chapitel 3.3 e _[Gu2024]_). + +==== Abunaments + +Sche prestaziuns per software open source vegnan furnidas en furma standardisada e repetitiva sco ina sort service level agreement (SLA), discurra ins dad abunaments. En il rom da tals abunaments garanteschan las interpresas per exempel actualisaziuns da segirezza currentas, support per e-mail u telefon, cumpatibilitad cun auters products da software e hardware tras certificaziuns, prestaziuns da mantenziun a lunga vista ed assicuranzas cunter pretensiuns giuridicas (dretg d'autur, patents). En cuntrachamb pajan las clientas ed ils clients abunaments per plazza da lavur u per CPU, sumegliant sco taxas da licenza u d'utilisaziun per software proprietar. Cuntrari al software proprietar n'èn abunaments per software open source dentant nagina premissa per l'utilisaziun dal software, mabain mo ina pussaivladad da recumpensar il plivalur da las prestaziuns furnidas dal furnitur open source. + +==== Licenziaziun duala + +Sch'ina interpresa posseda la proprietad intellectuala d'ina soluziun da software e sche tuttas cumponentas open source integradas stattan sut ina licenza permissiva, po vegnir applitgada ina licenziaziun duala u multipla. Quai permetta a l'interpresa che sviluppa da publitgar il software sut ina licenza open source copyleft e da la vender al medem temp sut ina licenza proprietara. Questa versiun commerziala vegn savens numnada versiun Enterprise e cuntegna tipicamain tschertas funcziuns supplementaras, sco integraziuns d'interfatschas exclusivas u il permiss per las cumpraduras ed ils cumpraders d'integrar il software en lur agens products proprietars. Tut tenor l'extensiun da las restricziuns da la versiun open source è precauziun da recumandar tar l'utilisaziun da software cun licenza duala, perquai che l'obtegniment da la versiun Enterprise po esser inevitabel, cun quai che il vendor lock-in è uschè aut sco tar in software proprietar tipic. +endif::[] diff --git a/docs/em002-2-1-checklist-oss-preliminary-assessment.adoc b/docs/em002-2-1-checklist-oss-preliminary-assessment.adoc new file mode 100644 index 0000000..0465b29 --- /dev/null +++ b/docs/em002-2-1-checklist-oss-preliminary-assessment.adoc @@ -0,0 +1,751 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-2.1 OSS Preliminary Assessment Checklist +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-2.1 Checkliste OSS-Vorabklärung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-2.1 Liste de contrôle Évaluation préalable OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-2.1 Lista di controllo Valutazione preliminare OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-2.1 Glista da controlla Evaluaziun preliminara OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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. + +field::[rows=1] + +Describe the goal and purpose of the software as well as the scope. + +If a URL link exists, please also provide this. + +field::[rows=4] + +=== 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. + +field::[rows=3] + +== Checklist + +*New software or legacy* + +Is this new software or an existing project (see [Em002-2] Section 3.1). + +[%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_) + +field::[rows=1] + +*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'.] + +[%interactive] +* [ ] Planned +* [ ] In development +* [ ] In operation +* [ ] End of life +* [ ] Archive + +field::[rows=1] + +*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. + +[%interactive] +* [ ] None conceivable +* [ ] Potential users +* [ ] Known users + +field::[rows=2] + +*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). + +[%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) + +field::[rows=2] + +*Who is publishing the software?* + +[%interactive] +* [ ] Federal authority +* [ ] Service provider +* [ ] Supplier +* [ ] Third party + +field::[rows=1] + +*Depth of release* + +Outcome from _Em002-4.1 OSS Community Checklist_. + +[%interactive] +* [ ] Minimal publication: Publication of the source code and other artefacts +* [ ] Issue tracking: Errors can be reported and will be handled. +* [ ] Community + +field::[rows=1] + +[%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. + +field::[rows=4] + +[%interactive] +* [ ] There are no security-relevant reasons preventing publication. + +Reviews according to [Em002-2] Section 3.3 have been carried out. + +field::[rows=2] + +[%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. + +field::[rows=1] + +== 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). + +field::[rows=4] + +*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. +endif::[] + +ifeval::["{lang}" == "de"] +Diese Checkliste ist Teil des Dokuments _Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software_. Sie ist zu Beginn eines Projekts auszufüllen oder bei der Abklärung, ob Software nicht veröffentlicht werden muss. + +Die Beschreibung der Checkliste findet sich in _[Em002-2]_, Kapitel 3. + +Mit dieser Checkliste kann auch festgelegt werden, ob die Entwicklung als Open Development direkt auf einem öffentlichen Repository erfolgt. + +Für Legacy-Code (entwickelt vor dem Inkrafttreten des EMBAG am 1.1.2024) stehen zusätzliche Fragen zur Verfügung. + +Wichtig: Soll Software nicht als OSS freigegeben werden, dient diese Checkliste auch als Begründung für einen solchen Entscheid. + +== Gegenstand + +=== Name und Kurzbeschreibung der Software + +Tragen Sie den Namen der Software ein. + +Dieser Name sollte in allen nachfolgenden OSS-Checklisten identisch sein, damit die Zuordnung stimmt. + +field::[rows=1] + +Beschreiben Sie Ziel und Zweck der Software sowie den Umfang. + +Falls ein URL-Link besteht, geben Sie diesen bitte ebenfalls an. + +field::[rows=4] + +=== Ansprechperson und Prüfung + +Nennen Sie die Bundesbehörde (Organisationseinheit), die Ansprechperson sowie die für die rechtliche Prüfung verantwortlichen Personen (z. B. ISBO/DSBO), welche die Einhaltung der Veröffentlichungsvorgaben geprüft haben. + +field::[rows=3] + +== Checkliste + +*Neue Software oder Legacy* + +Handelt es sich um neue Software oder um ein bestehendes Projekt (siehe [Em002-2] Kapitel 3.1). + +[%interactive] +* [ ] Legacy (Weiterentwicklung) +* [ ] Neue Software +* [ ] Legacyfootnote:[Vom EMBAG nicht gefordert, es ist aber auch möglich, bestehende Software freizugeben.] oder Weiterentwicklung von Legacy-Software +* [ ] Bestehendes Drittprojekt (_Em002-4.1 Checkliste OSS-Community_ ausfüllen) + +field::[rows=1] + +*Lebenszyklus* + +In welcher Phase des Lebenszyklus befindet sich die Software aktuell (siehe [Em002-2] Kapitel 3.1).footnote:[Die Ablösung bestehender Software sollte hier als «geplant» vermerkt werden.] + +[%interactive] +* [ ] Geplant +* [ ] In Entwicklung +* [ ] Im Betrieb +* [ ] End of Life +* [ ] Archiv + +field::[rows=1] + +*Nutzende* + +Gibt es potenzielle oder bekannte Personen oder Organisationen, welche die Software nutzen? Gibt es potenzielle Abnehmer für die Software? Mögliche und bekannte Nutzende können im Textfeld genannt werden. + +[%interactive] +* [ ] Keine denkbar +* [ ] Potenzielle Nutzende +* [ ] Bekannte Nutzende + +field::[rows=2] + +*Eigenentwicklung, gemeinsame Entwicklung oder Drittprojekt* + +Wie sieht die Grundstruktur aus? Handelt es sich um eine Eigenentwicklung des Bundes, um eine Zusammenarbeit, oder baut sie auf einem Drittprojekt auf? + +Die Struktur von Co-Entwicklung und Drittprojekt kann im Textfeld aufgeführt werden + +(siehe [Em002-2] Kapitel 3.1). + +[%interactive] +* [ ] Eigenentwicklung +* [ ] Gemeinsame Entwicklung (_Em002-4.1 Checkliste OSS-Community_ auszufüllen) +* [ ] Drittprojekt (_Em002-4.1 Checkliste OSS-Community_ auszufüllen) + +field::[rows=2] + +*Wer veröffentlicht die Software?* + +[%interactive] +* [ ] Bundesbehörde +* [ ] Leistungserbringer +* [ ] Lieferant +* [ ] Dritte + +field::[rows=1] + +*Tiefe der Freigabe* + +Ergebnis aus _Em002-4.1 Checkliste OSS-Community_. + +[%interactive] +* [ ] Minimale Veröffentlichung: Veröffentlichung des Quellcodes und weiterer Artefakte +* [ ] Issue-Tracking: Fehler können gemeldet werden und werden bearbeitet. +* [ ] Community + +field::[rows=1] + +[%interactive] +* [ ] Es liegt keine Verletzung von Rechten Dritter vor (z. B. Patentrechte, geistiges Eigentum, Marken- oder Designschutz). + +Die Prüfungen gemäss [Em002-2] Kapitel 3.2 wurden durchgeführt. Die Rechte an der Software liegen beim Bund, oder sie wird von Mitarbeitenden des Bundes (intern oder extern) entwickelt. Eine Begründung ist insbesondere dann erforderlich, wenn dies nicht der Fall ist. Es ist zudem darzulegen, weshalb die Rechte nicht beim Bund liegen, welche Abklärungen zu proprietären Teilen getroffen wurden sowie was bezüglich möglicher Hindernisse (z. B. Patentschutz) unternommen wurde beziehungsweise wie weit die Abklärungen gingen. + +field::[rows=4] + +[%interactive] +* [ ] Es bestehen keine sicherheitsrelevanten Gründe, die einer Veröffentlichung entgegenstehen. + +Die Prüfungen gemäss [Em002-2] Kapitel 3.3 wurden durchgeführt. + +field::[rows=2] + +[%interactive] +* [ ] Es besteht grundsätzliches Einverständnis und Machbarkeit, die Anwendung als Open Source zu veröffentlichen. + +Verweis auf Protokoll oder Entscheidgremium mit Datum. + +field::[rows=1] + +== Schlussbemerkungen + +Bemerkungen und Verweise auf weitere relevante Dokumente. + +Wird ein Contributor Licence Agreement (CLA) verwendet, so sollte dies hier vermerkt werden (siehe _Em002-3 Leitfaden OSS-Lizenzierung_ Kapitel 8.9). + +field::[rows=4] + +*Ablage des Formulars* + +Legen Sie dieses Formular bei der Projektdokumentation und/oder gemäss den Vorgaben Ihrer Behörde (Organisationseinheit) ab. + +*Lizenz der Checklisten-Vorlage: CC0 1.0 Universal* + +Dieses Dokument wird unter der CC0-Lizenz veröffentlicht. Es darf frei genutzt, verändert und verbreitet werden, auch zu kommerziellen Zwecken und in jedem Format. +endif::[] + +ifeval::["{lang}" == "fr"] +Cette liste de contrôle fait partie du document _Em002-2 Instructions pour la publication de logiciels open source_. Elle doit être remplie au début d'un projet ou lors de l'examen visant à déterminer si un logiciel ne doit pas être publié. + +La description de la liste de contrôle figure dans _[Em002-2]_, chapitre 3. + +Cette liste de contrôle permet également de définir si le développement se fera en open development directement sur un dépôt public. + +Pour le code existant (développé avant l'entrée en vigueur de la LMETA le 1.1.2024), des questions supplémentaires sont prévues. + +Important : si un logiciel ne doit pas être publié en OSS, cette liste de contrôle sert également de justification à une telle décision. + +== Objet + +=== Nom et brève description du logiciel + +Indiquez le nom du logiciel. + +Ce nom devrait être identique dans toutes les listes de contrôle OSS suivantes afin d'assurer une attribution correcte. + +field::[rows=1] + +Décrivez l'objectif et la finalité du logiciel ainsi que son périmètre. + +Si un lien URL existe, veuillez également l'indiquer. + +field::[rows=4] + +=== Personne de contact et examen + +Indiquez l'autorité fédérale (unité d'organisation), la personne de contact ainsi que les personnes responsables de l'examen juridique (p. ex. ISBO/DSBO) qui ont vérifié le respect des exigences de publication. + +field::[rows=3] + +== Liste de contrôle + +*Nouveau logiciel ou logiciel existant* + +S'agit-il d'un nouveau logiciel ou d'un projet existant (voir [Em002-2] chapitre 3.1) ? + +[%interactive] +* [ ] Logiciel existant (développement ultérieur) +* [ ] Nouveau logiciel +* [ ] Logiciel existantfootnote:[Non exigé par la LMETA, mais il est également possible de publier un logiciel existant.] ou développement ultérieur d'un logiciel existant +* [ ] Projet de tiers existant (remplir la _liste de contrôle Em002-4.1 Communauté OSS_) + +field::[rows=1] + +*Cycle de vie* + +À quelle étape du cycle de vie le logiciel se trouve-t-il actuellement (voir [Em002-2] chapitre 3.1) ?footnote:[Le remplacement d'un logiciel existant devrait être indiqué ici comme « planifié ».] + +[%interactive] +* [ ] Planifié +* [ ] En développement +* [ ] En exploitation +* [ ] Fin de vie +* [ ] Archive + +field::[rows=1] + +*Utilisateurs* + +Existe-t-il des personnes ou des organisations, potentielles ou connues, qui utilisent le logiciel ? Existe-t-il des clients potentiels pour le logiciel ? Les utilisateurs possibles et connus peuvent être nommés dans le champ de texte. + +[%interactive] +* [ ] Aucun envisageable +* [ ] Utilisateurs potentiels +* [ ] Utilisateurs connus + +field::[rows=2] + +*Développement propre, développement commun ou projet de tiers* + +Quelle est la structure de base ? S'agit-il d'un développement propre de la Confédération, d'une collaboration, ou le logiciel repose-t-il sur un projet de tiers ? + +La structure du codéveloppement et du projet de tiers peut être précisée dans le champ de texte + +(voir [Em002-2] chapitre 3.1). + +[%interactive] +* [ ] Développement propre +* [ ] Développement commun (_liste de contrôle Em002-4.1 Communauté OSS_ à remplir) +* [ ] Projet de tiers (_liste de contrôle Em002-4.1 Communauté OSS_ à remplir) + +field::[rows=2] + +*Qui publie le logiciel ?* + +[%interactive] +* [ ] Autorité fédérale +* [ ] Prestataire +* [ ] Fournisseur +* [ ] Tiers + +field::[rows=1] + +*Profondeur de la publication* + +Résultat de la _liste de contrôle Em002-4.1 Communauté OSS_. + +[%interactive] +* [ ] Publication minimale : publication du code source et des autres artefacts +* [ ] Suivi des problèmes : les erreurs peuvent être signalées et sont traitées. +* [ ] Communauté + +field::[rows=1] + +[%interactive] +* [ ] Il n'y a aucune violation de droits de tiers (p. ex. droits de brevet, propriété intellectuelle, protection des marques ou des designs). + +Les examens prévus au chapitre 3.2 de [Em002-2] ont été effectués. Les droits sur le logiciel appartiennent à la Confédération, ou celui-ci est développé par des collaborateurs de la Confédération (internes ou externes). Une justification est nécessaire en particulier si tel n'est pas le cas. Il convient également d'exposer pourquoi les droits n'appartiennent pas à la Confédération, quelles vérifications ont été effectuées concernant les parties propriétaires, ainsi que ce qui a été entrepris au sujet d'obstacles éventuels (p. ex. protection par brevet) ou jusqu'où les investigations sont allées. + +field::[rows=4] + +[%interactive] +* [ ] Aucun motif relevant de la sécurité ne s'oppose à la publication. + +Les examens prévus au chapitre 3.3 de [Em002-2] ont été effectués. + +field::[rows=2] + +[%interactive] +* [ ] Il existe un accord de principe et la faisabilité est donnée pour publier l'application en open source. + +Renvoi au procès-verbal ou à l'organe de décision, avec la date. + +field::[rows=1] + +== Remarques finales + +Remarques et renvois à d'autres documents pertinents. + +Si un Contributor Licence Agreement (CLA) est utilisé, cela devrait être indiqué ici (voir _Em002-3 Guide de licences OSS_ chapitre 8.9). + +field::[rows=4] + +*Classement du formulaire* + +Veuillez classer ce formulaire avec la documentation de projet et/ou conformément aux prescriptions de votre autorité (unité d'organisation). + +*Licence du modèle de liste de contrôle : CC0 1.0 Universal* + +Ce document est publié sous licence CC0. Il peut être librement utilisé, modifié et diffusé, y compris à des fins commerciales et dans tout format. +endif::[] + +ifeval::["{lang}" == "it"] +La presente lista di controllo fa parte del documento _Em002-2 Istruzioni per la pubblicazione di software open source_. Va compilata all'inizio di un progetto o in sede di chiarimento se non sia necessario pubblicare un software. + +La descrizione della lista di controllo figura in _[Em002-2]_, capitolo 3. + +Questa lista di controllo consente anche di stabilire se lo sviluppo avverrà come open development direttamente su un repository pubblico. + +Per il codice preesistente (sviluppato prima dell'entrata in vigore della LMeCA il 1.1.2024) sono previste domande supplementari. + +Importante: se un software non deve essere pubblicato come OSS, questa lista di controllo funge anche da motivazione di tale decisione. + +== Oggetto + +=== Nome e breve descrizione del software + +Indicate il nome del software. + +Tale nome dovrebbe essere identico in tutte le liste di controllo OSS successive, affinché l'attribuzione sia corretta. + +field::[rows=1] + +Descrivete l'obiettivo e lo scopo del software nonché la sua portata. + +Se esiste un collegamento URL, indicatelo anch'esso. + +field::[rows=4] + +=== Persona di contatto ed esame + +Indicate l'autorità federale (unità organizzativa), la persona di contatto nonché le persone responsabili dell'esame giuridico (p. es. ISBO/DSBO) che hanno verificato il rispetto delle prescrizioni di pubblicazione. + +field::[rows=3] + +== Lista di controllo + +*Software nuovo o preesistente* + +Si tratta di un software nuovo o di un progetto esistente (cfr. [Em002-2] capitolo 3.1)? + +[%interactive] +* [ ] Software preesistente (ulteriore sviluppo) +* [ ] Software nuovo +* [ ] Software preesistentefootnote:[Non richiesto dalla LMeCA, ma è comunque possibile pubblicare software esistente.] o ulteriore sviluppo di software preesistente +* [ ] Progetto di terzi esistente (compilare la _lista di controllo Em002-4.1 Community OSS_) + +field::[rows=1] + +*Ciclo di vita* + +In quale fase del ciclo di vita si trova attualmente il software (cfr. [Em002-2] capitolo 3.1)?footnote:[La sostituzione di software esistente dovrebbe essere indicata qui come «pianificata».] + +[%interactive] +* [ ] Pianificato +* [ ] In sviluppo +* [ ] In esercizio +* [ ] Fine del ciclo di vita +* [ ] Archivio + +field::[rows=1] + +*Utenti* + +Vi sono persone o organizzazioni, potenziali o note, che utilizzano il software? Vi sono potenziali acquirenti del software? Gli utenti possibili e noti possono essere indicati nel campo di testo. + +[%interactive] +* [ ] Nessuno ipotizzabile +* [ ] Utenti potenziali +* [ ] Utenti noti + +field::[rows=2] + +*Sviluppo proprio, sviluppo congiunto o progetto di terzi* + +Qual è la struttura di base? Si tratta di uno sviluppo proprio della Confederazione, di una collaborazione, oppure il software si basa su un progetto di terzi? + +La struttura dello sviluppo congiunto e del progetto di terzi può essere indicata nel campo di testo + +(cfr. [Em002-2] capitolo 3.1). + +[%interactive] +* [ ] Sviluppo proprio +* [ ] Sviluppo congiunto (compilare la _lista di controllo Em002-4.1 Community OSS_) +* [ ] Progetto di terzi (compilare la _lista di controllo Em002-4.1 Community OSS_) + +field::[rows=2] + +*Chi pubblica il software?* + +[%interactive] +* [ ] Autorità federale +* [ ] Fornitore di prestazioni +* [ ] Fornitore +* [ ] Terzi + +field::[rows=1] + +*Profondità della pubblicazione* + +Risultato della _lista di controllo Em002-4.1 Community OSS_. + +[%interactive] +* [ ] Pubblicazione minima: pubblicazione del codice sorgente e di altri artefatti +* [ ] Issue tracking: gli errori possono essere segnalati e vengono trattati. +* [ ] Community + +field::[rows=1] + +[%interactive] +* [ ] Non sussiste alcuna violazione di diritti di terzi (p. es. diritti di brevetto, proprietà intellettuale, protezione dei marchi o dei design). + +Gli esami di cui al capitolo 3.2 di [Em002-2] sono stati svolti. I diritti sul software spettano alla Confederazione, oppure il software è sviluppato da collaboratori della Confederazione (interni o esterni). Una motivazione è necessaria in particolare se così non è. Occorre inoltre esporre perché i diritti non spettano alla Confederazione, quali verifiche sono state effettuate riguardo alle parti proprietarie nonché che cosa è stato intrapreso in relazione a possibili ostacoli (p. es. protezione brevettuale) o fin dove sono giunti gli accertamenti. + +field::[rows=4] + +[%interactive] +* [ ] Non sussistono motivi rilevanti per la sicurezza che ostino alla pubblicazione. + +Gli esami di cui al capitolo 3.3 di [Em002-2] sono stati svolti. + +field::[rows=2] + +[%interactive] +* [ ] Sussistono l'accordo di principio e la fattibilità per pubblicare l'applicazione come open source. + +Rinvio al verbale o all'organo decisionale, con data. + +field::[rows=1] + +== Osservazioni conclusive + +Osservazioni e rinvii ad altri documenti rilevanti. + +Se viene utilizzato un Contributor Licence Agreement (CLA), dovrebbe essere indicato qui (cfr. _Em002-3 Guida alle licenze OSS_ capitolo 8.9). + +field::[rows=4] + +*Archiviazione del modulo* + +Archiviate questo modulo insieme alla documentazione di progetto e/o conformemente alle prescrizioni della vostra autorità (unità organizzativa). + +*Licenza del modello di lista di controllo: CC0 1.0 Universal* + +Il presente documento è pubblicato sotto licenza CC0. Può essere liberamente utilizzato, modificato e diffuso, anche a scopi commerciali e in qualsiasi formato. +endif::[] + +ifeval::["{lang}" == "rm"] +Questa glista da controlla fa part dal document _Em002-2 Instrucziuns per publitgar software open source_. Ella sto vegnir emplenida al cumenzament d'in project u en cas da sclerir, sch'in software na sto betg vegnir publitgà. + +La descripziun da la glista da controlla sa chatta en _[Em002-2]_, chapitel 3. + +Cun questa glista da controlla po era vegnir fixà, sche il svilup ha lieu sco open development directamain sin in repositori public. + +Per code existent (sviluppà avant l'entrada en vigur da l'EMBAG ils 1.1.2024) stattan a disposiziun dumondas supplementaras. + +Impurtant: Sch'in software na duai betg vegnir relaschà sco OSS, serva questa glista da controlla era sco motivaziun per ina tala decisiun. + +== Object + +=== Num e curta descripziun dal software + +Endatai il num dal software. + +Quest num duess esser identic en tuttas glistas da controlla OSS suandantas, per che l'attribuziun saja correcta. + +field::[rows=1] + +Descrivai la finamira e il intent dal software sco er l'extensiun. + +Sch'i dat in link URL, inditgai era quel. + +field::[rows=4] + +=== Persuna da contact e controlla + +Numnai l'autoritad federala (unitad d'organisaziun), la persuna da contact sco er las persunas responsablas per la controlla giuridica (p.ex. ISBO/DSBO) che han verifitgà l'observaziun da las prescripziuns da publicaziun. + +field::[rows=3] + +== Glista da controlla + +*Software nov u existent* + +Sa tracti d'in software nov u d'in project existent (vesair [Em002-2] chapitel 3.1)? + +[%interactive] +* [ ] Software existent (svilup vinavant) +* [ ] Software nov +* [ ] Software existentfootnote:[Betg pretendì da l'EMBAG, ma igl è era pussaivel da relaschar software existent.] u svilup vinavant da software existent +* [ ] Project da terzas persunas existent (emplenir la _glista da controlla Em002-4.1 Communitad OSS_) + +field::[rows=1] + +*Ciclus da vita* + +En tge fasa dal ciclus da vita sa chatta il software actualmain (vesair [Em002-2] chapitel 3.1)?footnote:[La remplazzada da software existent duess vegnir notada qua sco «planisada».] + +[%interactive] +* [ ] Planisà +* [ ] En svilup +* [ ] En funcziun +* [ ] Fin da la vita +* [ ] Archiv + +field::[rows=1] + +*Utilisaders* + +Dattia persunas u organisaziuns, potenzialas u enconuschentas, ch'utiliseschan il software? Dattia potenzials cumpraders per il software? Utilisaders pussaivels ed enconuschents pon vegnir numnads en il champ da text. + +[%interactive] +* [ ] Nagins imaginabels +* [ ] Utilisaders potenzials +* [ ] Utilisaders enconuschents + +field::[rows=2] + +*Svilup agen, svilup cuminaivel u project da terzas persunas* + +Co ha la structura fundamentala ora? Sa tracti d'in svilup agen da la Confederaziun, d'ina collavuraziun, u basa el sin in project da terzas persunas? + +La structura dal co-svilup e dal project da terzas persunas po vegnir inditgada en il champ da text + +(vesair [Em002-2] chapitel 3.1). + +[%interactive] +* [ ] Svilup agen +* [ ] Svilup cuminaivel (emplenir la _glista da controlla Em002-4.1 Communitad OSS_) +* [ ] Project da terzas persunas (emplenir la _glista da controlla Em002-4.1 Communitad OSS_) + +field::[rows=2] + +*Tgi publitgescha il software?* + +[%interactive] +* [ ] Autoritad federala +* [ ] Purschider da prestaziuns +* [ ] Furnitur +* [ ] Terzas persunas + +field::[rows=1] + +*Profunditad da la relaschada* + +Resultat da la _glista da controlla Em002-4.1 Communitad OSS_. + +[%interactive] +* [ ] Publicaziun minimala: publicaziun dal code da funtauna e d'ulteriurs artefacts +* [ ] Issue-tracking: sbagls pon vegnir annunziads e vegnan tractads. +* [ ] Communitad + +field::[rows=1] + +[%interactive] +* [ ] I n'exista nagina violaziun da dretgs da terzas persunas (p.ex. dretgs da patent, proprietad intellectuala, protecziun da marcas u da designs). + +Las controllas tenor [Em002-2] chapitel 3.2 èn vegnidas fatgas. Ils dretgs sin il software appartegnan a la Confederaziun, u el vegn sviluppà da collaboraturs da la Confederaziun (intern u extern). Ina motivaziun è necessaria en spezial, sche quai n'è betg il cas. I sto ultra da quai vegnir exponì, pertge ch'ils dretgs n'appartegnan betg a la Confederaziun, tge scleridas ch'èn vegnidas fatgas concernent parts proprietaras sco er tge ch'è vegnì entreprendì concernent impedaments pussaivels (p.ex. protecziun da patent) respectivamain quant lunsch che las scleridas èn ì. + +field::[rows=4] + +[%interactive] +* [ ] I n'existan nagins motivs relevants per la segirezza che s'opponan a la publicaziun. + +Las controllas tenor [Em002-2] chapitel 3.3 èn vegnidas fatgas. + +field::[rows=2] + +[%interactive] +* [ ] I exista in consentiment fundamental e la realisabladad da publitgar l'applicaziun sco open source. + +Renviament al protocol u al gremi da decisiun cun data. + +field::[rows=1] + +== Remartgas finalas + +Remartgas e renviaments ad ulteriurs documents relevants. + +Sch'in Contributor Licence Agreement (CLA) vegn utilisà, duess quai vegnir notà qua (vesair _Em002-3 Guida da licenzas OSS_ chapitel 8.9). + +field::[rows=4] + +*Archivaziun dal formular* + +Archivai quest formular tar la documentaziun dal project e/u tenor las prescripziuns da Vossa autoritad (unitad d'organisaziun). + +*Licenza dal model da la glista da controlla: CC0 1.0 Universal* + +Quest document vegn publitgà sut la licenza CC0. El dastga vegnir utilisà, midà e derasà liberamain, era per intents commerzials ed en mintga format. +endif::[] diff --git a/docs/em002-2-2-checklist-oss-analysis-and-preparation.adoc b/docs/em002-2-2-checklist-oss-analysis-and-preparation.adoc new file mode 100644 index 0000000..19a15ad --- /dev/null +++ b/docs/em002-2-2-checklist-oss-analysis-and-preparation.adoc @@ -0,0 +1,656 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-2.2 OSS Analysis and Preparation Checklist +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-2.2 Liste de contrôle Analyse et préparation OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-2.2 Lista di controllo Analisi e preparazione OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-2.2 Glista da controlla Analisa e preparaziun OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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. + +field::[rows=1] + +=== 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. + +field::[rows=3] + +== Checklist + +[%interactive] +* [ ] _Em002-2.1 OSS Preliminary Assessment Checklist_ has been completed and no problematic points were identified. + +[%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. +** 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. + +field::[rows=1] + +[%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. +** 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 + +field::[rows=1] + +[%interactive] +* [ ] The documentation is stored with the source code (see [Em002-2] Annex D.1.) + +Justification/storage location + +field::[rows=1] + +[%interactive] +* [ ] The documentation addresses both end users and technical professionals. + +List of the central documentation + +field::[rows=1] + +[%interactive] +* [ ] Detailed documentation of the source code (OSS specific) + +Important standard documentation (README, LICENSE, CONTRIBUTING, etc.) is available. + +field::[rows=1] + +[%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) + +field::[rows=1] + +[%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. + +field::[rows=1] + +[%interactive] +* [ ] The libraries used by the project are compatible with the project's licence. + +Explanation of review (if not filed as separate document) + +field::[rows=1] + +[%interactive] +* [ ] The project uses a package manager to manage its dependencies. + +[%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. + +[%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. + +field::[rows=1] + +[%interactive] +* [ ] For applications, an 'About' dialogue is available that references the _THIRD-PARTY-LICENSES.md_ file. + +[%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. + +== Concluding remarks + +Comments and references to other relevant documents + +field::[rows=4] + +*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. +endif::[] + +ifeval::["{lang}" == "de"] +Diese Checkliste ist Teil von _Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software_ und richtet sich an IKT-Fachpersonen. + +Sie dient der Überprüfung der Dokumentation und des Quellcodes eines Projekts. Damit hilft sie sicherzustellen, dass die Qualität der Dokumentation ausreicht, um eine Anwendung als Open Source zu veröffentlichen. Zudem lässt sich damit prüfen, ob der Quellcode und alle vom Projekt verwendeten Drittkomponenten keine rechtlichen Risiken bergen. Diese Massnahmen minimieren Sicherheitsrisiken. + +Informationen zu dieser Checkliste finden sich in _[Em002-2]_ in Kapitel 4. + +Darüber hinaus stellt diese Checkliste sicher, dass die Projektdokumentation Endnutzende und technische Fachpersonen gleichermassen anspricht. + +== Gegenstand + +=== Name und Kurzbeschreibung der Software + +Tragen Sie den Namen der Software ein. + +field::[rows=1] + +=== Ansprechperson und Prüfung + +Nennen Sie die Organisation, die Ansprechperson der Fachstelle sowie die verantwortlichen Personen (z. B. ISBO/DSBO), welche die Einhaltung der Veröffentlichungsvorgaben geprüft haben. + +field::[rows=3] + +== Checkliste + +[%interactive] +* [ ] Die _Em002-2.1 Checkliste OSS-Vorabklärung_ wurde ausgefüllt und es wurden keine problematischen Punkte festgestellt. + +[%interactive] +* [ ] Der zu veröffentlichende Quellcode wurde analysiert. +** Prüfen, wie die bestehende Codequalität und die Richtlinien umgesetzt wurden. +** Sicherstellen, dass keine sensiblen (Test-)Daten enthalten sind, z. B. Daten, die auf realen Personen oder Fällen beruhen. +** Aktuelle Dokumentation (siehe [Em002-2] Anhänge D.1. und D.2.) +** Unnötige Dateien oder veraltete Dokumente löschen. +** Code auf Secrets/Zugangsdaten prüfen.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/aktuell/im-fokus/2022/git.html] +** Gezielte Sicherheitstests durchführen und anschliessend ein (öffentliches) Bug-Bounty-Programm einrichten.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +** Alle verwendeten Bibliotheken prüfen, ob die Lizenzen vorliegen und entsprechende Listen (Attributionen) erstellt wurden. +** Beschreibung des Deployments (CI/CD-Pipelinefootnote:[https://de.wikipedia.org/wiki/CI/CD]) und gegebenenfalls Aufbau einer Demo-Instanz. + +field::[rows=1] + +[%interactive] +* [ ] Lizenzwahl +** Allfällige Abhängigkeiten von bestehenden Lizenzen prüfen. +** Bei Drittcode die Nutzungsbedingungen auf Kompatibilität mit der vorgesehenen Lizenz prüfen und den Code nötigenfalls ersetzen. +** Die passende Lizenz anhand des Leitfadens «Em002-3 Leitfaden OSS-Lizenzierung» auswählen (primäre Empfehlungen sind AGPL für Copyleft und MIT für permissiv). + +Gewählte Lizenz und Begründung + +field::[rows=1] + +[%interactive] +* [ ] Die Dokumentation wird zusammen mit dem Quellcode abgelegt (siehe [Em002-2] Anhang D.1.) + +Begründung/Ablageort + +field::[rows=1] + +[%interactive] +* [ ] Die Dokumentation spricht sowohl Endnutzende als auch technische Fachpersonen an. + +Liste der zentralen Dokumentation + +field::[rows=1] + +[%interactive] +* [ ] Ausführliche Dokumentation des Quellcodes (OSS-spezifisch) + +Wichtige Standarddokumentation (README, LICENSE, CONTRIBUTING usw.) ist vorhanden. + +field::[rows=1] + +[%interactive] +* [ ] Der Quellcode enthält einschliesslich Historie keine sensiblen, geschützten oder vertraulichen Personendaten. Oder die Historie wurde vollständig gelöscht. (siehe [Em002-2] Anhang E.2.) + +Erläuterung der Prüfung (falls nicht als separates Dokument abgelegt) + +field::[rows=1] + +[%interactive] +* [ ] Mit dem Lieferanten und allen beteiligten Entwicklerinnen und Entwicklern innerhalb der Bundesverwaltung wurde geklärt, ob Autorenangaben (Namen, E-Mail-Adressen) veröffentlicht werden dürfen. + +Alternativ wurde der Quellcode einschliesslich Historie bereinigt/anonymisiert. + +field::[rows=1] + +[%interactive] +* [ ] Die vom Projekt verwendeten Bibliotheken sind mit der Lizenz des Projekts kompatibel. + +Erläuterung der Prüfung (falls nicht als separates Dokument abgelegt) + +field::[rows=1] + +[%interactive] +* [ ] Das Projekt verwendet einen Paketmanager zur Verwaltung seiner Abhängigkeiten. + +[%interactive] +* [ ] Das Projekt deklariert seine Lizenz im entsprechenden Deskriptor des Paketmanagers. Erstellung einer Software Bill of Materials (SBOM), die alle verwendeten Open-Source-Komponenten auflistet. + +[%interactive] +* [ ] Der Quellcode enthält eine Datei _THIRD-PARTY-LICENSES.md_, die für jede verwendete Bibliothek aufführt: den Projektnamen der Bibliothek, die Homepage der Bibliothek, den SPDX-Identifikator der Lizenz der Bibliothek sowie einen Link auf die Lizenz der Bibliothek. + +field::[rows=1] + +[%interactive] +* [ ] Bei Anwendungen steht ein «Über»-Dialog zur Verfügung, der auf die Datei _THIRD-PARTY-LICENSES.md_ verweist. + +[%interactive] +* [ ] Im Rahmen des Code-Review-Prozesses wird sichergestellt, dass die Datei _THIRD-PARTY-LICENSES.md_ bei jeder Änderung an den Bibliotheken nachgeführt wird. + +== Schlussbemerkungen + +Bemerkungen und Verweise auf weitere relevante Dokumente + +field::[rows=4] + +*Ablage des Formulars* + +Legen Sie dieses Formular bei der Projektdokumentation und/oder gemäss den Vorgaben Ihrer Behörde (Organisationseinheit) ab. + +*Lizenz der Checklisten-Vorlage: CC0 1.0 Universal* + +Dieses Dokument wird unter der https://creativecommons.org/publicdomain/zero/1.0/[_CC0-Lizenz_] veröffentlicht. Es darf frei genutzt, verändert und verbreitet werden, auch zu kommerziellen Zwecken und in jedem Format. +endif::[] + +ifeval::["{lang}" == "fr"] +Cette liste de contrôle fait partie du document _Em002-2 Instructions pour la publication de logiciels open source_ et s'adresse aux spécialistes TIC. + +Elle sert à examiner la documentation et le code source d'un projet. Elle contribue ainsi à garantir que le niveau de qualité de la documentation est suffisant pour publier une application en open source. Elle permet également de vérifier que le code source et tous les composants tiers utilisés par le projet ne présentent aucun risque juridique. Ces mesures réduisent les risques de sécurité. + +Les informations relatives à cette liste de contrôle figurent dans _[Em002-2]_, chapitre 4. + +Cette liste de contrôle garantit en outre que la documentation du projet s'adresse aussi bien aux utilisateurs finaux qu'aux spécialistes techniques. + +== Objet + +=== Nom et brève description du logiciel + +Indiquez le nom du logiciel. + +field::[rows=1] + +=== Personne de contact et examen + +Indiquez l'organisation, la personne de contact du service spécialisé ainsi que les personnes responsables (p. ex. ISBO/DSBO) qui ont vérifié le respect des exigences de publication. + +field::[rows=3] + +== Liste de contrôle + +[%interactive] +* [ ] La _liste de contrôle Em002-2.1 Évaluation préalable OSS_ a été remplie et aucun point problématique n'a été constaté. + +[%interactive] +* [ ] Le code source à publier a été analysé. +** Vérifier comment la qualité du code existante et les directives ont été mises en œuvre. +** S'assurer qu'aucune donnée (de test) sensible n'est incluse, p. ex. des données fondées sur des personnes ou des cas réels. +** Documentation à jour (voir [Em002-2] annexes D.1. et D.2.) +** Supprimer les fichiers inutiles ou les documents obsolètes. +** Vérifier le code à la recherche de secrets ou d'identifiants.footnote:[https://www.ncsc.admin.ch/ncsc/fr/home/aktuell/im-fokus/2022/git.html] +** Effectuer des tests de sécurité ciblés et mettre ensuite en place un programme de bug bounty (public).footnote:[https://www.ncsc.admin.ch/ncsc/fr/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +** Examiner toutes les bibliothèques utilisées afin de s'assurer que les licences sont disponibles et que les listes correspondantes (attributions) ont été établies. +** Description du déploiement (pipeline CI/CDfootnote:[https://fr.wikipedia.org/wiki/CI/CD]) et, le cas échéant, mise en place d'une instance de démonstration. + +field::[rows=1] + +[%interactive] +* [ ] Choix de la licence +** Vérifier les éventuelles dépendances à des licences existantes. +** Pour le code de tiers, vérifier la compatibilité des conditions d'utilisation avec la licence prévue et remplacer le code si nécessaire. +** Choisir la licence appropriée à l'aide du guide « Em002-3 Guide de licences OSS » (les recommandations principales sont l'AGPL pour le copyleft et la MIT pour les licences permissives). + +Licence choisie et justification + +field::[rows=1] + +[%interactive] +* [ ] La documentation est conservée avec le code source (voir [Em002-2] annexe D.1.) + +Justification / lieu de conservation + +field::[rows=1] + +[%interactive] +* [ ] La documentation s'adresse aussi bien aux utilisateurs finaux qu'aux spécialistes techniques. + +Liste de la documentation centrale + +field::[rows=1] + +[%interactive] +* [ ] Documentation détaillée du code source (spécifique à l'OSS) + +La documentation standard importante (README, LICENSE, CONTRIBUTING, etc.) est disponible. + +field::[rows=1] + +[%interactive] +* [ ] Le code source, historique compris, ne contient aucune donnée personnelle sensible, protégée ou confidentielle. Ou l'historique a été entièrement supprimé. (voir [Em002-2] annexe E.2.) + +Explication de l'examen (s'il n'est pas classé comme document distinct) + +field::[rows=1] + +[%interactive] +* [ ] Il a été clarifié avec le fournisseur et tous les développeurs concernés au sein de l'administration fédérale si les informations sur les auteurs (noms, adresses électroniques) peuvent être publiées. + +À défaut, le code source, historique compris, a été nettoyé ou anonymisé. + +field::[rows=1] + +[%interactive] +* [ ] Les bibliothèques utilisées par le projet sont compatibles avec la licence du projet. + +Explication de l'examen (s'il n'est pas classé comme document distinct) + +field::[rows=1] + +[%interactive] +* [ ] Le projet utilise un gestionnaire de paquets pour gérer ses dépendances. + +[%interactive] +* [ ] Le projet déclare sa licence dans le descripteur correspondant du gestionnaire de paquets. Établissement d'une Software Bill of Materials (SBOM) recensant tous les composants open source utilisés. + +[%interactive] +* [ ] Le code source contient un fichier _THIRD-PARTY-LICENSES.md_ indiquant pour chaque bibliothèque utilisée : le nom du projet de la bibliothèque, sa page d'accueil, l'identifiant SPDX de sa licence et un lien vers celle-ci. + +field::[rows=1] + +[%interactive] +* [ ] Pour les applications, une boîte de dialogue « À propos » renvoyant au fichier _THIRD-PARTY-LICENSES.md_ est disponible. + +[%interactive] +* [ ] Dans le cadre du processus de revue de code, il est garanti que le fichier _THIRD-PARTY-LICENSES.md_ est mis à jour à chaque modification des bibliothèques. + +== Remarques finales + +Remarques et renvois à d'autres documents pertinents + +field::[rows=4] + +*Classement du formulaire* + +Veuillez classer ce formulaire avec la documentation de projet et/ou conformément aux prescriptions de votre autorité (unité d'organisation). + +*Licence du modèle de liste de contrôle : CC0 1.0 Universal* + +Ce document est publié sous la https://creativecommons.org/publicdomain/zero/1.0/[_licence CC0_]. Il peut être librement utilisé, modifié et diffusé, y compris à des fins commerciales et dans tout format. +endif::[] + +ifeval::["{lang}" == "it"] +La presente lista di controllo fa parte del documento _Em002-2 Istruzioni per la pubblicazione di software open source_ ed è destinata agli specialisti TIC. + +Serve a esaminare la documentazione e il codice sorgente di un progetto. Contribuisce così a garantire che il livello qualitativo della documentazione sia sufficiente per pubblicare un'applicazione come open source. Consente inoltre di verificare che il codice sorgente e tutti i componenti di terzi utilizzati dal progetto non comportino rischi giuridici. Queste misure riducono al minimo i rischi per la sicurezza. + +Le informazioni su questa lista di controllo figurano in _[Em002-2]_, capitolo 4. + +Questa lista di controllo garantisce inoltre che la documentazione di progetto si rivolga in egual misura agli utenti finali e agli specialisti tecnici. + +== Oggetto + +=== Nome e breve descrizione del software + +Indicate il nome del software. + +field::[rows=1] + +=== Persona di contatto ed esame + +Indicate l'organizzazione, la persona di contatto del servizio specializzato nonché le persone responsabili (p. es. ISBO/DSBO) che hanno verificato il rispetto delle prescrizioni di pubblicazione. + +field::[rows=3] + +== Lista di controllo + +[%interactive] +* [ ] La _lista di controllo Em002-2.1 Valutazione preliminare OSS_ è stata compilata e non sono stati rilevati punti problematici. + +[%interactive] +* [ ] Il codice sorgente da pubblicare è stato analizzato. +** Verificare come sono state attuate la qualità del codice esistente e le direttive. +** Assicurarsi che non siano contenuti dati (di test) sensibili, p. es. dati basati su persone o casi reali. +** Documentazione aggiornata (cfr. [Em002-2] allegati D.1. e D.2.) +** Cancellare i file superflui o i documenti obsoleti. +** Verificare il codice alla ricerca di segreti o credenziali.footnote:[https://www.ncsc.admin.ch/ncsc/it/home/aktuell/im-fokus/2022/git.html] +** Svolgere test di sicurezza mirati e istituire in seguito un programma di bug bounty (pubblico).footnote:[https://www.ncsc.admin.ch/ncsc/it/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +** Esaminare tutte le librerie utilizzate per accertare che le licenze siano disponibili e che siano stati redatti i relativi elenchi (attribuzioni). +** Descrizione del deployment (pipeline CI/CDfootnote:[https://it.wikipedia.org/wiki/CI/CD]) ed eventualmente allestimento di un'istanza dimostrativa. + +field::[rows=1] + +[%interactive] +* [ ] Scelta della licenza +** Verificare eventuali dipendenze da licenze esistenti. +** Per il codice di terzi, verificare la compatibilità delle condizioni d'uso con la licenza prevista e, se necessario, sostituire il codice. +** Scegliere la licenza adeguata sulla base della guida «Em002-3 Guida alle licenze OSS» (le raccomandazioni principali sono l'AGPL per il copyleft e la MIT per le licenze permissive). + +Licenza scelta e motivazione + +field::[rows=1] + +[%interactive] +* [ ] La documentazione è archiviata insieme al codice sorgente (cfr. [Em002-2] allegato D.1.) + +Motivazione / luogo di archiviazione + +field::[rows=1] + +[%interactive] +* [ ] La documentazione si rivolge sia agli utenti finali sia agli specialisti tecnici. + +Elenco della documentazione centrale + +field::[rows=1] + +[%interactive] +* [ ] Documentazione dettagliata del codice sorgente (specifica per l'OSS) + +La documentazione standard importante (README, LICENSE, CONTRIBUTING ecc.) è disponibile. + +field::[rows=1] + +[%interactive] +* [ ] Il codice sorgente, cronologia compresa, non contiene dati personali sensibili, protetti o confidenziali. Oppure la cronologia è stata cancellata completamente. (cfr. [Em002-2] allegato E.2.) + +Spiegazione dell'esame (se non archiviata come documento separato) + +field::[rows=1] + +[%interactive] +* [ ] Con il fornitore e con tutti gli sviluppatori coinvolti in seno all'Amministrazione federale è stato chiarito se le indicazioni sugli autori (nomi, indirizzi e-mail) possono essere pubblicate. + +In alternativa il codice sorgente, cronologia compresa, è stato ripulito o anonimizzato. + +field::[rows=1] + +[%interactive] +* [ ] Le librerie utilizzate dal progetto sono compatibili con la licenza del progetto. + +Spiegazione dell'esame (se non archiviata come documento separato) + +field::[rows=1] + +[%interactive] +* [ ] Il progetto utilizza un gestore di pacchetti per gestire le proprie dipendenze. + +[%interactive] +* [ ] Il progetto dichiara la propria licenza nel corrispondente descrittore del gestore di pacchetti. Allestimento di una Software Bill of Materials (SBOM) che elenca tutti i componenti open source utilizzati. + +[%interactive] +* [ ] Il codice sorgente contiene un file _THIRD-PARTY-LICENSES.md_ che indica per ogni libreria utilizzata: il nome del progetto della libreria, la sua homepage, l'identificatore SPDX della sua licenza e un collegamento alla stessa. + +field::[rows=1] + +[%interactive] +* [ ] Per le applicazioni è disponibile una finestra di dialogo «Informazioni su» che rinvia al file _THIRD-PARTY-LICENSES.md_. + +[%interactive] +* [ ] Nell'ambito del processo di code review si garantisce che il file _THIRD-PARTY-LICENSES.md_ venga aggiornato a ogni modifica delle librerie. + +== Osservazioni conclusive + +Osservazioni e rinvii ad altri documenti rilevanti + +field::[rows=4] + +*Archiviazione del modulo* + +Archiviate questo modulo insieme alla documentazione di progetto e/o conformemente alle prescrizioni della vostra autorità (unità organizzativa). + +*Licenza del modello di lista di controllo: CC0 1.0 Universal* + +Il presente documento è pubblicato sotto la https://creativecommons.org/publicdomain/zero/1.0/[_licenza CC0_]. Può essere liberamente utilizzato, modificato e diffuso, anche a scopi commerciali e in qualsiasi formato. +endif::[] + +ifeval::["{lang}" == "rm"] +Questa glista da controlla fa part da _Em002-2 Instrucziuns per publitgar software open source_ e s'adressa a persunas spezialisadas en TIC. + +Ella serva a controllar la documentaziun ed il code da funtauna d'in project. Uschia gida ella a garantir che la qualitad da la documentaziun tanschia per publitgar in'applicaziun sco open source. Ultra da quai po vegnir controllà, sche il code da funtauna e tut las cumponentas da terzas persunas utilisadas dal project na cumportan nagins ristgs giuridics. Questas mesiras reduceschan ils ristgs da segirezza. + +Infurmaziuns davart questa glista da controlla sa chattan en _[Em002-2]_ en il chapitel 4. + +Ultra da quai garantescha questa glista da controlla che la documentaziun dal project s'adressia tant als utilisaders finals sco er a las persunas spezialisadas tecnicas. + +== Object + +=== Num e curta descripziun dal software + +Endatai il num dal software. + +field::[rows=1] + +=== Persuna da contact e controlla + +Numnai l'organisaziun, la persuna da contact dal post spezialisà sco er las persunas responsablas (p.ex. ISBO/DSBO) che han verifitgà l'observaziun da las prescripziuns da publicaziun. + +field::[rows=3] + +== Glista da controlla + +[%interactive] +* [ ] La _glista da controlla Em002-2.1 Evaluaziun preliminara OSS_ è vegnida emplenida e i n'èn vegnids constatads nagins puncts problematics. + +[%interactive] +* [ ] Il code da funtauna da publitgar è vegnì analisà. +** Controllar, co che la qualitad dal code existenta e las directivas èn vegnidas realisadas. +** Garantir che naginas datas (da test) sensiblas na sajan cuntegnidas, p.ex. datas che sa basan sin persunas u cas reals. +** Documentaziun actuala (vesair [Em002-2] agiuntas D.1. e D.2.) +** Stizzar datotecas nunnecessarias u documents antiquads. +** Controllar il code concernent secrets/datas d'access.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/aktuell/im-fokus/2022/git.html] +** Exequir tests da segirezza mirads ed installar suenter in program da bug bounty (public).footnote:[https://www.ncsc.admin.ch/ncsc/de/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +** Controllar tuttas bibliotecas utilisadas, sche las licenzas èn avant maun e sche las glistas correspundentas (attribuziuns) èn vegnidas fatgas. +** Descripziun dal deployment (pipeline CI/CDfootnote:[https://de.wikipedia.org/wiki/CI/CD]) ed eventualmain construcziun d'ina instanza da demonstraziun. + +field::[rows=1] + +[%interactive] +* [ ] Tscherna da la licenza +** Controllar eventualas dependenzas da licenzas existentas. +** Per code da terzas persunas controllar las cundiziuns d'utilisaziun concernent la cumpatibilitad cun la licenza previsa e remplazzar il code sche necessari. +** Tscherner la licenza adattada cun agid da la guida «Em002-3 Guida da licenzas OSS» (las recumandaziuns principalas èn l'AGPL per copyleft e la MIT per permissiv). + +Licenza tschernida e motivaziun + +field::[rows=1] + +[%interactive] +* [ ] La documentaziun vegn archivada ensemen cun il code da funtauna (vesair [Em002-2] agiunta D.1.) + +Motivaziun/lieu d'archivaziun + +field::[rows=1] + +[%interactive] +* [ ] La documentaziun s'adressa tant als utilisaders finals sco er a las persunas spezialisadas tecnicas. + +Glista da la documentaziun centrala + +field::[rows=1] + +[%interactive] +* [ ] Documentaziun detagliada dal code da funtauna (specifica per OSS) + +La documentaziun standard impurtanta (README, LICENSE, CONTRIBUTING etc.) è avant maun. + +field::[rows=1] + +[%interactive] +* [ ] Il code da funtauna na cuntegna, inclusiv la cronologia, naginas datas persunalas sensiblas, protegidas u confidenzialas. U la cronologia è vegnida stizzada cumplettamain. (vesair [Em002-2] agiunta E.2.) + +Explicaziun da la controlla (sche betg archivada sco document separà) + +field::[rows=1] + +[%interactive] +* [ ] Cun il furnitur e cun tut ils sviluppaders participads entaifer l'administraziun federala è vegnì scleri, sche las indicaziuns davart ils auturs (nums, adressas d'e-mail) dastgan vegnir publitgadas. + +Alternativamain è il code da funtauna, inclusiv la cronologia, vegnì rundà/anonimisà. + +field::[rows=1] + +[%interactive] +* [ ] Las bibliotecas utilisadas dal project èn cumpatiblas cun la licenza dal project. + +Explicaziun da la controlla (sche betg archivada sco document separà) + +field::[rows=1] + +[%interactive] +* [ ] Il project utilisescha in manager da pachets per administrar sias dependenzas. + +[%interactive] +* [ ] Il project declerescha sia licenza en il descriptur correspundent dal manager da pachets. Elavuraziun d'ina Software Bill of Materials (SBOM) che renumbra tuttas cumponentas open source utilisadas. + +[%interactive] +* [ ] Il code da funtauna cuntegna ina datoteca _THIRD-PARTY-LICENSES.md_ che inditgescha per mintga biblioteca utilisada: il num dal project da la biblioteca, sia pagina d'internet, l'identificatur SPDX da sia licenza ed in link sin quella. + +field::[rows=1] + +[%interactive] +* [ ] Tar applicaziuns stat a disposiziun in dialog «Davart» che renviescha a la datoteca _THIRD-PARTY-LICENSES.md_. + +[%interactive] +* [ ] En il rom dal process da code review vegn garantì che la datoteca _THIRD-PARTY-LICENSES.md_ vegnia actualisada tar mintga midada da las bibliotecas. + +== Remartgas finalas + +Remartgas e renviaments ad ulteriurs documents relevants + +field::[rows=4] + +*Archivaziun dal formular* + +Archivai quest formular tar la documentaziun dal project e/u tenor las prescripziuns da Vossa autoritad (unitad d'organisaziun). + +*Licenza dal model da la glista da controlla: CC0 1.0 Universal* + +Quest document vegn publitgà sut la https://creativecommons.org/publicdomain/zero/1.0/[_licenza CC0_]. El dastga vegnir utilisà, midà e derasà liberamain, era per intents commerzials ed en mintga format. +endif::[] diff --git a/docs/em002-2-3-checklist-oss-release-and-publication.adoc b/docs/em002-2-3-checklist-oss-release-and-publication.adoc new file mode 100644 index 0000000..8f0a94d --- /dev/null +++ b/docs/em002-2-3-checklist-oss-release-and-publication.adoc @@ -0,0 +1,576 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-2.3 OSS Release and Publication Checklist +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-2.3 Liste de contrôle Validation et publication OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-2.3 Glista da controlla Relaschada e publicaziun OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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. + +field::[rows=1] + +=== 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. + +field::[rows=3] + +=== 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.] + +field::[rows=3] + +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. + +field::[rows=4] + +== Checklist + +The checklist is to be completed before actual publication. + +[%interactive] +* [ ] 'Em002-2.1 OSS Preliminary Assessment Checklist' has been completed and no problematic points were identified. + +[%interactive] +* [ ] 'Em002-2.2 OSS Analysis and Preparation Checklist' has been completed and no problematic points were identified. + +[%interactive] +* [ ] Licence has been selected. + +Selected licence and justification + +field::[rows=2] + +[%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. + +There may also be OSS checks in the repositories. + +The relevant configuration is described and the person responsible is named. + +field::[rows=1] + +[%interactive] +* [ ] Community and support is regulated (via 'Em002-4.1 OSS Community Checklist') + +The checklist is attached. The key points are included here. + +field::[rows=1] + +[%interactive] +* [ ] Level and method of support have been clarified. + +Indication of how this has been regulated. + +field::[rows=1] + +[%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. + +If a new repository or organisation is created, this can be reported via opensource@bk.admin.ch for inclusion in the OSS Catalogue. + +[%interactive] +* [ ] Transferred responsibilities + +Indication of whether responsibility for release was transferred to a third party (supplier, support, association) during procurement or subsequently. + +field::[rows=2] + +[%interactive] +* [ ] Green light for open sourcing from the application and budget managers + +Names and date + +field::[rows=2] + +== Concluding remarks + +Comments and references to other relevant documents + +field::[rows=4] + +*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. +endif::[] + +ifeval::["{lang}" == "de"] +Diese Checkliste ist Teil des Dokuments «Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software». + +Sie schliesst die Anleitung ab und führt zur Freigabe der Software unter einer Open-Source-Lizenz. Die Beschreibung der Checkliste findet sich in [Em002-2] Anhang D. + +== Gegenstand + +=== Name und Kurzbeschreibung der Software + +Tragen Sie den Namen der Software ein. + +field::[rows=1] + +=== Ansprechperson und Prüfung + +Nennen Sie die Organisation, die Ansprechperson der Fachstelle sowie die verantwortlichen Personen (z. B. ISBO/DSBO), welche die Einhaltung der Veröffentlichungsvorgaben geprüft haben. + +field::[rows=3] + +=== Repository-Namen und Entwicklerberechtigungen + +Geben Sie die geplanten Repository-Namen der zu veröffentlichenden Software sowie die gewählte Veröffentlichungsplattform an.footnote:[Ein Repository unter der GitHub-Organisation der Bundeskanzlei (http://github.com/swiss) kann bei opensource@bk.admin.ch beantragt werden.] + +field::[rows=3] + +Geben Sie an, wer (GitHub-Benutzername, Name, Stelle, Funktion) am Repository arbeitet. Befindet sich dieses in einem Repository eines Amtes, so ist anzugeben, wer die Person autorisiert hat. Diese Person ist anschliessend auch für die Lösung verantwortlich, falls die erste Person die Organisation verlässt oder ihre Stelle wechselt. Zudem sollte angegeben werden, ob Personen als Privatpersonen oder als Teil des Amtes handeln. Nennen Sie das GitHub-Benutzerkonto, dem die Rolle Repository-Administrator zugewiesen werden soll. Es kann mehrere Administratorinnen und Administratoren geben. + +field::[rows=4] + +== Checkliste + +Die Checkliste ist vor der eigentlichen Veröffentlichung auszufüllen. + +[%interactive] +* [ ] Die «Em002-2.1 Checkliste OSS-Vorabklärung» wurde ausgefüllt und es wurden keine problematischen Punkte festgestellt. + +[%interactive] +* [ ] Die «Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung» wurde ausgefüllt und es wurden keine problematischen Punkte festgestellt. + +[%interactive] +* [ ] Die Lizenz wurde ausgewählt. + +Gewählte Lizenz und Begründung + +field::[rows=2] + +[%interactive] +* [ ] Das ISDS-Konzept wurde erstellt. + +Die einschlägigen Prüfungen wurden durchgeführt. Verweisen Sie auf Dokumente/Prüfungen. Es ist festgelegt, wie mit sicherheitsrelevanten Meldungen Dritter umgegangen wird. + +Gegebenenfalls untersteht die Software einem Bug-Bounty-Programm. + +Es kann zudem OSS-Prüfungen in den Repositories geben. + +Die entsprechende Konfiguration ist beschrieben und die verantwortliche Person ist benannt. + +field::[rows=1] + +[%interactive] +* [ ] Community und Support sind geregelt (über «Em002-4.1 Checkliste OSS-Community») + +Die Checkliste liegt bei. Die wichtigsten Punkte sind hier aufgeführt. + +field::[rows=1] + +[%interactive] +* [ ] Umfang und Art des Supports wurden geklärt. + +Angabe, wie dies geregelt wurde. + +field::[rows=1] + +[%interactive] +* [ ] Für die Veröffentlichung wurde eine *publiccode.yml* erstellt. + +Der Metadatenstandard https://yml.publiccode.tools/ beschreibt die Software. Das festgelegte Format macht die Veröffentlichung besser auffindbar und wiederverwendbar. + +Diese ist im Hauptverzeichnis des Repositorys abzulegen. + +Wird ein neues Repository oder eine neue Organisation erstellt, so kann dies über opensource@bk.admin.ch zur Aufnahme in den OSS-Katalog gemeldet werden. + +[%interactive] +* [ ] Übertragene Verantwortlichkeiten + +Angabe, ob die Verantwortung für die Freigabe bei der Beschaffung oder nachträglich an Dritte (Lieferant, Support, Verein) übertragen wurde. + +field::[rows=2] + +[%interactive] +* [ ] Grünes Licht für das Open Sourcing durch die Applikations- und Budgetverantwortlichen + +Namen und Datum + +field::[rows=2] + +== Schlussbemerkungen + +Bemerkungen und Verweise auf weitere relevante Dokumente + +field::[rows=4] + +*Ablage des Formulars* + +Legen Sie dieses Formular bei der Projektdokumentation und/oder gemäss den Vorgaben Ihrer Behörde (Organisationseinheit) ab. + +*Lizenz der Checklisten-Vorlage: CC0 1.0 Universal* + +Dieses Dokument wird unter der https://creativecommons.org/publicdomain/zero/1.0/[_CC0-Lizenz_] veröffentlicht. Es darf frei genutzt, verändert und verbreitet werden, auch zu kommerziellen Zwecken und in jedem Format. +endif::[] + +ifeval::["{lang}" == "fr"] +Cette liste de contrôle fait partie du document « Em002-2 Instructions pour la publication de logiciels open source ». + +Elle conclut les instructions et aboutit à la publication du logiciel sous une licence open source. La description de la liste de contrôle figure dans [Em002-2] annexe D. + +== Objet + +=== Nom et brève description du logiciel + +Indiquez le nom du logiciel. + +field::[rows=1] + +=== Personne de contact et examen + +Indiquez l'organisation, la personne de contact du service spécialisé ainsi que les personnes responsables (p. ex. ISBO/DSBO) qui ont vérifié le respect des exigences de publication. + +field::[rows=3] + +=== Noms des dépôts et autorisations des développeurs + +Indiquez les noms de dépôt prévus pour le logiciel à publier ainsi que la plateforme de publication choisie.footnote:[Un dépôt au sein de l'organisation GitHub de la Chancellerie fédérale (http://github.com/swiss) peut être demandé à opensource@bk.admin.ch.] + +field::[rows=3] + +Indiquez qui (nom d'utilisateur GitHub, nom, poste, fonction) travaille sur le dépôt. Si celui-ci se trouve dans un dépôt d'un office, il faut préciser qui a autorisé la personne. Cette personne est alors également responsable de la solution si la première quitte l'organisation ou change de poste. Il convient également de préciser si les personnes agissent à titre privé ou en tant que membres de l'office. Indiquez le compte utilisateur GitHub auquel doit être attribué le rôle d'administrateur du dépôt. Il peut y avoir plusieurs administrateurs. + +field::[rows=4] + +== Liste de contrôle + +La liste de contrôle doit être remplie avant la publication proprement dite. + +[%interactive] +* [ ] La « liste de contrôle Em002-2.1 Évaluation préalable OSS » a été remplie et aucun point problématique n'a été constaté. + +[%interactive] +* [ ] La « liste de contrôle Em002-2.2 Analyse et préparation OSS » a été remplie et aucun point problématique n'a été constaté. + +[%interactive] +* [ ] La licence a été choisie. + +Licence choisie et justification + +field::[rows=2] + +[%interactive] +* [ ] Le concept SIPD a été établi. + +Les examens pertinents ont été effectués. Renvoyez aux documents et aux examens. Il est défini comment les signalements de tiers relevant de la sécurité seront traités. + +Le cas échéant, le logiciel est soumis à un programme de bug bounty. + +Des contrôles OSS peuvent en outre exister dans les dépôts. + +La configuration correspondante est décrite et la personne responsable est désignée. + +field::[rows=1] + +[%interactive] +* [ ] La communauté et le support sont réglés (via la « liste de contrôle Em002-4.1 Communauté OSS ») + +La liste de contrôle est jointe. Les points essentiels figurent ici. + +field::[rows=1] + +[%interactive] +* [ ] L'étendue et la forme du support ont été clarifiées. + +Indication de la manière dont cela a été réglé. + +field::[rows=1] + +[%interactive] +* [ ] Un fichier *publiccode.yml* a été créé pour la publication. + +Le standard de métadonnées https://yml.publiccode.tools/ décrit le logiciel. Le format défini rend la publication plus facile à trouver et à réutiliser. + +Ce fichier doit être enregistré dans le répertoire principal du dépôt. + +Si un nouveau dépôt ou une nouvelle organisation est créé, cela peut être annoncé à opensource@bk.admin.ch en vue de l'inscription au catalogue OSS. + +[%interactive] +* [ ] Responsabilités transférées + +Indication précisant si la responsabilité de la publication a été transférée à des tiers (fournisseur, support, association) lors de l'acquisition ou ultérieurement. + +field::[rows=2] + +[%interactive] +* [ ] Feu vert pour l'open sourcing de la part des responsables de l'application et du budget + +Noms et date + +field::[rows=2] + +== Remarques finales + +Remarques et renvois à d'autres documents pertinents + +field::[rows=4] + +*Classement du formulaire* + +Veuillez classer ce formulaire avec la documentation de projet et/ou conformément aux prescriptions de votre autorité (unité d'organisation). + +*Licence du modèle de liste de contrôle : CC0 1.0 Universal* + +Ce document est publié sous la https://creativecommons.org/publicdomain/zero/1.0/[_licence CC0_]. Il peut être librement utilisé, modifié et diffusé, y compris à des fins commerciales et dans tout format. +endif::[] + +ifeval::["{lang}" == "it"] +La presente lista di controllo fa parte del documento «Em002-2 Istruzioni per la pubblicazione di software open source». + +Essa conclude le istruzioni e porta al rilascio del software sotto una licenza open source. La descrizione della lista di controllo figura in [Em002-2] allegato D. + +== Oggetto + +=== Nome e breve descrizione del software + +Indicate il nome del software. + +field::[rows=1] + +=== Persona di contatto ed esame + +Indicate l'organizzazione, la persona di contatto del servizio specializzato nonché le persone responsabili (p. es. ISBO/DSBO) che hanno verificato il rispetto delle prescrizioni di pubblicazione. + +field::[rows=3] + +=== Nomi dei repository e autorizzazioni degli sviluppatori + +Indicate i nomi di repository previsti per il software da pubblicare nonché la piattaforma di pubblicazione scelta.footnote:[Un repository nell'organizzazione GitHub della Cancelleria federale (http://github.com/swiss) può essere richiesto a opensource@bk.admin.ch.] + +field::[rows=3] + +Indicate chi (nome utente GitHub, nome, posizione, funzione) lavora al repository. Se questo si trova in un repository di un ufficio, occorre indicare chi ha autorizzato la persona. Tale persona è poi responsabile anche della soluzione qualora la prima lasci l'organizzazione o cambi posizione. Andrebbe inoltre precisato se le persone agiscono a titolo privato o in quanto parte dell'ufficio. Indicate l'account utente GitHub al quale deve essere attribuito il ruolo di amministratore del repository. Vi possono essere più amministratori. + +field::[rows=4] + +== Lista di controllo + +La lista di controllo va compilata prima della pubblicazione vera e propria. + +[%interactive] +* [ ] La «lista di controllo Em002-2.1 Valutazione preliminare OSS» è stata compilata e non sono stati rilevati punti problematici. + +[%interactive] +* [ ] La «lista di controllo Em002-2.2 Analisi e preparazione OSS» è stata compilata e non sono stati rilevati punti problematici. + +[%interactive] +* [ ] La licenza è stata scelta. + +Licenza scelta e motivazione + +field::[rows=2] + +[%interactive] +* [ ] Il concetto SIPD è stato allestito. + +Gli esami pertinenti sono stati svolti. Rinviate ai documenti e agli esami. È stabilito come vengono trattate le segnalazioni di terzi rilevanti per la sicurezza. + +Se del caso, il software è sottoposto a un programma di bug bounty. + +Nei repository possono inoltre essere previsti controlli OSS. + +La relativa configurazione è descritta e la persona responsabile è designata. + +field::[rows=1] + +[%interactive] +* [ ] Community e supporto sono disciplinati (mediante la «lista di controllo Em002-4.1 Community OSS») + +La lista di controllo è allegata. I punti essenziali figurano qui. + +field::[rows=1] + +[%interactive] +* [ ] L'entità e la modalità del supporto sono state chiarite. + +Indicazione di come ciò è stato disciplinato. + +field::[rows=1] + +[%interactive] +* [ ] Per la pubblicazione è stato creato un file *publiccode.yml*. + +Lo standard di metadati https://yml.publiccode.tools/ descrive il software. Il formato definito rende la pubblicazione più facilmente reperibile e riutilizzabile. + +Il file va salvato nella directory principale del repository. + +Se viene creato un nuovo repository o una nuova organizzazione, ciò può essere segnalato a opensource@bk.admin.ch per l'inserimento nel catalogo OSS. + +[%interactive] +* [ ] Responsabilità trasferite + +Indicazione se la responsabilità della pubblicazione è stata trasferita a terzi (fornitore, supporto, associazione) al momento dell'acquisto o successivamente. + +field::[rows=2] + +[%interactive] +* [ ] Via libera all'open sourcing da parte dei responsabili dell'applicazione e del budget + +Nomi e data + +field::[rows=2] + +== Osservazioni conclusive + +Osservazioni e rinvii ad altri documenti rilevanti + +field::[rows=4] + +*Archiviazione del modulo* + +Archiviate questo modulo insieme alla documentazione di progetto e/o conformemente alle prescrizioni della vostra autorità (unità organizzativa). + +*Licenza del modello di lista di controllo: CC0 1.0 Universal* + +Il presente documento è pubblicato sotto la https://creativecommons.org/publicdomain/zero/1.0/[_licenza CC0_]. Può essere liberamente utilizzato, modificato e diffuso, anche a scopi commerciali e in qualsiasi formato. +endif::[] + +ifeval::["{lang}" == "rm"] +Questa glista da controlla fa part dal document «Em002-2 Instrucziuns per publitgar software open source». + +Ella conclura las instrucziuns e maina a la relaschada dal software sut ina licenza open source. La descripziun da la glista da controlla sa chatta en [Em002-2] agiunta D. + +== Object + +=== Num e curta descripziun dal software + +Endatai il num dal software. + +field::[rows=1] + +=== Persuna da contact e controlla + +Numnai l'organisaziun, la persuna da contact dal post spezialisà sco er las persunas responsablas (p.ex. ISBO/DSBO) che han verifitgà l'observaziun da las prescripziuns da publicaziun. + +field::[rows=3] + +=== Nums dals repositoris ed autorisaziuns dals sviluppaders + +Inditgai ils nums da repositori planisads dal software da publitgar sco er la plattafurma da publicaziun tschernida.footnote:[In repositori sut l'organisaziun GitHub da la Chanzlia federala (http://github.com/swiss) po vegnir dumandà tar opensource@bk.admin.ch.] + +field::[rows=3] + +Inditgai, tgi (num d'utilisader GitHub, num, post, funcziun) che lavura al repositori. Sche quel sa chatta en in repositori d'in uffizi, sto vegnir inditgà, tgi che ha autorisà la persuna. Questa persuna è lura era responsabla per la soluziun, sche l'emprima persuna banduna l'organisaziun u mida ses post. I duess ultra da quai vegnir inditgà, sche las persunas agischeschan sco persunas privatas u sco part da l'uffizi. Numnai il conto d'utilisader GitHub al qual duai vegnir attribuì il rol d'administratur dal repositori. I pon dar plirs administraturs. + +field::[rows=4] + +== Glista da controlla + +La glista da controlla sto vegnir emplenida avant la publicaziun propria. + +[%interactive] +* [ ] La «glista da controlla Em002-2.1 Evaluaziun preliminara OSS» è vegnida emplenida e i n'èn vegnids constatads nagins puncts problematics. + +[%interactive] +* [ ] La «glista da controlla Em002-2.2 Analisa e preparaziun OSS» è vegnida emplenida e i n'èn vegnids constatads nagins puncts problematics. + +[%interactive] +* [ ] La licenza è vegnida tschernida. + +Licenza tschernida e motivaziun + +field::[rows=2] + +[%interactive] +* [ ] Il concept ISDS è vegnì elavurà. + +Las controllas relevantas èn vegnidas fatgas. Renviai als documents ed a las controllas. I è fixà, co ch'i vegn tractà cun annunzias da terzas persunas relevantas per la segirezza. + +Eventualmain è il software suttamess ad in program da bug bounty. + +I pon ultra da quai dar controllas OSS en ils repositoris. + +La configuraziun correspundenta è descritta e la persuna responsabla è numnada. + +field::[rows=1] + +[%interactive] +* [ ] Communitad e support èn reglads (via la «glista da controlla Em002-4.1 Communitad OSS») + +La glista da controlla è agiuntada. Ils puncts ils pli impurtants èn inditgads qua. + +field::[rows=1] + +[%interactive] +* [ ] L'extensiun e la moda dal support èn vegnidas scleridas. + +Indicaziun, co che quai è vegnì reglà. + +field::[rows=1] + +[%interactive] +* [ ] Per la publicaziun è vegnida creada ina *publiccode.yml*. + +Il standard da metadatas https://yml.publiccode.tools/ descriva il software. Il format fixà renda la publicaziun pli facil da chattar e da reutilisar. + +Quella sto vegnir archivada en l'ordinatur principal dal repositori. + +Sch'in nov repositori u ina nova organisaziun vegn creà, po quai vegnir annunzià via opensource@bk.admin.ch per l'admissiun en il catalog OSS. + +[%interactive] +* [ ] Responsabladads transferidas + +Indicaziun, sche la responsabladad per la relaschada è vegnida transferida a terzas persunas (furnitur, support, associaziun) tar l'acquist u pli tard. + +field::[rows=2] + +[%interactive] +* [ ] Glisch verda per l'open sourcing da vart dals responsabels da l'applicaziun e dal budget + +Nums e data + +field::[rows=2] + +== Remartgas finalas + +Remartgas e renviaments ad ulteriurs documents relevants + +field::[rows=4] + +*Archivaziun dal formular* + +Archivai quest formular tar la documentaziun dal project e/u tenor las prescripziuns da Vossa autoritad (unitad d'organisaziun). + +*Licenza dal model da la glista da controlla: CC0 1.0 Universal* + +Quest document vegn publitgà sut la https://creativecommons.org/publicdomain/zero/1.0/[_licenza CC0_]. El dastga vegnir utilisà, midà e derasà liberamain, era per intents commerzials ed en mintga format. +endif::[] diff --git a/docs/em002-2.adoc b/docs/em002-2.adoc new file mode 100644 index 0000000..404d142 --- /dev/null +++ b/docs/em002-2.adoc @@ -0,0 +1,3620 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-2 Instructions for Publishing OSS +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-2 Anleitung zur Veröffentlichung von OSS +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-2 Instructions pour la publication d'OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-2 Istruzioni per la pubblicazione di OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-2 Instrucziuns per publitgar OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +*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 {url-repo}/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. + +[mermaid,align="center",alt="Overview of the OSS publication process"] +.... +flowchart TD + S(["Start"]) + A["Preliminary assessment"] + B["Analysis and preparation"] + C["Publication"] + S --> A + A --> B + B --> C +.... + +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.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. + +The following diagram describes the instructions and different characteristics. + +[mermaid,align="center",alt="Decision tree for software release"] +.... +flowchart TD + Start(["Start
developed from 1.1.2024"]) + subgraph B1["1. Preliminary assessment"] + T{"Type of software"} + end + subgraph B2["2. Analysis and preparation"] + I{"Are third parties
interested in the software?"} + GJ["Clarify governance and
collaboration [Em002-4.1]"] + GT["Clarify governance and
collaboration [Em002-4.1]"] + O{"Open source software
development?"} + end + subgraph B3["3. Publication"] + M["Perform minimal release"] + P["Publication of the software"] + D["Open source software
development"] + C["Building and maintaining
a community [Em002-4]"] + end + Start --> T + T -->|"In-house development"| I + T -->|"Joint development"| GJ + T -->|"Third-party project"| GT + I -->|"No"| M + I -->|"Yes, or conceivable"| O + GJ --> O + GT --> D + O -->|"No"| P + O -->|"Yes"| D + P --> C + D --> C + M --> E1(["End"]) + C --> E2(["End"]) +.... + +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.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 + +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.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software] and the documents ++[++KBB-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.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.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. + +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.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.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? + +=== 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, ++[++KBB-MB++]++ contains important information. + +*Procedure* + +[mermaid,align="center",alt="Process for handling third-party rights exceptions"] +.... +flowchart TD + S(["Start"]) + Q1{"Purchase of a licence or of an
existing solution as a central
procurement item?"} + Q2{"Further developments
definable?"} + Q3{"Do the rights belong
to the Confederation?"} + Q4{"Is the acquisition of
third-party rights necessary?"} + Q5{"Can a part with rights held by the
Confederation be demarcated
in a targeted manner?"} + R1["Reasonable exception:
third-party rights"] + R2["Partial release by
the Confederation"] + R3["Release by the Confederation"] + S --> Q1 + Q1 -->|"No"| Q3 + Q1 -->|"Yes"| Q2 + Q2 -->|"Yes"| Q3 + Q2 -->|"No"| R1 + Q3 -->|"Yes"| R3 + Q3 -->|"No"| Q4 + Q4 -->|"Yes"| R3 + Q4 -->|"No"| Q5 + Q5 -->|"Yes"| R2 + Q5 -->|"No"| R1 +.... + +Figure 2 - Exception: Third-party rights (always also take into account ++[++KBB-MB++]++ and link:em002-7.pdf[Em002-7 Strategic Aspects of Procurement and Open Source Software]) + +A reasonable exception for third-party rights arises not only from the procurement of licences or existing software, but also from software development on existing, licensed software. + +A partial release is possible in the following constellation: the software contains proprietary or protected parts; those parts can be differentiated from further development; other intellectual property is involved. + +*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.pdf[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:* + +[NOTE] +==== +It is always the software that is relevant and not the purpose of the software. The processing of critical data is not a priori a security-relevant aspect. +==== + +[mermaid,align="center",alt="Process for handling security-relevant reasons exceptions"] +.... +flowchart TD + S(["Start"]) + Q1{"Security-relevant
grounds?"} + Q2{"Can the security-relevant
software be decoupled?"} + Q3{"Temporary grounds?"} + M["Publication measures"] + R1["Release part of
the software"] + R2["Exception:
security-relevant grounds"] + R3["Temporary exception"] + R4["Release"] + S --> Q1 + Q1 -->|"One or more points apply"| Q2 + Q1 -->|"Not applicable"| Q3 + Q2 -->|"Yes"| R1 + Q2 -->|"No"| R2 + Q3 -->|"One or more points apply"| R3 + Q3 -->|"No temporary grounds"| M + M --> R4 +.... + +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.pdf[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.pdf[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.pdf[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.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. + +*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.pdf[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.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. +|=== + +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.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. + +=== 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.pdf[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.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.pdf[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 Project 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.pdf[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.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. + +* 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.com/Fyrd/caniuse] 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/] +endif::[] + +ifeval::["{lang}" == "de"] +*Haftungsausschluss:* Dieses Dokument ist ein laufend weiterentwickelter Entwurf und Teil der Hilfsmittel, welche die Bundesverwaltung bei der Veröffentlichung von Open-Source-Code unterstützen.footnote:[Empfehlung für die Informatik der Bundesverwaltung gemäss ++[++P035++]++ _Kapitel 4.6_]footnote:[Zu den Definitionen der Klassifizierungen INTERN und VERTRAULICH siehe die _Verordnung vom 8. November 2023 über die Informationssicherheit bei Bund und Armee (ISV; SR 128.1)_]footnote:[Siehe Fussnote 1]footnote:[Planungsbereiche gemäss der _IKT-Strategie des Bundes 2020–2023 vom 3. April 2020 (SB000)_] Weitere Informationen finden Sie im {url-repo}/tree/main[README]. + +''''' + +== Management Summary + +Diese Anleitung beschreibt das Vorgehen für die Offenlegung von Quellcode von Software, die Bundesbehörden zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen, gemäss Art. 9 EMBAG.footnote:[Bundesgesetz _++[++EMOTA2023++]++_] Ausnahmen bestehen, wenn Rechte Dritter oder sicherheitsrelevante Gründe die Offenlegung ausschliessen oder einschränken. Veröffentlichung bedeutet, dass alle die Software nutzen, weiterentwickeln und verbreiten dürfen. Es werden keine Lizenzgebühren erhoben. + +Diese Anleitung richtet sich an Personen, die für die Veröffentlichung von Quellcode verantwortlich sind und diese umsetzen. + +[mermaid,align="center",alt="Übersicht über den OSS-Veröffentlichungsprozess"] +.... +flowchart TD + S(["Start"]) + A["Vorabklärung"] + B["Analyse und Vorbereitung"] + C["Veröffentlichung"] + S --> A + A --> B + B --> C +.... + +Der Gegenstand gliedert sich in drei Hauptteile: + +* Der erste Teil (Kapitel 3) behandelt die *Vorabklärungen* und die Ausnahmen nach EMBAG. +* Der zweite Teil (Kapitel 4), *Analyse und Vorbereitung*, untersucht den Quellcode und bereitet ihn nach Bedarf auf. Zudem wird die Lizenzwahl getroffen. +* Der dritte Teil (Kapitel 5), *Veröffentlichung und Bekanntmachung*, beschreibt die eigentliche Veröffentlichung und weitere Massnahmen wie Kommunikation und Aufbau einer geeigneten Community. + +*Drei Checklisten* begleiten und dokumentieren den Prozess. + +Technische Ergänzungen sind im Anhang aufgeführt. + +== Einleitung + +Bei der Freigabe von Open-Source-Software ist zu unterscheiden zwischen dem *Beitragen von Quellcode und Dokumentation zu bestehender Open-Source-Software* und der *Veröffentlichung als eigenständiges Open-Source-Projekt*. + +Ersteres umfasst typischerweise Fehlerbehebungen und Funktionserweiterungen. Je nach Lizenztyp und Softwareeinsatz muss oder kann der Quellcode unter der bestehenden Lizenz des Open-Source-Projekts freigegeben werden. Möglicherweise ist eine Freigabevereinbarung einzuhalten. + +Im zweiten Fall, dem Start eines neuen Open-Source-Projekts, können Governance und Lizenz grundsätzlich frei gewählt werden. Zu berücksichtigen ist einzig die Lizenz, unter der allfällige in das neue Projekt integrierte Softwareelemente veröffentlicht sind. Weitere Einzelheiten zur Lizenzwahl finden sich im Dokument link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung]. Lässt sich für die Bundesverwaltung aus einer Community ein Mehrwert erzielen oder will die Bundesverwaltung ein Ökosystem schaffen, so ist zusätzlich die link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] gemäss link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] auszufüllen. + +Die Freigabe von Open-Source-Software ist mehr als eine rein technische Massnahme. Sie bedeutet auch, eine entsprechend offene Kultur zu etablieren und die Menschen mitzunehmen. Eine erfolgreiche Open-Source-Kultur ist eine Mischung aus Offenheit, technischer Exzellenz, starker sozialer Interaktion und gemeinsamem Engagement. + +Die folgende Grafik beschreibt die Anleitung und die verschiedenen Ausprägungen. + +[mermaid,align="center",alt="Entscheidungsbaum für die Softwarefreigabe"] +.... +flowchart TD + Start(["Start
entwickelt ab 1.1.2024"]) + subgraph B1["1. Vorabklärung"] + T{"Art der Software"} + end + subgraph B2["2. Analyse und Vorbereitung"] + I{"Besteht Interesse
Dritter an der Software?"} + GJ["Governance und Zusammenarbeit
klären [Em002-4.1]"] + GT["Governance und Zusammenarbeit
klären [Em002-4.1]"] + O{"Open-Source-
Softwareentwicklung?"} + end + subgraph B3["3. Veröffentlichung"] + M["Minimale Freigabe durchführen"] + P["Veröffentlichung der Software"] + D["Open-Source-
Softwareentwicklung"] + C["Community aufbauen
und pflegen [Em002-4]"] + end + Start --> T + T -->|"Eigenentwicklung"| I + T -->|"Gemeinsame Entwicklung"| GJ + T -->|"Drittprojekt"| GT + I -->|"Nein"| M + I -->|"Ja, oder denkbar"| O + GJ --> O + GT --> D + O -->|"Nein"| P + O -->|"Ja"| D + P --> C + D --> C + M --> E1(["Ende"]) + C --> E2(["Ende"]) +.... + +Abbildung 1 – Entscheidungsbaum für die Softwarefreigabe + +== Prozess der Vorabklärung + +*Ziel:* Die Vorteile und möglichen Folgen einer Veröffentlichung der Software verstehen. Entscheiden, ob die Software veröffentlicht werden kann und, falls ja, ob sich der Aufbau einer aktiven Community lohnt. Hinweis: Die link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] sollte möglichst früh im Projekt ausgefüllt werden, da dies die Art der Softwareentwicklung beeinflussen kann. + +=== Freigabe nach EMBAG + +Nach Art. 9 des Bundesgesetzes vom 17. März 2023 ++[++EMOTA2023++]++ über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) muss die Bundesverwaltung (konkret Art. 2 Abs. 1) den Quellcode von Software offenlegen, die sie zur Erfüllung ihrer Aufgaben entwickelt oder entwickeln lässt. Ausnahmen gelten, wenn Rechte Dritter oder sicherheitsrelevante Gründe dies ausschliessen oder einschränken. + +Für im Auftrag des Bundes erstellte Individualsoftware gelten grundsätzlich die Allgemeinen Geschäftsbedingungen des Bundes ++[++BBL-AGB++]++. Nach Ziffer 25.1 sehen diese vor, dass das Eigentum an Quellcode und Dokumentation an den Leistungsbezüger (den Bund) übergeht. Wurde die Software gemeinsam von mehreren Organisationen oder anderen Institutionen beschafft, so ist zu prüfen, wer die Rechte am Code hat. Beispielsweise kann das Eigentum bei einem zu diesem Zweck gegründeten Verein liegen. + +Die blosse Nutzung von Standardsoftware fällt nicht unter Art. 9 EMBAG, und eine Freigabe wäre in der Regel ohnehin nicht möglich, da die Rechte an Standardsoftware häufig beim Anbieter verbleiben (AGB Bund für die Beschaffung von Standardsoftware). Individuelle Erweiterungen von Standardsoftware eignen sich hingegen durchaus für eine Veröffentlichung. Normalerweise stehen diese im Eigentum des Bundes. Reine Konfigurationsanpassungen eignen sich weniger für eine Veröffentlichung. Das Thema wird in link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software] sowie in den Dokumenten ++[++KBB-MB++]++ und ++[++BBL-WL++]++ behandelt. Grundsätzlich unterstehen Erweiterungen stets Art. 9 EMBAG. + +==== Software im Verhältnis zum EMBAG + +Die aktuelle Norm ISO/IEC 24765 enthält drei Definitionen für Software: + +. ein Programm oder eine Menge von Programmen zum Betrieb von Computern +. Programme und die zugehörige Dokumentation +. Programme und, sofern zutreffend, zugehörige Dokumentation sowie weitere für den Computerbetrieb notwendige Daten. + +Auf Basis dieser Definition gelten auch kleinere Skripte, Makros oder Infrastructure as Code (IaC) als Software. Das EMBAG bezieht sich in Artikel 9 Absatz 1 auf den Quellcode. Nach dieser Auslegung würde eine Veröffentlichung nach Definition 1 genügen. Eine Veröffentlichung ohne zugehörige Dokumentation ist jedoch von geringem Wert, da die Software nach Definition 2 nicht genutzt werden kann. + +Um Synergien mit Dritten zu erzielen, ist Definition 3 zugrunde zu legen. Bezüglich Daten bedeutet dies konkret Stammdaten und Grundkonfigurationen (beispielsweise Aufzählungswerte und Grunddaten, die ebenfalls als Open Source verfügbar gemacht werden sollten). + +Kleinere Projekte, Skripte oder Codebeispiele können auch gemeinsam in einem Repository veröffentlicht werden, wenn die Bundesbehörde dies als sinnvoll erachtet. In diesem Fall können diese Anleitung und die entsprechenden Checklisten einmalig ausgefüllt werden. + +Bei der Entscheidung, was und wie veröffentlicht wird, sind Verhältnismässigkeit und Aufwand zu berücksichtigen. + +==== Art der Software + +Wie in Abbildung 1 dargestellt, wird zwischen Eigenentwicklung, gemeinsamer Entwicklung und Drittprojekten unterschieden. Jede Konstellation hat andere Auswirkungen. Unabhängig davon, wie die Software entwickelt wird, fällt sie unter Art. 9 EMBAG. + +Bei der Eigenentwicklung erstellt der Bund die Software selbst oder lässt sie entsprechend erstellen. Er wählt die Governance und behält die Rechte am Quellcode. + +Bei der gemeinsamen Entwicklung erstellt der Bund die Software zusammen mit anderen Organisationen. Governance und Rechte an der Software sind über die gewählte Organisationsform zu regeln. + +Trägt der Bund direkt zu Drittsoftware bei, so fällt auch dieser Quellcode unter Art. 9 EMBAG. Es ist sicherzustellen, dass dies im Interesse der Bundesbehörden geschieht, dass die Beteiligung den Projektanforderungen entspricht und dass sich die Bundesverwaltung an die Governance hält. + +Dies erfolgt anhand der link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] und der link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community]. + +==== Legacy-Code + +Bei alter Software (*Legacy-Software*) ist der nachträgliche Aufwand für eine Veröffentlichung höher, als wenn die Freigabe von Anfang an geplant war. Bei Legacy-Software lohnt sich dieser Aufwand nur, wenn eine potenzielle Nutzerin oder ein potenzieller Nutzer die Software einsetzen will. Unabhängig davon sollte die link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] ausgefüllt werden, um die massgebenden Entscheide zu dokumentieren. + +Anwendungen, mit deren Entwicklung Bundesbehörden am oder nach dem 1. Januar 2024 begonnen haben oder die im Auftrag des Bundes auf der Grundlage eines nach dem 1. Januar 2024 abgeschlossenen Vertrags entwickelt werden, gelten nicht als Legacy und unterstehen in jedem Fall der Veröffentlichungspflicht nach Art. 9 Abs. 1 EMBAG. + +Die Veröffentlichungspflicht nach EMBAG hängt nicht vom Nutzen für Dritte ab. + +==== Bibliotheken, Plug-ins und Add-ons + +In manchen Fällen handelt es sich bei der Software nicht um eine eigenständige Anwendung, sondern nur um Teile davon. Das EMBAG und die Verordnung definieren den Quellcode nicht näher. Die Anleitung gilt auch für entkoppelte Bibliotheken, Plug-ins und Add-ons; diese fallen unter das EMBAG. + +*Aufgaben:* + +* Informationen aus link:em002-5.pdf[Em002-5 Merkblatt OSS-Hilfsmittel] beschaffen. Dieses beschreibt sowohl allgemeine Informationen zu Open-Source-Software als auch spezifische Informationen zur Anwendung des EMBAG. +* Prüfen, ob die Voraussetzungen nach EMBAG erfüllt sind. +* Die link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] ausfüllen. In der Regel ist es sinnvoll, die Ansprechpersonen des Softwarelieferanten bzw. der Entwicklung direkt beizuziehen. +* Bei Bedarf die link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] ausfüllen. + +*Entscheid:* Muss die Software veröffentlicht werden und wie soll dies geschehen? + +=== Ausnahme: Rechte Dritter + +Auf eine Veröffentlichung ist zu verzichten, wenn dadurch Rechte Dritter verletzt würden. Wurde die Software von Bundesangestellten entwickelt, so stehen die Rechte der Arbeitgeberin zu.footnote:[Art. 332 OR i. V. m. Art. 6 Abs. 2 BPG] In Verträgen über Personalverleih und IT-Dienstleistungen werden die Rechte üblicherweise an den Bund übertragen und sollten geltend gemacht werden. + +Wurde oder wird die Software auf der Grundlage der Allgemeinen Geschäftsbedingungen des Bundes (Stand 2024) entwickelt,footnote:[Allgemeine Geschäftsbedingungen des Bundes, insbesondere Ziffer 25.1 – https://www.bkb.admin.ch/bkb/de/home/themen/agb.html#accordion_21321111141713247349255] so stehen die Immaterialgüterrechte dem Auftraggeber zu, sofern vertraglich nichts anderes vereinbart wurde. + +Eine Anwendung besteht typischerweise aus zahlreichen Einzelkomponenten und -teilen. Bei manchen Arten wird es problematisch, wenn diese selbst nicht Open Source sind oder nicht als Teil der Anwendung unter einer Open-Source-Lizenz veröffentlicht werden können. + +*Bibliotheken* + +Je nach Programmiersprache werden Bibliotheken entweder direkt mit der Anwendung kompiliert, gelinkt oder als Pakete ausgeliefert. Sie bilden einen integralen Bestandteil der Anwendung. + +Enthält die Anwendung proprietäre oder lizenzpflichtige Bibliotheken, so wird das Open Sourcing schwieriger. Grundsätzlich kann der Quellcode des übrigen Teils der Anwendung veröffentlicht werden, doch müssten potenzielle Nutzende oder Entwickelnde die betreffende Bibliothek erwerben, bevor die Anwendung nutzbar oder erweiterbar wird. + +Liegt das Eigentum an der problematischen Bibliothek beim Softwarelieferanten, so lohnt sich eine rechtliche Abklärung, ob der Bund übertragbare Rechte an diesen Bibliotheken hat. + +Wo möglich sollten proprietäre und lizenzpflichtige Bibliotheken bei Eigenentwicklungen vermieden oder vor der Freigabe nach Möglichkeit ersetzt werden. Mit Blick auf das Ziel von Artikel 9 EMBAG sollte möglichst viel von der öffentlichen Verwaltung genutzte Funktionalität veröffentlicht werden. Einzelne Bibliotheken, welche die Veröffentlichung des Codes verhindern, stellen daher technische Schulden dar, die dokumentiert und bei Gelegenheit beseitigt werden sollten. + +*Datenbanken und andere Datenspeicher* + +Nutzt die Anwendung proprietäre, lizenzpflichtige Datenspeicher wie Microsoft SQL Server, so steht dies einer Open-Source-Veröffentlichung nicht entgegen. + +Es sollte jedoch geprüft werden, ob zusätzlich offene Datenbanken wie PostgreSQL unterstützt werden können. Dies kann Betriebskosten sparen und die Einstiegshürden für potenzielle Nutzende senken. + +*Applikationsserver und Betriebssysteme* + +Benötigt die Anwendung lizenzierte Betriebssysteme oder Applikationsserver (z. B. Microsoft Windows Server oder RedHat JBoss), so steht dies einer Open-Source-Veröffentlichung nicht entgegen. + +Wir empfehlen, beim Softwareanbieter nachzufragen, ob und gegebenenfalls welche lizenzierten Drittbibliotheken als Komponenten der Anwendung verwendet werden. + +Wurde die Softwareerstellung gemeinsam von mehreren Organisationen oder anderen Institutionen beschafft, so liegt das Eigentum in der Regel bei einem zu diesem Zweck gegründeten Verein oder einer anderen juristischen Person. + +*Weiteres geistiges Eigentum* + +Zu den Rechten Dritter zählen nicht nur Urheberrechte, sondern auch weiteres geistiges Eigentum (Marken, Patente). Patente verhindern grundsätzlich nicht, dass Software als Open Source veröffentlicht wird, können aber deren Nutzung oder Erweiterung verhindern. Patente sind in der Schweiz zwar eher unüblich, doch lohnt sich in der Regel eine kurze Nachfrage beim Softwareanbieter, ob bereits eine Prüfung stattgefunden hat. + +*Erwerb der erforderlichen Rechte* + +Um die gesetzlichen Vorgaben des EMBAG zu erfüllen, hat die Bundesbehörde als Auftraggeberin die Möglichkeit, sich die Rechte an den Arbeitsergebnissen zu sichern. Diese Voraussetzung für eine Veröffentlichung kann bei der Beschaffung als Kriterium festgelegt werden. Der nachträgliche Erwerb notwendiger Rechte an der Software kann aufwendiger werden. + +Will die Bundesbehörde die Software nicht selbst veröffentlichen, so kann sie diese Aufgabe beispielsweise an den Auftragnehmer delegieren oder die Veröffentlichungsrechte entsprechend übertragen. In diesem Fall überträgt sie die notwendigen Rechte (und Pflichten) an den Lieferanten und/oder Dritte und beauftragt sie mit der Veröffentlichung. Damit wird das Recht faktisch unter der Bedingung der Freigabe bzw. des Supports der entsprechenden Software an Dritte übertragen. + +Auch hier enthält ++[++KBB-MB++]++ wichtige Hinweise. + +*Vorgehen* + +[mermaid,align="center",alt="Prozess für den Umgang mit der Ausnahme Rechte Dritter"] +.... +flowchart TD + S(["Start"]) + Q1{"Beschaffung einer Lizenz oder
einer bestehenden Lösung als
zentraler Beschaffungsgegenstand?"} + Q2{"Weiterentwicklungen
definierbar?"} + Q3{"Liegen die Rechte
beim Bund?"} + Q4{"Ist der Erwerb von Rechten
Dritter notwendig?"} + Q5{"Kann ein Teil mit Rechten beim
Bund gezielt abgegrenzt werden?"} + R1["Begründete Ausnahme:
Rechte Dritter"] + R2["Teilweise Freigabe
durch den Bund"] + R3["Freigabe durch den Bund"] + S --> Q1 + Q1 -->|"Nein"| Q3 + Q1 -->|"Ja"| Q2 + Q2 -->|"Ja"| Q3 + Q2 -->|"Nein"| R1 + Q3 -->|"Ja"| R3 + Q3 -->|"Nein"| Q4 + Q4 -->|"Ja"| R3 + Q4 -->|"Nein"| Q5 + Q5 -->|"Ja"| R2 + Q5 -->|"Nein"| R1 +.... + +Abbildung 2 – Ausnahme: Rechte Dritter (stets auch ++[++KBB-MB++]++ und link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software] berücksichtigen) + +Eine begründete Ausnahme wegen Rechten Dritter ergibt sich nicht nur aus der Beschaffung von Lizenzen oder bestehender Software, sondern auch aus der Softwareentwicklung auf bestehender, lizenzierter Software. + +Eine teilweise Freigabe ist in folgender Konstellation möglich: Die Software enthält proprietäre oder geschützte Teile; diese lassen sich von der Weiterentwicklung abgrenzen; es ist anderes geistiges Eigentum betroffen. + +*Aufgaben:* + +* Prüfen, ob die Organisation die massgebenden Schutzrechte an der Software besitzt. +* Prüfen, ob die Rechte erworben werden können. +* Nötigenfalls die schriftliche Erlaubnis der Rechteinhaber einholen. +* Sicherstellen, dass die Anwendung keine proprietären oder geschützten Teile enthält. +* Prüfen, dass keine Hindernisse aufgrund von Patentschutz bestehen (soweit möglich und zumutbar). +* Prüfen, ob die Freigabe durch Dritte erfolgen soll. +* Prüfen, ob die Entwicklung auf Open-Source-Softwareentwicklung beruhen soll (anhand des link:em002-4.pdf[Em002-4 Leitfadens OSS-Community]). + +*Entscheid:* Kann die Software veröffentlicht werden, ohne Rechte Dritter zu verletzen? + +=== Ausnahme: Sicherheitsrelevante Gründe + +Software, die aus sicherheitsrelevanten Gründen nicht veröffentlicht werden kann, ist von der Veröffentlichung ausgenommen. + +Die eigentlichen Daten einer Software sind von der Veröffentlichung des Quellcodes nicht betroffen. Diese Daten sind in der Regel sensibel und werden nicht veröffentlicht. Es kann jedoch sein, dass neben den Inhaltsdaten bestimmte im Quellcode sichtbare Algorithmen und Verfahren nicht öffentlich werden sollen (z. B. offensive Cyberfähigkeiten, Einzelheiten der Betrugserkennung). Sicherheit kann sich auf Vertraulichkeit, Integrität, Verfügbarkeit oder Nachvollziehbarkeit beziehen. + +*Empfehlung:* + +Software sollte bewusst so entwickelt werden, dass auch bei einer Veröffentlichung des Quellcodes kein zusätzliches Risiko entsteht. Die Annahme, eine Nichtveröffentlichung schütze vor erfolgreichen Angriffen, ist trügerisch («security through obscurity»). + +*Vorgehen:* + +[NOTE] +==== +Massgebend ist stets die Software und nicht der Zweck der Software. Die Bearbeitung kritischer Daten ist nicht a priori ein sicherheitsrelevanter Aspekt. +==== + +[mermaid,align="center",alt="Prozess für den Umgang mit der Ausnahme sicherheitsrelevante Gründe"] +.... +flowchart TD + S(["Start"]) + Q1{"Sicherheitsrelevante
Gründe?"} + Q2{"Kann die sicherheitsrelevante
Software entkoppelt werden?"} + Q3{"Vorübergehende Gründe?"} + M["Massnahmen für
die Veröffentlichung"] + R1["Teil der Software
freigeben"] + R2["Ausnahme:
sicherheitsrelevante Gründe"] + R3["Vorübergehende Ausnahme"] + R4["Freigeben"] + S --> Q1 + Q1 -->|"Ein oder mehrere Punkte treffen zu"| Q2 + Q1 -->|"Nicht zutreffend"| Q3 + Q2 -->|"Ja"| R1 + Q2 -->|"Nein"| R2 + Q3 -->|"Ein oder mehrere Punkte treffen zu"| R3 + Q3 -->|"Keine vorübergehenden Gründe"| M + M --> R4 +.... + +Abbildung 3 – Ausnahme: Sicherheitsrelevante Gründe + +Folgende Gründe können je Projekt als sicherheitsrelevant gelten: + +* Die Veröffentlichung der Software würde ein Informationssicherheitsrisiko wesentlich erhöhen.footnote:[Informationssicherheitsgesetz, ISG. Art. 6 Informationssicherheit. https://www.fedlex.admin.ch/eli/cc/2022/232/de#art_6] +* Bei Algorithmen zur Betrugsprävention und ähnlichen Algorithmen kann gegebenenfalls auf eine Veröffentlichung verzichtet werden. +* Besonders sensible Cybersicherheitstechnologien. +* Kernsoftware für den Betrieb kritischer Infrastrukturen. +* Wenn die Veröffentlichung andere Rechtsgrundlagen verletzen würde. + +Die folgenden vorübergehenden Gründe können eine Veröffentlichung noch verhindern. Eine Veröffentlichung wird jedoch später durch geeignete Massnahmen ermöglicht. + +* Legacy-Code konnte noch nicht bereinigt werden und enthält möglicherweise sicherheitsrelevante Probleme. +* Sicherheitsaudits des Codes wurden noch nicht durchgeführt. +* Der Entwicklungsprozess ist noch nicht reif genug für eine sichere Veröffentlichung. Ist der Entwicklungsprozess nicht ausreichend etabliert, so besteht die Möglichkeit, dass Teile veröffentlicht werden, die nicht für Dritte bestimmt sind. Beispielsweise müssen Richtlinien zur Codekommentierung und die Erzeugung von Testdaten an das neue Veröffentlichungsszenario angepasst werden und zuverlässig funktionieren. + +Durch folgende Massnahmen kann Software trotz sicherheitsrelevanter Gründe veröffentlicht werden: + +* Konfigurationen (z. B. Art der verwendeten Verschlüsselung) von der Software trennen. +* Fachlich sensible, nicht öffentliche Informationen (z. B. Abläufe, Berechnungen) in Konfigurationen oder Einstellungen auslagern. +* Geeignete organisatorische, personelle und technische Massnahmen planen, umsetzen und regelmässig üben. +* Geeignete Qualitätsaktivitäten bei der Veröffentlichung planen und durchführen. Siehe folgendes Kapitel «Analyse und Vorbereitung». + +*Aufgaben:* + +* Die Software auf sicherheitsrelevante Gründe prüfen, die einer Veröffentlichung entgegenstehen. +* Den Aufwand für die Behebung vorübergehender Gründe abschätzen. +* Massnahmen planen, um sicherheitsrelevante Informationen vom Quellcode der Software zu trennen. +* Sicherstellen, dass die Anwendung keine Verfahren enthält, die nicht öffentlich werden dürfen. + +*Entscheid:* + +Bestehen zwingende sicherheitsrelevante Gründe, die eine Veröffentlichung verunmöglichen? + +=== Klärung der Veröffentlichung + +In diesem Schritt wird geklärt, wer die Software veröffentlicht. Wurde die Software von einem externen Anbieter erstellt, so kann die Veröffentlichung auch diesem Anbieter übertragen werden. In diesem Schritt ist zu bestimmen, wo der Quellcode veröffentlicht wird, und eine entsprechende Governance festzulegen. + +Wurde die Software bundesintern entwickelt und kann oder will der Bund sie nicht selbst veröffentlichen, so kann ein Veröffentlichungsauftrag an einen Lieferanten erteilt oder können die Rechte abgetreten werden (Übertragung der Pflichten an Dritte). + +*Minimale Freigabe und Support* + +Das EMBAG macht keine Vorgaben zur Veröffentlichung. Eine minimale Freigabe des Quellcodes erfüllt die gesetzliche Vorgabe. Weitere Aktivitäten sind nicht erforderlich. Die Frage, ob und in welchem Umfang Support angeboten wird und wie aktiv das Projekt gepflegt wird, lässt sich anhand des link:em002-4.pdf[Em002-4 Leitfadens OSS-Community] beantworten. + +*Open-Source-Softwareentwicklung (OSSD)* + +Bei der Open-Source-Softwareentwicklung (OSSD) wird zusätzlich zur Veröffentlichung des Quellcodes der gesamte Entwicklungsprozess öffentlich durchgeführt. Alles von den Anforderungen (Issues) bis zum Quellcode ist transparent. OSSD wird unterstützt durch öffentliche Kommunikationswerkzeuge (Mailinglisten, Foren usw.), ein Versionsverwaltungssystem (Git), Fehler- und Funktionslisten, eine Roadmap und Entwicklerwerkzeuge. Durch diese transparente Arbeitsweise profitiert die gesamte Community und die Zusammenarbeit über Organisationsgrenzen hinweg wird ermöglicht. Bei diesem Ansatz ist bei Projektabschluss keine weitere Veröffentlichungsaktivität nötig, da dies bereits zu Projektbeginn berücksichtigt wurde. + +*Aufgaben* + +* Eine grobe Aufwandschätzung für die Analysephase erstellen. Je nach Grösse und Komplexität der Anwendung liegt der Aufwand zwischen drei Tagen und zwei Wochen. +* Ressourcen für weitere Schritte, insbesondere für die Analyse, freigeben. +* Grundsätzlich zustimmen, die Anwendung als Open Source zu veröffentlichen. + +*Entscheid:* + +Grundsätzliches Einverständnis und Machbarkeit für die Veröffentlichung der Anwendung als Open Source sind gegeben. + +=== Aufwand minimieren + +Die Checklisten und die Anleitung sind so aufgebaut, dass der Aufwand für Freigaben möglichst gering bleibt. Eine konsequente vorausschauende Planung der Freigabe zu Projektbeginn und eine auf die Freigabe ausgerichtete Entwicklung minimieren den Aufwand. Ein gewisser administrativer Aufwand und gewisse Kosten fallen zwangsläufig an ++[++Le2023++]++. Diese lassen sich unter Umständen über Communities mit geteilten Entwicklungskosten zurückgewinnen (siehe link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]). + +=== Wahl der Veröffentlichungssprache + +Bei der Sprachwahl sind sowohl das potenzielle Zielpublikum als auch die Arbeitsweise des Teams zu berücksichtigen. Erfreulicherweise sind Übersetzungen mit neuen Werkzeugen deutlich einfacher geworden. Als Optionen kommen die Amtssprachen des Bundesfootnote:[https://www.fedlex.admin.ch/eli/cc/1999/404/de#art_70] und Englisch in Frage. + +Ist das Projekt international relevant, so sollte Englisch die Zielsprache sein. Für eine nachträgliche Veröffentlichung ist ein Sprachwechsel naturgemäss wenig sinnvoll. + +Mindestens die README.md sollte in mehreren Sprachen vorliegen, damit Interessierte sofort erkennen, ob das Projekt für sie relevant ist. + +Die öffentliche Kommunikation sollte in erster Linie das Zielpublikum berücksichtigen. Zu beachten ist zudem, dass es sich um öffentliche Kommunikation des Bundes handelt. + +*Hinweis*: Mit der Veröffentlichung betritt die Bundesverwaltung einen neuen Kanal der öffentlichen Kommunikation. Geschieht dies nicht sorgfältig und professionell, so kann das öffentliche Ansehen des Bundes rasch leiden. + +== Analyse und Vorbereitung + +*Ziel:* Die für eine Open-Source-Veröffentlichung erforderlichen Arbeiten sind abgeschlossen. Die Entscheide zu Lizenz und Art der Community sind gefällt. Dies erfolgt anhand der link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung]. + +=== Quellcodeanalyse + +Der zu veröffentlichende Quellcode und weitere zugehörige Dokumente werden vor der Veröffentlichung analysiert. Diese Analyse stellt sicher, dass keine vertraulichen Informationen veröffentlicht werden. + +Ist umfangreicher Quellcode zur Veröffentlichung vorgesehen, so empfiehlt sich der Einsatz geeigneter automatisierter Werkzeuge für die folgenden Tätigkeiten. + +Die Einzelheiten sind in Abschnitt E festgelegt. + +*Aufgaben* + +* Prüfen, wie die bestehende Codequalität und die Richtlinien umgesetzt wurden (z. B. ISO/IEC 25010:2023footnote:[ISO/IEC 25010:2023 – Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.iso.org/standard/78176.html]). +* Sicherstellen, dass keine sensiblen (Test-)Daten enthalten sind, z. B. Daten, die auf realen Personen oder Fällen beruhen. +* Die Softwaredokumentation aktualisieren (siehe Anhang). +* Unnötige Dateien oder veraltete Dokumente und Daten löschen. +* Den Quellcode auf Secrets/Zugangsdaten prüfen.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/aktuell/im-fokus/2022/git.html] +* Gezielte Sicherheitstests durchführen und anschliessend ein (öffentliches) Bug-Bounty-Programm einrichten.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Alle verwendeten Bibliotheken bezüglich Lizenzen prüfen und die entsprechenden Listen (Attributionen) erstellen. Ist eine Bibliothek unter mehreren Lizenzen verfügbar, so ist dies in den Listen entsprechend anzugeben. +* Das Deployment beschreiben (CI/CD-Pipeline) und allenfalls eine Demo-Instanz einrichten. + +Diese Tätigkeiten sind unabhängig von der Veröffentlichung, bilden jedoch Voraussetzungen für eine gute Softwarequalität und die Sicherstellung der Compliance. Die Beachtung dieser Massnahmen vereinfacht die Zusammenarbeit, erhöht die Qualität externer Beiträge und verbessert das Image der Software bzw. der Behörde. + +=== Lizenzwahl + +*Siehe link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung].* + +International etablierte Lizenztexte sollten verwendet werden, wo dies möglich und sinnvoll ist. Haftungsansprüche von Lizenznehmern sind so weit rechtlich möglich auszuschliessen. + +*Aufgaben* + +* Allfällige Abhängigkeiten von bestehenden Lizenzen prüfen. +* Bei Drittcode die Nutzungsbedingungen auf Kompatibilität mit der vorgesehenen Lizenz prüfen und den Code nötigenfalls ersetzen.footnote:[Siehe Em002-3 zur Auswahl von Drittcode bzw. Bibliotheken für einen Technologie-Stack und zur Kompatibilität der Lizenz.] +* Die geeignete Lizenz auswählen. + +Die Lizenzkompatibilität lässt sich mit Werkzeugen wie ORT Toolkit,footnote:[https://oss-review-toolkit.org/] Black Duck,footnote:[https://www.blackducksoftware.com] FOSSAfootnote:[https://www.fossa.com] oder FOSSologyfootnote:[https://www.fossology.org] prüfen. Die ToDo Group footnote:[https://landscape.todogroup.org/] bietet eine aktuelle Übersicht über Werkzeuge. + +*Entscheid:* + +* Festlegen und dokumentieren, unter welcher Lizenz die Software veröffentlicht wird. + +=== Open-Source-Dokumentation + +Mit der Veröffentlichung wird ein Mindestmass an Dokumentation erwartet. Im Open-Source-Ökosystem haben sich mehrere Dokumente etabliert. Diese geben Besuchenden rasch Einblick in die Software einschliesslich der Lizenzierung. + +Folgende Dokumente werden erwartet: + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Dokument* |*Beschreibung / Inhalt:* +|README(.md) |Dient als Einstiegsdokument und gibt einen raschen Überblick über Zweck, Umfang, Status, Lizenz und Zielgruppen des Projekts. +|LICENSE |Beschreibung der im Projekt gewählten Lizenz +|CONTRIBUTING(.md) |Beschreibt den Prozess, wie man zum Projekt beitragen kann. +|CODE++_++OF++_++CONDUCT(.md) |Der Code of Conduct legt die erwarteten sozialen Normen innerhalb des Projekts fest. +|CHANGELOG(.md) |Führt eine Liste der Änderungen in den Softwareversionen. +|THIRD-PARTY-LICENSES(.md) |Beschreibung der Drittlizenzen bzw. der verwendeten Komponenten. +|Getting started |Kurzanleitung zur Installation und Nutzung der Software. +|Create Gitignore |Beschreibt Dokumente, die nicht veröffentlicht werden, z. B. Konfigurationen, Testdaten oder generierte Inhalte. Geschützte und sensible Informationen sollten ausserhalb des Projekts in geeigneten, dafür vorgesehenen Werkzeugen und Speichern verwaltet werden. +|publiccode.yml |Strukturierte Metadaten zur Beschreibung der Software auf Basis des Standards https://yml.publiccode.tools/. Das festgelegte Format macht die Veröffentlichung besser auffindbar und wiederverwendbar. Weitere Informationen in Anhang F. +|=== + +Tabelle 1 – Open-Source-Dokumente + +Weitere technische Einzelheiten zu diesen Dokumenten sind im Anhang beschrieben. + +*Aufgaben* + +* Standarddokumentation erstellen. +* Copyright, Lizenzhinweise und Haftungsausschluss in allen Dateien aufführen. +* Je nach Veröffentlichungsplattform können zusätzliche Beschreibungen erstellt werden. + +*Entscheid:* + +* Definitiver Entscheid, die Anwendung als Open Source zu veröffentlichen. + +== Veröffentlichung und Bekanntmachung + +*Ziel:* Die Anwendung ist als Open Source veröffentlicht und für Dritte leicht auffindbar. Alle Komponenten sind für die Veröffentlichung bereit und die Community ist aufgebaut oder etabliert. Dies erfolgt anhand der link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung]. In gewissem Umfang werden dabei bereits gefällte Entscheide rekapituliert. + +=== Wahl der Plattform + +Es gibt mehrere Möglichkeiten, Quellcode zu veröffentlichen. Die folgende Tabelle gibt einen Überblick über mögliche Source-Code-Management-Systeme (SCM) und Plattformen. + +Die geeignete Plattform ist vor der eigentlichen Veröffentlichung auszuwählen. Einige Bundesbehörden sind bereits auf GitHub vertreten.footnote:[Die Website https://ossbenchmark.com gibt einen Überblick über Organisationen und Behörden, die auf GitHub aktiv sind.] In diesem Fall ist es sinnvoll, bereits etablierte Plattformen zu nutzen. + +*Empfehlung:* + +Wir empfehlen derzeit, für die Veröffentlichung von Quellcode pro Bundesbehörde eine Organisation auf GitHub einzurichten. Innerhalb dieser Organisation können entsprechende Projekte (Repositories) angelegt und Nutzende mit passenden Berechtigungen verwaltet werden. Künftig sollte eine zentrale Bundesplattform aufgebaut werden. Um eine optimale Benutzerverwaltung zu gewährleisten und das Ansehen der Schweizerischen Eidgenossenschaft zu wahren, ist es wichtig, weniger, dafür besser verwaltete Repositories zu nutzen. + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Plattform* |*Eigenschaften* +|GitHubfootnote:[https://github.com/about/] |Online-Plattform von Microsoft mit grosser Verbreitung. Eine grosse Menge an Open-Source-Software wird auf GitHub gehostet. Bietet neben SCM viele zusätzliche Werkzeuge. Verfügbar in einer Free- und einer Enterprise-Version (Subskription). +|GitLabfootnote:[https://about.gitlab.com/] |Online-Plattform des gleichnamigen Unternehmens GitLab, die selbst unter einer Open-Source-Lizenz veröffentlicht ist. Bietet neben SCM viele zusätzliche Werkzeuge. Kann auch lokal betrieben werden und bietet damit ein gewisses Mass an Souveränität. Verfügbar in einer Free- und einer Enterprise-Version (Subskription). +|Bitbucketfootnote:[https://bitbucket.org/product/en] |Online-Plattform von Atlassian, speziell in dessen Ökosystem integriert. Verfügbar in einer Free- und einer Enterprise-Version (Subskription). +|Internes SCM-System |Wird eine eigene SCM-Plattform bereitgestellt, so kann diese ebenfalls veröffentlichen und bestimmte Repos/Projekte verfügbar machen. Der Betrieb muss sichergestellt sein. +|Bundesplattform |Derzeit gibt es keine zentrale Bundesplattform für die Veröffentlichung von Software. Eine entsprechende Massnahme wird in link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] vorgeschlagen. +|Website, öffentlicher FTP-Server usw. |Das EMBAG legt nicht fest, wie Software zu veröffentlichen ist. Eine minimale Freigabefootnote:[Eine minimale Veröffentlichung umfasst nur die Veröffentlichung des Quellcodes und weiterer minimaler Artefakte. Diese Art der Veröffentlichung erfüllt die Vorgaben des EMBAG. Ein Mehrwert wird durch die Veröffentlichung jedoch nicht erzielt.] kann auch auf einer Website oder anderen öffentlich zugänglichen Ressourcen erfolgen. Für eine nachhaltige Zusammenarbeit im Sinne von Open Source ist dies jedoch nicht geeignet. +|=== + +Tabelle 2 – Plattformen für die Veröffentlichung von Open-Source-Software + +Wird die Software gemeinsam mit einem externen Partner oder einer externen Organisation veröffentlicht, so ist darauf zu achten, dass entsprechende Berechtigungen und Zugriffe auf den Quellcode vorhanden sind. + +*Aufgaben* + +* Geeignete Plattform einschliesslich entsprechender Organisation/Projekt evaluieren. +* Sofern noch nicht geklärt, die Benennung von Projekt/Repository festlegen. +* Berechtigungen am Repo festlegen und prüfen. +* Angemessene Governance und eine allfällige Replikation des Quellcodes sicherstellen. + +*Entscheid:* + +* Die Plattform für die Veröffentlichung wurde sachgerecht gewählt. + +=== Veröffentlichung der Software + +Sind die Voraussetzungen geklärt, so kann die Software veröffentlicht werden. + +*Aufgaben* + +* Die Voraussetzungen anhand der link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] prüfen. +* Der Zugang zur Plattform besteht und die Governance ist geklärt. +* Veröffentlichung von Quellcode und Dokumentation durch die Entwicklung. + +=== Kommunikation + +Nach der eigentlichen Veröffentlichung können durch und innerhalb der betroffenen Bundesbehörde weitere Kommunikationsaktivitäten angestossen werden. Diese unterstützen die Verbreitung und bringen den gewünschten Mehrwert aus der Veröffentlichung. + +*Aufgaben* + +* Beschreibung im Repo-Hosting, Sicherheitseinstellungen usw. +* Interne und gegebenenfalls externe Kommunikation +* Eine Mitteilung an die Community verfassen. +* Die Anwendung innerhalb der Organisation und in Fachgremien bekannt machen, deren Nutzung und Beiträge fördern. +* Eine publiccode.yml-Dateifootnote:[Der Metadatenstandard https://yml.publiccode.tools/ beschreibt die Software. Das festgelegte Format macht die Veröffentlichung besser auffindbar und wiederverwendbar. Weitere Informationen in Anhang F.] im Repository für den OSS-Katalog der Bundesverwaltung erstellen.footnote:[OSS-Katalog: https://www.opensource.admin.ch] + +=== Aufbau und Pflege der Community + +Bei der Veröffentlichung von Software kann eine Community entstehen, die durch Beiträge (Pull Requests), Fragen, Dokumentationsvorschläge usw. zur Software beitragen kann. Für eine aktive Community ist erheblicher Aufwand sowohl für den Aufbau als auch für die laufende Pflege erforderlich. Eine gut funktionierende Community minimiert unerwünschte Forks der Software. Ziel ist es, den Mehrwert der Community durch gezielte Aktivitäten zu aktivieren. Auch bei einer minimalen Veröffentlichung sollte der Umgang mit Rückmeldungen und Fragen zur Software festgelegt werden. + +*Aufgaben* + +* Klären, wer potenzielle Nutzende oder Interessierte sind. +* Die geeignete Form für die konkrete Anwendung anhand des link:em002-4.pdf[Em002-4 Leitfadens OSS-Community] bestimmen. +* Die Community aufbauen. +* Aktivitäten zum Community-Aufbau. + +== Anhang + +=== Änderungen gegenüber der Vorversion + +* Kapitel 4.3 und 5.3: Veröffentlichung mit publiccode.yml ergänzt +* Anhang F «Public Code» wurde ergänzt +* Verschiedene kleinere redaktionelle Änderungen und Verbesserungen + +=== Referenzen + +Siehe _Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung_. + +=== Abkürzungen + +Siehe link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] und link:em002-6.pdf[Em002-6 FAQ zu OSS]. + +=== Begleitdokumentation link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] – Dokumentation + +=== Quellcodedokumentation + +Die Dokumentation sollte Teil des Quellcodes des Projekts sein, damit Änderungen an der Dokumentation revisionssicher abgelegt werden und die Dokumentation parallel zum Projekt versioniert wird. Damit ist automatisch sichergestellt, dass die Dokumentation bei sachgerechter Pflege nicht vom Entwicklungsstand des Projekts abweicht und dass die Dokumentation zu älteren Versionen des Projekts jederzeit abgerufen werden kann. + +Zudem erhalten Dritte damit die Möglichkeit, auf einfache Weise Änderungen an der Dokumentation beizutragen. + +Als Auszeichnungssprache für die Textformatierung sollte Markdown verwendet werden, da es einfach zu schreiben, weit verbreitet und maschinenlesbar ist. Zudem werden Markdown-Dokumente von allen gängigen Plattformen in einem gut lesbaren Zielformat dargestellt. Markdown-Dokumente lassen sich unabhängig von der eingesetzten Plattform mit statischen Website-Generatoren wie beispielsweise Jekyll, MkDocs, Gatsby oder Sphinx in jedes Zielformat rendern, etwa mit den Corporate-Identity-Vorgaben einer Verwaltung. + +=== Adressaten und Aufbau der Dokumentation + +Die Projektdokumentation sollte sowohl Endnutzende als auch technische Fachpersonen ansprechen und sich somit nicht ausschliesslich auf die Technik konzentrieren. Zur Sprachwahl siehe Kapitel 3.6. Dies unterstützt die Verbreitung der Software. + +Eine Datei README.md dient als Einstiegsdokument. Dateien mit diesem Namen werden von allen gängigen Plattformen erkannt und als Einstiegspunkt in die Dokumentation angezeigt.footnote:[Weitere Informationen zum Erstellen einer Readme-Datei: https://www.makeareadme.com/] + +README.md sollte einen raschen Überblick über Zweck, Umfang, Status, Lizenz und Zielgruppen des Projekts geben. Konkret sollte README.md die folgenden Punkte enthalten: + +* Name der Software +* Kurzbeschreibung von Zweck und Funktion der Software. Umfang und mögliche Einschränkungen +* Installationsanleitung +* Nutzung der Software +* Hinweis auf eine allfällige Demo-Instanz +* Support- und Kontaktangaben +* Wie man zur Open-Source-Software beiträgt (Contributing) +* Verwendete Lizenz (Licence) +* Projektstatus / Entwicklungsstand + +=== Open Source hervorheben und Lizenz ablegen + +Direkt nach dem Leitbild sollte klar und unmissverständlich festgehalten werden, dass es sich beim Projekt um Open-Source-Software handelt. Die vom Projekt verwendete Lizenz sollte mit dem entsprechenden SPDX-Identifikatorfootnote:[SPDX-Identifikator – https://spdx.org/about] angegeben und mit dem konkreten Lizenztext in der Datei LICENSE verlinkt werden. Lizenzvorlagen enthalten typischerweise einen variablen Teil (z. B. Projektname, Copyright-Jahr, Name der Autorin oder des Autors), der in der Datei LICENSE anzupassen ist. + +Die meisten Plattformen erkennen Lizenzen in einer Datei LICENSE und bieten übersichtliche Informationen zur Lizenz, z. B. eine kurze Zusammenfassung der Lizenzbedingungen. + +Es wird empfohlen, jeder neu erstellten Quelldatei einen minimalen Lizenz- und Copyright-Header hinzuzufügen. Bestehende Header in bestehenden Dateien sollten nicht verändert werden. Wird zu einem Projekt beigetragen, das klare Vorgaben für Header hat, so sind diese einzuhalten. + +Weitere Einzelheiten siehe: Producing Open Source Software: State That the Project is Free.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Aktueller Entwicklungsstand + +Um den Zustand des Projekts rasch aufzuzeigen, sollte der aktuelle Entwicklungsstand in README.md dokumentiert werden. Für Lesende ist es wichtig zu wissen, ob sich das Projekt in einem reifen Zustand oder am Anfang der Entwicklung befindet, ob es aktiv gepflegt wird und wie häufig neue Versionen veröffentlicht werden. + +In diesem Abschnitt kann beschrieben werden, welche Art von Unterstützung durch Dritte für das Projekt derzeit am wichtigsten ist. Dies könnte beispielsweise eine Entwicklerin oder ein Entwickler mit spezifischem Technologiewissen sein oder jemand, der die Projektdokumentation überarbeitet. + +Weitere Einzelheiten siehe Producing Open Source Software: Development Status.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Demo-Instanz + +Bei Anwendungen empfiehlt es sich, eine Demo-Instanz bereitzustellen, damit die Anwendung ohne Installationsaufwand ausprobiert werden kann. Je nach Art der Anwendung kann die Demo-Instanz die produktive Installation oder eine Teststufe sein. Wichtig ist, dass Lesende möglichst eigenständig und direkt auf die entsprechende Instanz zugreifen können. + +Als Alternative stellen viele Open-Source-Projekte Werkzeuge bereit, um die Anwendung einfach zu starten. Dies kann beispielsweise mit Containern, portablen Anwendungen oder Installationsskripten erfolgen. + +=== Fachliche Ansprechperson und Projekteignerschaft + +In der Datei README.md sollte die wichtigste fachliche Ansprechperson genannt werden, damit andere interessierte Verwaltungen und Organisationen möglichst direkt Kontakt aufnehmen können. + +Persönliche E-Mail-Adressen sollten nicht verwendet werden. + +In der Datei README.md sollte zudem kurz beschrieben werden, welche Organisation Projekteignerin ist, insbesondere wenn für das Projekt ein Verein gegründet wurde. + +== Installationsdokumentation + +Bei Anwendungen sollte README.md auf eine Installationsdokumentation verweisen, die Hardware- und Softwareanforderungen beschreibt, welche Infrastrukturkomponenten (beispielsweise Datenbanken) verwendet werden und wie die Anwendung installiert und betrieben werden kann. + +=== Developer Guidelines + +Der Einstiegspunkt für die Developer Guidelines sollte in einer Markdown-Datei CONTRIBUTING.md abgelegt werden, die in README.md verlinkt ist. Die Developer Guidelines sind Teil der erweiterten Dokumentation für Entwickelnde, die zum Projekt beitragen möchten, und konzentrieren sich in erster Linie auf die Zusammenarbeit und Kommunikation im Projekt und nicht auf die Technik. + +Die Developer Guidelines sollten die folgenden Punkte enthalten und gegebenenfalls auf die entsprechenden Dokumente verweisen: + +* Einen Verweis auf den Code of Conduct des Projekts. Der Code of Conduct legt die erwarteten sozialen Normen innerhalb des Projekts fest. +* Es wird empfohlen, als Code of Conduct den unter CC-BY-4.0footnote:[https://creativecommons.org/licenses/by/4.0/] lizenzierten Contributor Covenant Code of Conduct zu wählen oder darauf aufzubauen.footnote:[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html] +* Einen Hinweis, dass das Projekt Code-Reviews in Form von GitHub-Pull-Requests durchführt, mit einem Verweis auf die GitHub-Pull-Request-Dokumentation. + +Abschliessend sollte auf die Developer Documentation verwiesen werden. + +=== Developer Documentation + +Während die Developer Guidelines die Zusammenarbeit und die sozialen Normen des Projekts beschreiben, konzentriert sich die Developer Documentation auf die technischen Aspekte der Mitwirkung an der Entwicklung des Projekts. Sie sollte mindestens die folgenden Punkte beschreiben: + +* Welche technischen Abhängigkeiten das Projekt hat und welche Werkzeuge für die Projektentwicklung nötig sind. +* Welche formalen Regeln für den Quellcode des Projekts gelten, beispielsweise zur Quellcodeformatierung. +* Wie der Quellcode des Projekts organisiert ist und wie Funktionen technisch getestet werden können. +* Eine Architekturskizze mit einer groben Beschreibung der Architektur, vorzugsweise einschliesslich Kontextabgrenzung und grober Komponentensicht.footnote:[Architekturrahmen MMB (Modellierungsmethode Bund) oder arc42. http://arc42.org/] +* Bei Anwendungen: Wie die Anwendung zu Entwicklungs- oder Debugging-Zwecken gestartet werden kann und welche Infrastrukturkomponenten hierfür nötig sind. + +== Begleitdokumentation zur link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] – Quellcode + +=== Quellcodehistorie + +Der Quellcode eines Projekts wird üblicherweise in einem Source-Code-Management-System (SCM) wie GitHub abgelegt. Diese Systeme speichern nicht nur den aktuellen Stand des Quellcodes, sondern auch Änderungen, die im Lauf der Zeit am Quellcode vorgenommen wurden. Dazu gehören insbesondere Löschungen im Quellcode einschliesslich gelöschter Dateien. + +Zudem enthält das SCM Metainformationen zu Änderungen am Quellcode, etwa Name und E-Mail der Autorin oder des Autors oder PGP-Signaturen für signierte Commits und Tags. + +=== Sensible, geschützte oder vertrauliche Daten + +Der Quellcode und die Quellcodehistorie des Projekts können öffentlich verfügbare Daten enthalten, etwa ein Postleitzahlenverzeichnis, zufällig erzeugte Daten oder synthetische Daten. + +Der Quellcode und die Quellcodehistorie dürfen keine sensiblen oder vertraulichen (Personen-)Daten oder Informationen im Sinne des Datenschutzgesetzes (DSG) und des Informationssicherheitsgesetzes (ISG) enthalten. Dazu gehören insbesondere: + +* Benutzernamen und Passwörter oder andere Geheimnisse wie private Schlüssel, Zugangstoken oder Zertifikate. +* Interne DNS-Namen, URLs, Hostnamen, IP-Adressen, Netzstrukturen oder Laufwerksnamen. +* Namen, Adressen, Bilder oder ähnliche Personendaten ohne Einwilligung der betroffenen Person +* Anonymisierte oder pseudonymisierte Daten (weil Anonymisierung oder Pseudonymisierung rückgängig gemacht werden können) + +Auch wenn der aktuelle Stand des Quellcodes frei von sensiblen, geschützten oder vertraulichen Daten oder Informationen ist, können solche Daten oder Informationen weiterhin aus der Historie des SCM-Systems abgerufen werden, wenn sie in der Vergangenheit je Teil des Quellcodes oder der SCM-Metainformationen waren. Eine Bereinigung des aktuellen Quellcodestands entfernt diese Informationen nicht vollständig.footnote:[Eine Möglichkeit zur Bereinigung eines Repos bietet das Werkzeug https://rtyley.github.io/bfg-repo-cleaner/[BFG Repo-Cleaner]] + +Im Zweifelsfall wird daher empfohlen, die Quellhistorie nach der Bereinigung des Quellcodes vor dessen Veröffentlichung vollständig zu entfernen. + +Namen und E-Mail-Adressen der Autorinnen und Autoren des Quellcodes sind üblicherweise direkt im Quellcode oder in den SCM-Metadaten verfügbar, beispielsweise in GitHub-Commits oder annotierten GitHub-Tags. Rechtlich ist dies unproblematisch, da das entwickelnde Unternehmen die Veröffentlichung solcher Informationen zu regeln hat. Es wird jedoch empfohlen, das entwickelnde Unternehmen bzw. bundesinterne Mitarbeitende darauf hinzuweisen, dass Namen und E-Mail-Adressen der Quellcode-Autorinnen und -Autoren bei der Veröffentlichung der Software offengelegt werden können. + +=== Entfernen von Autorenangaben + +Die Historie der Software kann geändert werden, um Autorenangaben zu verbergen. Werkzeugefootnote:[https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/] können diesen Schritt weitgehend automatisieren. + +Das Entfernen von Autorenangaben beseitigt Attribution, Nachvollziehbarkeit und Kontaktinformationen. Der damit verbundene Aufwand ist je nach Umfang des Quellcodes nicht zu unterschätzen. Aus diesen Gründen wird das Entfernen von Autorenangaben nicht empfohlen. Namen dürfen veröffentlicht werden, wenn a) die Einwilligung der betroffenen Personen vorliegt und b) keine sicherheitsrelevanten Gründe dagegensprechen. + +=== Berücksichtigung von Bibliothekslizenzen + +Praktisch jedes Projekt nutzt Drittbibliotheken (Softwarebibliotheken, Abhängigkeiten), um auf häufig verwendete Funktionen zuzugreifen, ohne sie selbst programmieren zu müssen. Diese Bibliotheken hängen üblicherweise von weiteren Bibliotheken ab, woraus mehrstufige Abhängigkeiten entstehen (transitive Abhängigkeiten). Je nach Programmiersprache können selbst kleine Projekte Hunderte von Abhängigkeiten aufweisen. + +Die Ergebnisse dieser Abklärung sind bei der Lizenzwahl nach link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] und in der link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] zu berücksichtigen. + +Für jede dieser Abhängigkeiten ist sicherzustellen, dass ihre Lizenz mit der Projektlizenz kompatibel ist. Besonders problematisch sind Abhängigkeiten, die nicht unter einer Open-Source-Lizenz stehen, die keine Lizenz deklariert haben oder die eine virale Lizenz verwenden, die nicht zur Projektlizenz passt. Manche Bibliotheken sind unter mehr als einer Lizenz lizenziert und erlauben es den Nutzenden, eine auszuwählen. + +* In allen wichtigen Programmiersprachen lassen sich die Abhängigkeiten des Projekts (einschliesslich transitiver Abhängigkeiten) und deren Lizenzen automatisch auflisten. Dazu gehören: +* Das Project-Info-Reports-Plugin für den Paketmanager Apache Maven für Java-Projekte, das mit dem Dependency-Report eine HTML-Ausgabe aller verwendeten Bibliotheken einschliesslich der deklarierten Lizenz erzeugt.footnote:[Plugin-Info https://maven.apache.org/plugins/maven-project-info-reports-plugin/plugin-info.html] +* Der NPM Licence Checker für den Paketmanager NPM für JavaScript-Projekte, der alle verwendeten Bibliotheken einschliesslich der deklarierten Lizenz in verschiedenen Formaten ausgeben kann, z. B. CSV.footnote:[NPM Licence Checker https://github.com/davglass/license-checker] +* Der Licence Finder von Pivotal, der verschiedene Paketmanager und Programmiersprachen unterstützt, darunter Ruby Gems, Python Eggs und Godeps.footnote:[Licence Finder von Pivotal https://github.com/pivotal/LicenseFinder] + +== Verwendung von Bibliotheken mit proprietären Lizenzen + +Bibliotheken unter einer proprietären Lizenz sind in Open-Source-Projekten grundsätzlich problematisch und können in der Regel nicht verwendet werden, insbesondere wenn der Quellcode unter einer viralen Lizenz wie der AGPL veröffentlicht wurde. + +Bitte wenden Sie sich an den Anbieter und den Rechtsdienst des betreffenden Amtes, um zu prüfen, ob und unter welchen Bedingungen die proprietäre Bibliothek in Ihrem Projekt verwendet werden kann. + +=== Verwendung von Paketmanagern + +Praktisch alle verbreiteten Programmiersprachen stellen Paketmanager zur Verwaltung ihrer Abhängigkeiten bereit, etwa Apache Maven für Java-Projekte, NPM für JavaScript-Projekte oder NuGet für .NET-Projekte. + +Bei Verwendung eines Paketmanagers sind die vom Projekt genutzten Abhängigkeiten nicht mehr direkt Teil des Quellcodes des Projekts, etwa durch Kopieren des Quellcodes der Abhängigkeit in das Projekt oder durch Kopieren der Abhängigkeiten in binärer Form in das Projekt. Stattdessen bezieht das Projekt alle Abhängigkeiten über die Deklarationen des Paketmanagers. + +Dies erlaubt es, alle Abhängigkeiten aufzulisten und korrekt zu referenzieren. Zudem verhindert es die unbeabsichtigte Veränderung von Abhängigkeitscode. Sind Änderungen nötig, so müssen sie direkt an der Quelle der Abhängigkeit vorgenommen werden. + +=== Deklaration der Projektlizenz im Paketmanager-Deskriptor + +Das Projekt sollte seine Lizenz im entsprechenden Paketmanager-Deskriptor deklarieren, unter Verwendung des SPDX-Identifikators,footnote:[SPDX-Identifikator – https://spdx.org/] damit die Projektlizenz vom Paketmanager ausgegeben werden kann. Dies ist besonders bei Bibliotheken wichtig, damit Nutzende der Bibliothek deren Lizenz automatisch über den Paketmanager abfragen können. + +=== Attribution und Copyright-Hinweise + +Viele Bibliotheken unterstehen einer Lizenz, die von den Nutzenden der Bibliothek einen ursprünglichen Copyright-Hinweis oder eine Attribution verlangt. + +Dazu gehören die folgenden Lizenzen (Auszug): + +Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons «Attribution» (CC BY), MIT, ISC + +Für weitere siehe die Liste der von der OSI anerkannten Lizenzen.footnote:[Open-Source-Lizenzen sind Lizenzen, die der Open Source Definition entsprechen – kurz gesagt erlauben sie, Software frei zu nutzen, zu verändern und zu teilen. https://opensource.org/licenses] + +In der Praxis betrifft dies nahezu alle verwendeten Bibliotheken. Da die Zahl der in kleinen Projekten verwendeten Bibliotheken bereits sehr hoch ist, ist ein rechtlich korrekter Copyright-Hinweis bzw. die nötige Attribution nur mit grossem Aufwand möglich. + +Es wird daher empfohlen, wie folgt vorzugehen: + +* Eine Liste der verwendeten Bibliotheken erstellen, mit den Mechanismen des Paketmanagers oder mit Werkzeugen wie dem NPM Licence Checker oder dem Licence Finder von Pivotal. +* Die Liste manuell aufbereiten, sodass sie die folgenden Angaben enthält: offizieller Name des Bibliotheksprojekts, Website des Bibliotheksprojekts, für die Bibliothek verwendete Lizenz als SPDX-Identifikator mit Link auf den Lizenztext. +* Die Liste im Quellcode des Projekts ablegen, z. B. in einer Datei THIRD-PARTY-LICENSES.md. +* Bei Anwendungen: Einen Link auf THIRD-PARTY-LICENSES.md in einem Dialog «Über» oder «Über diese Anwendung» aufnehmen. +* Der Dialog «Über» ist für diesen Zweck weit verbreitet, beispielsweise in Google Chrome (im Dialog «Über Chrome»). +* Bei Bibliotheken: In README.md unter THIRD-PARTY-LICENSES.md verweisen. +* Im Rahmen des Code-Review-Prozesses sicherstellen, dass Änderungen an den Bibliotheken in THIRD-PARTY-LICENSES.md nachgeführt werden. + +== Beispiel Codeblock THIRD-PARTY-LICENSES.md + +Dieses Projekt verwendet Open-Source-Software: + +* Spring Boot, http://projects.spring.io/spring-boot/[projects.spring.io/spring-boot] lizenziert unter http://www.apache.org/licenses/LICENSE-2.0[Apache-2.0] +* caniuse-db, https://github.com/Fyrd/caniuse[github.com/Fyrd/caniuse] lizenziert unter https://creativecommons.org/licenses/by/4.0/[CC-BY-4.0] + +=== Begleitdokumentation zur Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung + +==== Veröffentlichung mit publiccode.yml + +Publiccode.yml ist ein Metadatenstandard für Software-Repositories, die von öffentlichen Verwaltungen entwickelte oder beschaffte Software enthalten. Ziel ist es, diese Software besser auffindbar und wiederverwendbar zu machen. Der Metadatenstandard ist international etabliert und öffentlich unter https://yml.publiccode.tools/ beschrieben. Eine Datei publiccode.yml enthält typischerweise Angaben wie Titel und Beschreibung (in mehreren Sprachen möglich), Entwicklungsstand, Kontaktangaben, Lizenzinformationen usw. Für die Schweiz sind länderspezifische Erweiterungen geplant. + +Für jede Software ist im Hauptverzeichnis des Repositorys eine yml-Datei zu erstellen. Besteht die Lösung aus mehreren (Hilfs-)Repos, so genügt eine Datei, da diese den Anwendungsfall der Lösung beschreibt. + +Anhand der strukturierten Daten in den publiccode.yml-Dateien wird für die gesamte Bundesverwaltung ein https://www.opensource.admin.ch/[OSS-Katalog] (https://www.opensource.admin.ch[opensource.admin.ch]) erzeugt. Der Katalog bietet einen Überblick über veröffentlichte Software und erleichtert das Auffinden und die Wiederverwendung bestehender Lösungen. + +Wird ein neues Repository oder eine neue Organisation erstellt, so ist dies für die Aufnahme in den OSS-Katalog per E-Mail an opensource@bk.admin.ch zu melden. + +Neben dem OSS-Katalog steht auch ein grafischer Editor und Validator für publiccode.yml-Dateien zur Verfügung. + +OSS-Katalog und Editor: https://www.opensource.admin.ch/ + +=== Weitere Quellen und Lizenz + +Die Checkliste, die Begleitdokumentation und zugehörige Vorlagen beruhen teilweise auf den folgenden Quellen: + +* Google Open Source Docs von Google LLC, lizenziert unter 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 von 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/] +endif::[] + +ifeval::["{lang}" == "fr"] +*Clause de non-responsabilité :* 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.footnote:[Recommandation pour l'informatique de l'administration fédérale conformément à ++[++P035++]++ _chapitre 4.6_]footnote:[Pour les définitions des classifications INTERNE et CONFIDENTIEL, voir l'_ordonnance du 8 novembre 2023 sur la sécurité de l'information au sein de la Confédération et de l'armée (OSI ; RS 128.1)_]footnote:[Voir note de bas de page 1]footnote:[Domaines de planification conformément à la _stratégie informatique de la Confédération 2020-2023 du 3 avril 2020 (SB000)_] Pour de plus amples informations, voir le {url-repo}/tree/main[README] principal. + +''''' + +== Résumé à l'intention de la direction + +Les présentes instructions décrivent la procédure de publication du code source des logiciels que les autorités fédérales développent ou font développer pour accomplir leurs tâches, conformément à l'art. 9 LMETA.footnote:[Loi fédérale _++[++EMOTA2023++]++_] Des exceptions sont prévues lorsque des droits de tiers ou des motifs relevant de la sécurité excluent ou restreignent cette publication. Publier signifie que quiconque peut utiliser, développer et diffuser le logiciel. Aucune redevance de licence n'est perçue. + +Les présentes instructions s'adressent aux personnes responsables de la publication du code source et chargées de sa mise en œuvre. + +[mermaid,align="center",alt="Vue d'ensemble du processus de publication OSS"] +.... +flowchart TD + S(["Début"]) + A["Évaluation préalable"] + B["Analyse et préparation"] + C["Publication"] + S --> A + A --> B + B --> C +.... + +La matière est divisée en trois parties principales : + +* La première partie (chapitre 3) traite des *évaluations préalables* et des exceptions prévues par la LMETA. +* La deuxième partie (chapitre 4), *Analyse et préparation*, examine le code source et le prépare selon les besoins. Le choix de la licence y est également effectué. +* La troisième partie (chapitre 5), *Publication et annonce*, décrit la publication proprement dite ainsi que d'autres mesures telles que la communication et la constitution d'une communauté appropriée. + +*Trois listes de contrôle* accompagnent et documentent le processus. + +Des compléments techniques figurent en annexe. + +== Introduction + +Lors de la publication de logiciels open source, il convient de distinguer entre la *contribution de code source et de documentation à un logiciel open source existant* et la *publication en tant que projet open source indépendant*. + +Le premier cas comprend typiquement des corrections d'erreurs et des extensions fonctionnelles. Selon le type de licence et l'utilisation du logiciel, le code source doit ou peut être publié sous la licence existante du projet open source. Un accord de publication peut devoir être respecté. + +Dans le second cas, le lancement d'un nouveau projet open source, la gouvernance et la licence peuvent en principe être choisies librement. Le seul élément à prendre en compte est la licence sous laquelle sont publiés les éléments logiciels éventuellement intégrés au nouveau projet. De plus amples détails sur le choix de la licence figurent dans le document link:em002-3.pdf[Em002-3 Guide de licences OSS]. Si une plus-value peut être générée pour l'administration fédérale grâce à une communauté ou si l'administration fédérale souhaite créer un écosystème, la link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS] doit également être remplie conformément au link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +La publication de logiciels open source est plus qu'une simple mesure technique. Elle suppose aussi d'établir une culture correspondante d'ouverture et d'embarquer les personnes concernées. Une culture open source réussie est un mélange d'ouverture, d'excellence technique, de forte interaction sociale et d'engagement partagé. + +Le schéma suivant décrit les instructions et les différentes configurations. + +[mermaid,align="center",alt="Arbre de décision pour la publication de logiciels"] +.... +flowchart TD + Start(["Début
développé à partir du 1.1.2024"]) + subgraph B1["1. Évaluation préalable"] + T{"Type de logiciel"} + end + subgraph B2["2. Analyse et préparation"] + I{"Des tiers sont-ils
intéressés par le logiciel ?"} + GJ["Clarifier la gouvernance et
la collaboration [Em002-4.1]"] + GT["Clarifier la gouvernance et
la collaboration [Em002-4.1]"] + O{"Développement de logiciels
open source ?"} + end + subgraph B3["3. Publication"] + M["Effectuer une publication minimale"] + P["Publication du logiciel"] + D["Développement de logiciels
open source"] + C["Constituer et entretenir
une communauté [Em002-4]"] + end + Start --> T + T -->|"Développement propre"| I + T -->|"Développement commun"| GJ + T -->|"Projet de tiers"| GT + I -->|"Non"| M + I -->|"Oui, ou envisageable"| O + GJ --> O + GT --> D + O -->|"Non"| P + O -->|"Oui"| D + P --> C + D --> C + M --> E1(["Fin"]) + C --> E2(["Fin"]) +.... + +Figure 1 – Arbre de décision pour la publication de logiciels + +== Processus d'évaluation préalable + +*Objectif :* comprendre les avantages et les conséquences possibles d'une publication du logiciel. Décider si le logiciel peut être publié et, dans l'affirmative, si la constitution d'une communauté active en vaut la peine. Remarque : la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable OSS] devrait être remplie le plus tôt possible dans le projet, car cela peut influencer la manière dont le logiciel est développé. + +=== Publication selon la LMETA + +Conformément à l'art. 9 de la loi fédérale du 17 mars 2023 ++[++EMOTA2023++]++ sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA), l'administration fédérale (concrètement l'art. 2, al. 1) doit publier le code source des logiciels qu'elle développe ou fait développer pour accomplir ses tâches. Des exceptions s'appliquent lorsque des droits de tiers ou des motifs relevant de la sécurité l'excluent ou le restreignent. + +Pour les logiciels sur mesure créés sur mandat de la Confédération, les conditions générales de la Confédération ++[++BBL-AGB++]++ s'appliquent en principe. Selon leur chiffre 25.1, la propriété du code source et de la documentation passe au service acquéreur (la Confédération). Si le logiciel a été acquis conjointement par plusieurs organisations ou d'autres institutions, il faut vérifier qui détient les droits sur le code. La propriété peut par exemple appartenir à une association fondée à cet effet. + +La simple utilisation de logiciels standard n'entre pas dans le champ de l'art. 9 LMETA et une publication ne serait de toute façon généralement pas possible, les droits sur les logiciels standard restant souvent chez le fournisseur (CG de la Confédération pour l'acquisition de logiciels standard). Les extensions sur mesure de logiciels standard se prêtent en revanche tout à fait à une publication. Elles appartiennent normalement à la Confédération. De simples adaptations de configuration se prêtent moins à une publication. Le sujet est traité dans link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et des logiciels open source] ainsi que dans les documents ++[++KBB-MB++]++ et ++[++BBL-WL++]++. En principe, les extensions relèvent toujours de l'art. 9 LMETA. + +==== Le logiciel au regard de la LMETA + +La norme ISO/IEC 24765 actuelle contient trois définitions du logiciel : + +. un programme ou un ensemble de programmes servant à faire fonctionner des ordinateurs +. les programmes et la documentation qui s'y rapporte +. les programmes et, le cas échéant, la documentation associée ainsi que les autres données nécessaires au fonctionnement de l'ordinateur. + +Sur la base de cette définition, les scripts, macros ou Infrastructure as Code (IaC) de moindre importance sont également considérés comme des logiciels. La LMETA se réfère au code source à l'article 9, alinéa 1. Selon cette interprétation, une publication au sens de la définition 1 suffirait. Une publication sans la documentation associée n'a toutefois que peu de valeur, le logiciel ne pouvant pas être utilisé au sens de la définition 2. + +Pour réaliser des synergies avec des tiers, il faut se fonder sur la définition 3. S'agissant des données, cela signifie concrètement les données de base et les configurations de base (par exemple les valeurs d'énumération et les données de base qui devraient également être mises à disposition en open source). + +Les petits projets, scripts ou exemples de code peuvent aussi être publiés ensemble dans un seul dépôt si l'autorité fédérale le juge approprié. Dans ce cas, les présentes instructions et les listes de contrôle correspondantes peuvent être remplies une seule fois. + +La proportionnalité et la charge de travail doivent être prises en compte pour décider de ce qui est publié et comment. + +==== Type de logiciel + +Comme le montre la figure 1, on distingue entre développement propre, développement commun et projets de tiers. Chaque constellation a des implications différentes. Quelle que soit la manière dont le logiciel est développé, il relève de l'art. 9 LMETA. + +Dans le cas du développement propre, la Confédération crée elle-même le logiciel ou le fait créer en conséquence. Elle choisit la gouvernance et conserve les droits sur le code source. + +Dans le cas du développement commun, la Confédération crée le logiciel avec d'autres organisations. La gouvernance et les droits sur le logiciel doivent être réglés par la forme d'organisation choisie. + +Si la Confédération contribue directement à un logiciel de tiers, ce code source relève également de l'art. 9 LMETA. Il faut s'assurer que cela se fasse dans l'intérêt des autorités fédérales, que la participation réponde aux exigences du projet et que l'administration fédérale respecte la gouvernance. + +Cela se fait au moyen de la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable OSS] et de la link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS]. + +==== Code existant + +Pour les anciens logiciels (*logiciels existants*), la charge rétroactive liée à une publication est plus élevée que si celle-ci avait été planifiée dès le départ. Pour les logiciels existants, il ne vaut la peine de consentir cette charge que si un utilisateur potentiel souhaite utiliser le logiciel. Indépendamment de cela, la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable OSS] devrait être remplie afin de documenter les décisions déterminantes. + +Les applications dont les autorités fédérales ont commencé le développement le 1er janvier 2024 ou après cette date, ou qui sont développées sur mandat de la Confédération sur la base d'un contrat conclu après le 1er janvier 2024, ne sont pas considérées comme existantes et relèvent dans tous les cas de l'obligation de publication prévue à l'art. 9, al. 1, LMETA. + +L'obligation de publication prévue par la LMETA ne dépend pas de l'utilité pour des tiers. + +==== Bibliothèques, plug-ins et add-ons + +Dans certains cas, le logiciel n'est pas une application autonome, mais seulement des parties de celle-ci. La LMETA et l'ordonnance ne définissent pas plus précisément le code source. Les instructions s'appliquent également aux bibliothèques, plug-ins et add-ons découplés, qui relèvent de la LMETA. + +*Tâches :* + +* Recueillir les informations figurant dans link:em002-5.pdf[Em002-5 Aide-mémoire Outils OSS]. Celui-ci décrit tant des informations générales sur les logiciels open source que des informations spécifiques sur l'application de la LMETA. +* Vérifier si les conditions prévues par la LMETA sont remplies. +* Remplir la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable OSS]. En règle générale, il est judicieux d'associer directement les personnes de contact du fournisseur ou de l'équipe de développement. +* Au besoin, remplir la link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS]. + +*Décision :* le logiciel doit-il être publié et comment cela doit-il se faire ? + +=== Exception : droits de tiers + +Il convient de renoncer à une publication si celle-ci violerait des droits de tiers. Si le logiciel a été développé par des employés de la Confédération, les droits appartiennent à l'employeur.footnote:[Art. 332 CO en relation avec l'art. 6, al. 2, LPers] Dans les contrats de location de services et de prestations informatiques, les droits sont généralement transférés à la Confédération et devraient être invoqués. + +Si le logiciel a été ou est développé sur la base des conditions générales de la Confédération suisse (état 2024),footnote:[Conditions générales de la Confédération suisse, en particulier le chiffre 25.1 – https://www.bkb.admin.ch/bkb/de/home/themen/agb.html#accordion_21321111141713247349255] les droits de propriété intellectuelle appartiennent au mandant, sauf convention contractuelle contraire. + +Une application se compose typiquement de nombreux composants et éléments individuels. Pour certains types, cela devient problématique lorsqu'ils ne sont eux-mêmes pas open source ou ne peuvent pas être publiés sous une licence open source dans le cadre de l'application. + +*Bibliothèques* + +Selon le langage de programmation, les bibliothèques sont soit compilées directement avec l'application, soit liées, soit livrées sous forme de paquets. Elles font partie intégrante de l'application. + +Si l'application contient des bibliothèques propriétaires ou soumises à licence, l'open sourcing devient plus difficile. En principe, le code source du reste de l'application peut être publié, mais les utilisateurs ou développeurs potentiels devraient acquérir la bibliothèque concernée avant que l'application ne devienne utilisable ou extensible. + +Si la propriété de la bibliothèque problématique appartient au fournisseur de l'application, il vaut la peine de demander une clarification juridique afin de déterminer si la Confédération dispose de droits transférables sur ces bibliothèques. + +Dans la mesure du possible, les bibliothèques propriétaires et soumises à licence devraient être évitées dans les développements propres ou remplacées si possible avant la publication. Au regard de l'objectif de l'article 9 LMETA, il convient de publier autant de fonctionnalités que possible utilisées par les administrations publiques. Les bibliothèques isolées qui empêchent la publication du code représentent donc une dette technique qui devrait être documentée et, le cas échéant, éliminée dès que l'occasion se présente. + +*Bases de données et autres systèmes de stockage* + +Si l'application utilise un système de stockage propriétaire et soumis à licence tel que Microsoft SQL Server, cela ne constitue pas un obstacle à une publication open source. + +Il convient toutefois d'examiner si des bases de données ouvertes supplémentaires telles que PostgreSQL peuvent être prises en charge. Cela peut réduire les coûts d'exploitation et abaisser les barrières à l'entrée pour les utilisateurs potentiels. + +*Serveurs d'applications et systèmes d'exploitation* + +Si l'application nécessite des systèmes d'exploitation ou des serveurs d'applications sous licence (p. ex. Microsoft Windows Server ou RedHat JBoss), cela ne constitue pas un obstacle à une publication open source. + +Nous recommandons de demander au fournisseur du logiciel si des bibliothèques tierces sous licence sont utilisées comme composants de l'application et, le cas échéant, lesquelles. + +Si la création du logiciel a été acquise conjointement par plusieurs organisations ou d'autres institutions, la propriété appartient généralement à une association ou à une autre personne morale constituée à cet effet. + +*Autre propriété intellectuelle* + +Les droits de tiers ne comprennent pas seulement les droits d'auteur, mais aussi d'autres droits de propriété intellectuelle (marques, brevets). Les brevets n'empêchent pas fondamentalement qu'un logiciel soit publié en open source, mais ils peuvent en empêcher l'utilisation ou l'extension. Bien que les brevets soient plutôt rares en Suisse, il vaut généralement la peine de demander brièvement au fournisseur du logiciel si un examen a déjà eu lieu. + +*Acquisition des droits nécessaires* + +Pour satisfaire aux exigences légales de la LMETA, l'autorité fédérale a, en tant qu'adjudicateur, la possibilité de s'assurer les droits sur les résultats des travaux. Cette condition d'une publication peut être définie comme critère lors de l'acquisition. L'acquisition ultérieure des droits nécessaires sur le logiciel peut s'avérer plus complexe. + +Si l'autorité fédérale ne souhaite pas publier elle-même le logiciel, elle peut par exemple déléguer cette tâche au mandataire ou transférer les droits de publication en conséquence. Dans ce cas, elle transfère les droits (et obligations) nécessaires au fournisseur ou à des tiers et les charge de la publication. Le droit est ainsi effectivement transféré à un tiers sous condition de publication ou de support du logiciel correspondant. + +Ici aussi, ++[++KBB-MB++]++ contient des indications importantes. + +*Procédure* + +[mermaid,align="center",alt="Processus de traitement de l'exception relative aux droits de tiers"] +.... +flowchart TD + S(["Début"]) + Q1{"Acquisition d'une licence ou d'une
solution existante en tant qu'objet
d'acquisition central ?"} + Q2{"Les développements ultérieurs
sont-ils définissables ?"} + Q3{"Les droits appartiennent-ils
à la Confédération ?"} + Q4{"L'acquisition de droits de
tiers est-elle nécessaire ?"} + Q5{"Une partie dont les droits appartiennent
à la Confédération peut-elle être
délimitée de manière ciblée ?"} + R1["Exception justifiée :
droits de tiers"] + R2["Publication partielle par
la Confédération"] + R3["Publication par la Confédération"] + S --> Q1 + Q1 -->|"Non"| Q3 + Q1 -->|"Oui"| Q2 + Q2 -->|"Oui"| Q3 + Q2 -->|"Non"| R1 + Q3 -->|"Oui"| R3 + Q3 -->|"Non"| Q4 + Q4 -->|"Oui"| R3 + Q4 -->|"Non"| Q5 + Q5 -->|"Oui"| R2 + Q5 -->|"Non"| R1 +.... + +Figure 2 – Exception : droits de tiers (toujours tenir compte également de ++[++KBB-MB++]++ et de link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et des logiciels open source]) + +Une exception justifiée au titre des droits de tiers résulte non seulement de l'acquisition de licences ou de logiciels existants, mais aussi du développement logiciel réalisé sur un logiciel existant sous licence. + +Une publication partielle est possible dans la constellation suivante : le logiciel contient des parties propriétaires ou protégées ; celles-ci peuvent être distinguées du développement ultérieur ; d'autres droits de propriété intellectuelle sont en jeu. + +*Tâches :* + +* Vérifier si l'organisation détient les droits de protection déterminants sur le logiciel. +* Vérifier si les droits peuvent être acquis. +* Au besoin, obtenir l'autorisation écrite des titulaires des droits. +* S'assurer que l'application ne contient aucune partie propriétaire ou protégée. +* Vérifier qu'aucun obstacle ne résulte d'une protection par brevet (dans la mesure du possible et du raisonnable). +* Vérifier si la publication doit être effectuée par un tiers. +* Vérifier si le développement doit reposer sur le développement de logiciels open source (au moyen du link:em002-4.pdf[Em002-4 Guide des communautés OSS]). + +*Décision :* le logiciel peut-il être publié sans violer de droits de tiers ? + +=== Exception : motifs relevant de la sécurité + +Les logiciels qui ne peuvent pas être publiés pour des motifs relevant de la sécurité sont exemptés de publication. + +Les données proprement dites d'un logiciel ne sont pas concernées par la publication du code source. Ces données sont généralement sensibles et ne sont pas publiées. Il se peut toutefois qu'outre les données de contenu, certains algorithmes et procédés visibles dans le code source ne doivent pas devenir publics (p. ex. capacités cyber offensives, détails de la détection des fraudes). La sécurité peut porter sur la confidentialité, l'intégrité, la disponibilité ou la traçabilité. + +*Recommandation :* + +Les logiciels devraient être délibérément développés de manière qu'aucun risque supplémentaire ne survienne même en cas de publication du code source. L'hypothèse selon laquelle la non-publication protège contre des attaques réussies est trompeuse (« security through obscurity »). + +*Procédure :* + +[NOTE] +==== +Ce qui est déterminant est toujours le logiciel et non sa finalité. Le traitement de données critiques ne constitue pas a priori un aspect relevant de la sécurité. +==== + +[mermaid,align="center",alt="Processus de traitement de l'exception relative aux motifs de sécurité"] +.... +flowchart TD + S(["Début"]) + Q1{"Motifs relevant
de la sécurité ?"} + Q2{"Le logiciel relevant de la
sécurité peut-il être découplé ?"} + Q3{"Motifs temporaires ?"} + M["Mesures pour
la publication"] + R1["Publier une partie
du logiciel"] + R2["Exception :
motifs relevant de la sécurité"] + R3["Exception temporaire"] + R4["Publier"] + S --> Q1 + Q1 -->|"Un ou plusieurs points s'appliquent"| Q2 + Q1 -->|"Non applicable"| Q3 + Q2 -->|"Oui"| R1 + Q2 -->|"Non"| R2 + Q3 -->|"Un ou plusieurs points s'appliquent"| R3 + Q3 -->|"Aucun motif temporaire"| M + M --> R4 +.... + +Figure 3 – Exception : motifs relevant de la sécurité + +Les motifs suivants peuvent être considérés comme relevant de la sécurité selon le projet : + +* La publication du logiciel augmenterait sensiblement un risque en matière de sécurité de l'information.footnote:[Loi sur la sécurité de l'information, LSI. Art. 6 Sécurité de l'information. https://www.fedlex.admin.ch/eli/cc/2022/232/de#art_6] +* Pour les algorithmes de prévention de la fraude et les algorithmes analogues, il peut le cas échéant être renoncé à une publication. +* Technologies de cybersécurité particulièrement sensibles. +* Logiciels essentiels à l'exploitation d'infrastructures critiques. +* Lorsque la publication violerait d'autres bases légales. + +Les motifs temporaires suivants peuvent encore empêcher une publication. Celle-ci sera toutefois rendue possible ultérieurement par des mesures appropriées. + +* Le code existant n'a pas encore pu être nettoyé et contient éventuellement des problèmes relevant de la sécurité. +* Les audits de sécurité du code n'ont pas encore été réalisés. +* Le processus de développement n'est pas encore assez mature pour permettre une publication sûre. Si le processus de développement n'est pas suffisamment établi, il est possible que des parties non destinées à des tiers soient publiées. Par exemple, les directives de commentaire du code et la génération de données de test doivent être adaptées au nouveau scénario de publication et fonctionner de manière fiable. + +Les mesures suivantes permettent de publier un logiciel malgré des motifs relevant de la sécurité : + +* Séparer du logiciel les configurations (p. ex. type de chiffrement utilisé). +* Externaliser dans des configurations ou des paramètres les informations techniquement sensibles et non publiques (p. ex. processus, calculs). +* Planifier, mettre en œuvre et exercer régulièrement des mesures organisationnelles, personnelles et techniques appropriées. +* Planifier et réaliser des activités de qualité appropriées lors de la publication. Voir le chapitre suivant « Analyse et préparation ». + +*Tâches :* + +* Examiner le logiciel quant aux motifs relevant de la sécurité qui empêcheraient une publication. +* Estimer la charge nécessaire pour éliminer les motifs temporaires. +* Planifier des mesures visant à séparer les informations relevant de la sécurité du code source du logiciel. +* S'assurer que l'application ne contient aucun procédé qui ne doit pas devenir public. + +*Décision :* + +Existe-t-il des motifs impératifs relevant de la sécurité qui rendent la publication impossible ? + +=== Clarification de la publication + +Cette étape permet de clarifier qui publiera le logiciel. Si le logiciel a été créé par un fournisseur externe, la publication peut aussi être confiée à ce fournisseur. Lors de cette étape, il importe de déterminer où le code source sera publié et d'établir une gouvernance correspondante. + +Si le logiciel a été développé en interne à la Confédération et que celle-ci ne peut ou ne souhaite pas le publier elle-même, un mandat de publication peut être confié à un fournisseur ou les droits peuvent être cédés (transfert des obligations à un tiers). + +*Publication minimale et support* + +La LMETA ne prévoit aucune exigence concernant la publication. Une publication minimale du code source satisfait à l'exigence légale. Aucune autre activité n'est requise. La question de savoir si et dans quelle mesure un support est offert et avec quelle intensité le projet est entretenu peut être traitée au moyen du link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +*Développement de logiciels open source (OSSD)* + +Dans le développement de logiciels open source (OSSD), outre la publication du code source, l'ensemble du processus de développement se déroule publiquement. Tout, des exigences (issues) au code source, est transparent. L'OSSD s'appuie sur des outils de communication publics (listes de diffusion, forums, etc.), un système de gestion de versions (git), des listes d'erreurs et de fonctionnalités, une feuille de route et des outils de développement. Grâce à cette méthode de travail transparente, toute la communauté en profite et la collaboration au-delà des frontières organisationnelles devient possible. Avec cette approche, aucune activité de publication supplémentaire n'est nécessaire à l'achèvement du projet, celle-ci ayant déjà été prise en compte à son démarrage. + +*Tâches* + +* Établir une estimation sommaire de la charge pour la phase d'analyse. Selon la taille et la complexité de l'application, la charge varie entre trois jours et deux semaines. +* Libérer des ressources pour les étapes suivantes, en particulier pour l'analyse. +* Donner un accord de principe pour publier l'application en open source. + +*Décision :* + +L'accord de principe et la faisabilité pour publier l'application en open source sont donnés. + +=== Minimiser la charge + +Les listes de contrôle et les instructions sont conçues de manière à réduire au minimum la charge liée aux publications. Une planification anticipée et cohérente de la publication dès le début du projet ainsi qu'un développement orienté vers la publication minimisent la charge. Une certaine charge administrative et certains coûts sont inévitables ++[++Le2023++]++. Ceux-ci peuvent le cas échéant être récupérés grâce à des communautés partageant les coûts de développement (voir link:em002-4.pdf[Em002-4 Guide des communautés OSS]). + +=== Choix de la langue de publication + +Le choix de la langue doit tenir compte à la fois du public cible potentiel et de la méthode de travail de l'équipe. Heureusement, les traductions sont devenues bien plus simples grâce aux nouveaux outils. Les langues officielles de la Confédérationfootnote:[https://www.fedlex.admin.ch/eli/cc/1999/404/fr#art_70] et l'anglais entrent en ligne de compte. + +Si le projet présente une pertinence internationale, l'anglais devrait être la langue cible. Pour une publication ultérieure, un changement de langue n'a naturellement guère de sens. + +Au minimum, le fichier README.md devrait être disponible en plusieurs langues afin que les personnes intéressées puissent voir immédiatement si le projet est pertinent pour elles. + +La communication publique devrait tenir compte en premier lieu du public cible. Il convient également de considérer qu'il s'agit d'une communication publique de la Confédération. + +*Remarque* : avec la publication, l'administration fédérale emprunte un nouveau canal de communication publique. Si cela n'est pas fait avec soin et professionnalisme, l'image publique de la Confédération peut rapidement en pâtir. + +== Analyse et préparation + +*Objectif :* les travaux nécessaires à une publication open source sont achevés. Les décisions relatives à la licence et au type de communauté ont été prises. Cela se fait au moyen de la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[liste de contrôle Em002-2.2 Analyse et préparation OSS]. + +=== Analyse du code source + +Le code source à publier et les autres documents qui s'y rapportent sont analysés avant la publication. Cette analyse garantit qu'aucune information confidentielle n'est publiée. + +Si un volume important de code source est prévu pour la publication, il est recommandé d'utiliser des outils automatisés appropriés pour les activités suivantes. + +Les détails sont définis à la section E. + +*Tâches* + +* Vérifier comment la qualité du code existante et les directives ont été mises en œuvre (p. ex. ISO/IEC 25010:2023footnote:[ISO/IEC 25010:2023 - Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.iso.org/standard/78176.html]). +* S'assurer qu'aucune donnée (de test) sensible n'est incluse, p. ex. des données fondées sur des personnes ou des cas réels. +* Mettre à jour la documentation du logiciel (voir annexe). +* Supprimer les fichiers inutiles ou les documents et données obsolètes. +* Vérifier le code source à la recherche de secrets ou d'identifiants.footnote:[https://www.ncsc.admin.ch/ncsc/fr/home/aktuell/im-fokus/2022/git.html] +* Effectuer des tests de sécurité ciblés et mettre ensuite en place un programme de bug bounty (public).footnote:[https://www.ncsc.admin.ch/ncsc/fr/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Vérifier toutes les bibliothèques utilisées quant aux licences et établir les listes correspondantes (attributions). Si une bibliothèque est disponible sous plusieurs licences, cela doit être indiqué en conséquence dans les listes. +* Décrire le déploiement (pipeline CI/CD) et, le cas échéant, mettre en place une instance de démonstration. + +Ces activités sont indépendantes de la publication, mais constituent des conditions préalables à une bonne qualité logicielle et à la garantie de la conformité. Le respect de ces mesures simplifie la collaboration, accroît la qualité des contributions externes et améliore l'image du logiciel ou de l'autorité. + +=== Choix de la licence + +*Voir link:em002-3.pdf[Em002-3 Guide de licences OSS].* + +Des textes de licence établis à l'échelle internationale devraient être utilisés lorsque cela est possible et judicieux. Les prétentions en responsabilité des preneurs de licence doivent être exclues dans la mesure permise par le droit. + +*Tâches* + +* Vérifier les éventuelles dépendances à des licences existantes. +* Pour le code de tiers, vérifier la compatibilité des conditions d'utilisation avec la licence prévue et remplacer le code si nécessaire.footnote:[Voir Em002-3 concernant le choix de code ou de bibliothèques de tiers pour une pile technologique et concernant la compatibilité de la licence.] +* Choisir la licence appropriée. + +La compatibilité des licences peut être vérifiée au moyen d'outils tels qu'ORT Toolkit,footnote:[https://oss-review-toolkit.org/] Black Duck,footnote:[https://www.blackducksoftware.com] FOSSAfootnote:[https://www.fossa.com] ou FOSSology.footnote:[https://www.fossology.org] Le ToDo Group footnote:[https://landscape.todogroup.org/] propose une vue d'ensemble actualisée des outils. + +*Décision :* + +* Déterminer et documenter sous quelle licence le logiciel sera publié. + +=== Documentation open source + +Un minimum de documentation est attendu lors de la publication. Plusieurs documents se sont établis dans l'écosystème open source. Ils donnent aux visiteurs un aperçu rapide du logiciel, y compris de sa licence. + +Les documents suivants sont attendus : + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Document* |*Description / contenu :* +|README(.md) |Sert de document d'entrée et donne un aperçu rapide de l'objectif, du périmètre, du statut, de la licence et des groupes cibles du projet. +|LICENSE |Description de la licence choisie dans le projet +|CONTRIBUTING(.md) |Décrit le processus permettant de contribuer au projet. +|CODE++_++OF++_++CONDUCT(.md) |Le code de conduite fixe les normes sociales attendues au sein du projet. +|CHANGELOG(.md) |Tient une liste des modifications apportées aux versions du logiciel. +|THIRD-PARTY-LICENSES(.md) |Description des licences de tiers ou des composants utilisés. +|Getting started |Brève marche à suivre pour installer et utiliser le logiciel. +|Create Gitignore |Décrit les documents qui ne seront pas publiés, p. ex. configurations, données de test ou contenus générés. Les informations protégées et sensibles devraient être gérées en dehors du projet, dans des outils et des espaces de stockage appropriés et dédiés. +|publiccode.yml |Métadonnées structurées décrivant le logiciel, sur la base du standard https://yml.publiccode.tools/. Le format défini rend la publication plus facile à trouver et à réutiliser. De plus amples informations figurent à l'annexe F. +|=== + +Tableau 1 – Documents open source + +D'autres détails techniques sur ces documents sont décrits en annexe. + +*Tâches* + +* Créer la documentation standard. +* Faire figurer le copyright, les mentions de licence et la clause de non-responsabilité dans tous les fichiers. +* Selon la plateforme de publication, des descriptions supplémentaires peuvent être ajoutées. + +*Décision :* + +* Décision définitive de publier l'application en open source. + +== Publication et annonce + +*Objectif :* l'application est publiée en open source et facilement repérable par des tiers. Tous les composants sont prêts pour la publication et la communauté est constituée ou établie. Cela se fait au moyen de la link:em002-2-3-checklist-oss-release-and-publication.pdf[liste de contrôle Em002-2.3 Validation et publication OSS]. Dans une certaine mesure, il s'agit de récapituler des décisions déjà prises. + +=== Choix de la plateforme + +Il existe plusieurs manières de publier du code source. Le tableau suivant donne une vue d'ensemble des systèmes de gestion de code source (SCM) et des plateformes possibles. + +La plateforme appropriée doit être choisie avant la publication proprement dite. Certaines autorités fédérales sont déjà présentes sur GitHub.footnote:[Le site https://ossbenchmark.com donne un aperçu des organisations et autorités actives sur GitHub.] Dans ce cas, il est judicieux d'utiliser les plateformes déjà établies. + +*Recommandation :* + +Nous recommandons actuellement de mettre en place une organisation sur GitHub par autorité fédérale pour la publication du code source. Au sein de cette organisation, des projets (dépôts) correspondants peuvent être créés et les utilisateurs gérés avec les autorisations appropriées. À l'avenir, une plateforme fédérale centrale devrait être mise en place. Afin de garantir une gestion optimale des utilisateurs et de préserver la réputation de la Confédération suisse, il est important d'utiliser moins de dépôts, mais mieux gérés. + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Plateforme* |*Caractéristiques* +|GitHubfootnote:[https://github.com/about/] |Plateforme en ligne de Microsoft, très répandue. Une grande quantité de logiciels open source est hébergée sur GitHub. Offre de nombreux outils supplémentaires en plus du SCM. Disponible en version Free et Enterprise (abonnement). +|GitLabfootnote:[https://about.gitlab.com/] |Plateforme en ligne de l'entreprise du même nom GitLab, elle-même publiée sous une licence open source. Offre de nombreux outils supplémentaires en plus du SCM. Peut aussi être exploitée localement, offrant ainsi un certain degré de souveraineté. Disponible en version Free et Enterprise (abonnement). +|Bitbucketfootnote:[https://bitbucket.org/product/en] |Plateforme en ligne d'Atlassian, spécifiquement intégrée à son écosystème. Disponible en version Free et Enterprise (abonnement). +|Système SCM interne |Si une plateforme SCM propre est mise à disposition, elle peut aussi publier et rendre disponibles certains dépôts ou projets. L'exploitation doit être assurée. +|Plateforme fédérale |Il n'existe actuellement aucune plateforme fédérale centrale pour la publication de logiciels. Une mesure en ce sens est proposée dans link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale]. +|Site web, serveur FTP public, etc. |La LMETA ne définit pas comment un logiciel doit être publié. Une publication minimalefootnote:[Une publication minimale ne comprend que la publication du code source et d'autres artefacts minimaux. Ce type de publication satisfait aux exigences de la LMETA. Aucune plus-value n'est toutefois obtenue par cette publication.] peut aussi se faire sur un site web ou d'autres ressources accessibles au public. Cela ne convient toutefois pas à une collaboration durable au sens de l'open source. +|=== + +Tableau 2 – Plateformes de publication de logiciels open source + +Si le logiciel est publié conjointement avec un partenaire ou une organisation externe, il convient de veiller à ce que les autorisations et les accès appropriés au code source soient disponibles. + +*Tâches* + +* Évaluer la plateforme appropriée, y compris l'organisation ou le projet correspondant. +* Si ce n'est pas encore clarifié, déterminer la dénomination du projet ou du dépôt. +* Définir et vérifier les autorisations sur le dépôt. +* Assurer une gouvernance appropriée et une éventuelle réplication du code source. + +*Décision :* + +* La plateforme de publication a été choisie de manière appropriée. + +=== Publication du logiciel + +Lorsque les conditions sont clarifiées, le logiciel peut être publié. + +*Tâches* + +* Vérifier les conditions au moyen de la link:em002-2-3-checklist-oss-release-and-publication.pdf[liste de contrôle Em002-2.3 Validation et publication OSS]. +* L'accès à la plateforme est disponible et la gouvernance est clarifiée. +* Publication du code source et de la documentation par l'équipe de développement. + +=== Communication + +Après la publication proprement dite, d'autres activités de communication peuvent être lancées par et au sein de l'autorité fédérale concernée. Elles favorisent la diffusion et apportent la plus-value souhaitée de la publication. + +*Tâches* + +* Description dans l'hébergement du dépôt, paramètres de sécurité, etc. +* Communication interne et, le cas échéant, externe +* Rédiger un message à l'intention de la communauté. +* Faire connaître l'application au sein de l'organisation et dans les organes spécialisés, en promouvoir l'utilisation et les contributions. +* Créer un fichier publiccode.ymlfootnote:[Le standard de métadonnées https://yml.publiccode.tools/ décrit le logiciel. Le format défini rend la publication plus facile à trouver et à réutiliser. De plus amples informations figurent à l'annexe F.] dans le dépôt pour le catalogue OSS de l'administration fédérale.footnote:[Catalogue OSS : https://www.opensource.admin.ch] + +=== Constitution et entretien de la communauté + +Lors de la publication d'un logiciel, une communauté peut se développer et contribuer au logiciel par des contributions (pull requests), des questions, des propositions de documentation, etc. Pour disposer d'une communauté active, une charge considérable est nécessaire tant pour la constitution que pour l'entretien continu. Une communauté qui fonctionne bien réduit au minimum les forks indésirables du logiciel. L'objectif est ici d'activer la plus-value de la communauté par des activités ciblées. Même en cas de publication minimale, la manière de traiter les retours et les questions sur le logiciel devrait être définie. + +*Tâches* + +* Clarifier qui sont les utilisateurs potentiels ou les personnes intéressées. +* Déterminer la forme appropriée pour l'application concrète au moyen du link:em002-4.pdf[Em002-4 Guide des communautés OSS]. +* Constituer la communauté. +* Activités de constitution de la communauté. + +== Annexe + +=== Modifications par rapport à la version précédente + +* Chapitres 4.3 et 5.3 : publication complétée par publicode.yml +* L'annexe F « Public Code » a été ajoutée +* Diverses modifications et améliorations rédactionnelles mineures + +=== Références + +Voir _Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale_. + +=== Abréviations + +Voir link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] et link:em002-6.pdf[Em002-6 FAQ sur l'OSS]. + +=== Documentation d'accompagnement link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle Analyse et préparation OSS] – Documentation + +=== Documentation du code source + +La documentation devrait faire partie du code source du projet afin que les modifications de la documentation soient enregistrées de manière infalsifiable et que la documentation soit versionnée parallèlement au projet. Cela garantit automatiquement que la documentation, si elle est correctement entretenue, ne diverge pas de l'état de développement du projet et que la documentation des versions antérieures du projet peut être consultée à tout moment. + +En outre, cela donne à des tiers la possibilité de contribuer facilement à des modifications de la documentation. + +Markdown devrait être utilisé comme langage de balisage pour la mise en forme du texte, car il est facile à écrire, largement répandu et lisible par machine. De plus, les documents Markdown sont affichés dans un format cible bien lisible par toutes les plateformes courantes. Les documents Markdown peuvent être rendus dans n'importe quel format cible indépendamment de la plateforme utilisée, au moyen de générateurs de sites statiques tels que Jekyll, MkDocs, Gatsby ou Sphinx, par exemple avec les prescriptions d'identité visuelle d'une administration. + +=== Destinataires et structure de la documentation + +La documentation de projet devrait s'adresser tant aux utilisateurs finaux qu'aux spécialistes techniques et ne pas se concentrer uniquement sur la technique. Pour le choix de la langue, voir le chapitre 3.6. Cela favorise la diffusion du logiciel. + +Un fichier README.md sert de document d'entrée. Les fichiers portant ce nom sont reconnus par toutes les plateformes courantes et affichés comme point d'entrée de la documentation.footnote:[Pour plus d'informations sur la création d'un fichier readme : https://www.makeareadme.com/] + +README.md devrait donner un aperçu rapide de l'objectif, du périmètre, du statut, de la licence et des groupes cibles du projet. Concrètement, README.md devrait contenir les points suivants : + +* Nom du logiciel +* Brève description de l'objectif et de la fonction du logiciel. Périmètre et limites possibles +* Instructions d'installation +* Utilisation du logiciel +* Renvoi à une éventuelle instance de démonstration +* Coordonnées de support et de contact +* Comment contribuer au logiciel open source (Contributing) +* Licence utilisée (Licence) +* Statut du projet / état de développement + +=== Mettre en avant l'open source et déposer la licence + +Directement après l'énoncé de mission, il convient d'indiquer clairement et sans ambiguïté que le projet est un logiciel open source. La licence utilisée par le projet devrait être indiquée avec l'identifiant SPDX correspondantfootnote:[Identifiant SPDX – https://spdx.org/about] et liée au texte de licence concret figurant dans le fichier LICENSE. Les modèles de licence comportent généralement une partie variable (p. ex. nom du projet, année de copyright, nom de l'auteur) qui doit être adaptée dans le fichier LICENSE. + +La plupart des plateformes reconnaissent les licences figurant dans un fichier LICENSE et offrent des informations claires sur la licence, p. ex. un bref résumé des conditions de licence. + +Il est recommandé d'ajouter un en-tête minimal de licence et de copyright à chaque fichier source créé. Les en-têtes existants dans les fichiers existants ne devraient pas être modifiés. En cas de contribution à un projet disposant de règles claires sur les en-têtes, celles-ci doivent être respectées. + +Pour plus de détails, voir : Producing Open Source Software: State That the Project is Free.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== État de développement actuel + +Afin de montrer rapidement l'état du projet, l'état de développement actuel devrait être documenté dans README.md. Il est important pour les lecteurs de savoir si le projet est dans un état mature ou au début de son développement, s'il est activement entretenu et à quelle fréquence de nouvelles versions sont publiées. + +Cette section peut décrire quel type de soutien de tiers est actuellement le plus important pour le projet. Il pourrait s'agir par exemple d'un développeur disposant de connaissances technologiques spécifiques ou d'une personne chargée de remanier la documentation du projet. + +Pour plus de détails, voir Producing Open Source Software: Development Status.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Instance de démonstration + +Pour les applications, il est recommandé de mettre à disposition une instance de démonstration afin que l'application puisse être essayée sans effort d'installation. Selon le type d'application, l'instance de démonstration peut être l'installation productive ou un environnement de test. Il importe que les lecteurs puissent accéder à l'instance correspondante de la manière la plus autonome et la plus directe possible. + +En alternative, de nombreux projets open source fournissent des outils permettant de démarrer facilement l'application. Cela peut se faire par exemple au moyen de conteneurs, d'applications portables ou de scripts d'installation. + +=== Personne de contact spécialisée et propriété du projet + +Le fichier README.md devrait nommer la principale personne de contact spécialisée afin que d'autres administrations et organisations intéressées puissent prendre contact le plus directement possible. + +Les adresses électroniques personnelles ne devraient pas être utilisées. + +Le fichier README.md devrait aussi décrire brièvement quelle organisation est propriétaire du projet, en particulier si une association a été constituée pour celui-ci. + +== Documentation d'installation + +Pour les applications, README.md devrait renvoyer à une documentation d'installation décrivant les exigences matérielles et logicielles, les composants d'infrastructure utilisés (par exemple les bases de données) ainsi que la manière d'installer et d'exploiter l'application. + +=== Developer Guidelines + +Le point d'entrée des Developer Guidelines devrait être déposé dans un fichier Markdown CONTRIBUTING.md, lié dans README.md. Les Developer Guidelines font partie de la documentation étendue destinée aux développeurs qui souhaitent contribuer au projet et se concentrent avant tout sur la collaboration et la communication au sein du projet plutôt que sur la technique. + +Les Developer Guidelines devraient contenir les points suivants et renvoyer le cas échéant aux documents correspondants : + +* Un renvoi au code de conduite du projet. Le code de conduite fixe les normes sociales attendues au sein du projet. +* Il est recommandé de choisir comme code de conduite le Contributor Covenant Code of Conduct, placé sous licence CC-BY-4.0,footnote:[https://creativecommons.org/licenses/by/4.0/] ou de s'en inspirer.footnote:[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html] +* Une indication précisant que le projet effectue des revues de code sous forme de pull requests GitHub, avec un renvoi à la documentation GitHub sur les pull requests. + +Enfin, il convient de renvoyer à la Developer Documentation. + +=== Developer Documentation + +Alors que les Developer Guidelines décrivent la collaboration et les normes sociales du projet, la Developer Documentation se concentre sur les aspects techniques de la participation au développement du projet. Elle devrait décrire au moins les points suivants : + +* Quelles dépendances techniques le projet présente et quels outils sont nécessaires à son développement. +* Quelles règles formelles s'appliquent au code source du projet, par exemple en matière de formatage du code source. +* Comment le code source du projet est organisé et comment les fonctions peuvent être testées techniquement. +* Une esquisse d'architecture avec une description sommaire de l'architecture, de préférence avec délimitation du contexte et vue sommaire des composants.footnote:[Cadre d'architecture MMB (méthode de modélisation de la Confédération) ou arc42. http://arc42.org/] +* Pour les applications : comment l'application peut être démarrée à des fins de développement ou de débogage et quels composants d'infrastructure sont nécessaires à cet effet. + +== Documentation d'accompagnement de la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[liste de contrôle Em002-2.2 Analyse et préparation OSS] – Code source + +=== Historique du code source + +Le code source d'un projet est généralement conservé dans un système de gestion de code source (SCM) tel que GitHub. Ces systèmes enregistrent non seulement l'état actuel du code source, mais aussi les modifications qui y ont été apportées au fil du temps. Cela comprend en particulier les suppressions dans le code source, y compris les fichiers supprimés. + +En outre, le SCM contient des métainformations sur les modifications du code source, telles que le nom et l'adresse électronique de l'auteur, ou des signatures PGP pour les commits et tags signés. + +=== Données sensibles, protégées ou confidentielles + +Le code source et son historique peuvent contenir des données accessibles au public, telles qu'un répertoire de codes postaux, des données générées aléatoirement ou des données synthétiques. + +Le code source et son historique ne doivent contenir aucune donnée ou information (personnelle) sensible ou confidentielle au sens de la loi fédérale sur la protection des données (LPD) et de la loi sur la sécurité de l'information (LSI). Cela comprend en particulier : + +* Les noms d'utilisateur et mots de passe ou autres secrets tels que clés privées, jetons d'accès ou certificats. +* Les noms DNS internes, URL, noms d'hôte, adresses IP, structures de réseau ou noms de lecteurs. +* Les noms, adresses, images ou données personnelles similaires sans le consentement de la personne concernée +* Les données anonymisées ou pseudonymisées (car il est possible d'annuler l'anonymisation ou la pseudonymisation) + +Même si l'état actuel du code source est exempt de données ou d'informations sensibles, protégées ou confidentielles, de telles données ou informations peuvent encore être extraites de l'historique du système SCM si elles ont un jour fait partie du code source ou des métainformations du SCM. Le nettoyage de l'état actuel du code source ne supprime pas complètement ces informations.footnote:[L'outil https://rtyley.github.io/bfg-repo-cleaner/[BFG Repo-Cleaner] offre une possibilité de nettoyer un dépôt] + +En cas de doute, il est donc recommandé de supprimer entièrement l'historique après le nettoyage du code source, avant de publier celui-ci. + +Les noms et adresses électroniques des auteurs du code source sont généralement disponibles directement dans le code source ou dans les métadonnées du SCM, par exemple dans les commits GitHub ou les tags GitHub annotés. D'un point de vue juridique, cela ne pose pas de problème, l'entreprise de développement étant chargée de régler la publication de telles informations. Il est toutefois recommandé de sensibiliser l'entreprise de développement ou les employés internes de la Confédération au fait que les noms et adresses électroniques des auteurs du code source peuvent être divulgués lors de la publication du logiciel. + +=== Suppression des informations sur les auteurs + +L'historique du logiciel peut être modifié afin de masquer les informations sur les auteurs. Des outilsfootnote:[https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/] permettent d'automatiser cette étape dans une large mesure. + +La suppression des informations sur les auteurs supprime l'attribution, la traçabilité et les coordonnées de contact. La charge que cela représente ne doit pas être sous-estimée, selon le volume de code source. Pour ces raisons, la suppression des auteurs n'est pas recommandée. Les noms peuvent être publiés si a) le consentement des personnes concernées a été obtenu et b) aucun motif relevant de la sécurité ne s'y oppose. + +=== Prise en compte des licences des bibliothèques + +Pratiquement chaque projet utilise des bibliothèques de tiers (bibliothèques logicielles, dépendances) afin d'accéder à des fonctions couramment utilisées sans devoir les programmer. Ces bibliothèques dépendent généralement d'autres bibliothèques, ce qui engendre des dépendances à plusieurs niveaux (dépendances transitives). Selon le langage de programmation, même de petits projets peuvent compter des centaines de dépendances. + +Les résultats de cette clarification doivent être pris en compte lors du choix de la licence conformément au link:em002-3.pdf[Em002-3 Guide de licences OSS] et dans la link:em002-2-3-checklist-oss-release-and-publication.pdf[liste de contrôle Em002-2.3 Validation et publication OSS]. + +Pour chacune de ces dépendances, il convient de s'assurer que sa licence est compatible avec celle du projet. Sont particulièrement problématiques les dépendances qui ne sont pas sous licence open source, qui n'ont déclaré aucune licence ou qui utilisent une licence virale ne correspondant pas à celle du projet. Certaines bibliothèques sont placées sous plus d'une licence et laissent à l'utilisateur le choix de l'une d'elles. + +* Dans tous les principaux langages de programmation, les dépendances du projet (y compris les dépendances transitives) et leurs licences peuvent être listées automatiquement. Il s'agit notamment de : +* Le plugin Project Info Reports pour le gestionnaire de paquets Apache Maven pour les projets Java, qui génère au moyen du rapport de dépendances une sortie HTML de toutes les bibliothèques utilisées, y compris la licence déclarée.footnote:[Infos sur le plugin https://maven.apache.org/plugins/maven-project-info-reports-plugin/plugin-info.html] +* Le NPM Licence Checker pour le gestionnaire de paquets NPM pour les projets JavaScript, qui peut restituer toutes les bibliothèques utilisées, y compris la licence déclarée, dans différents formats, p. ex. CSV.footnote:[NPM Licence Checker https://github.com/davglass/license-checker] +* Le Licence Finder de Pivotal, qui prend en charge divers gestionnaires de paquets et langages de programmation, dont Ruby Gems, Python Eggs et Godeps.footnote:[Licence Finder de Pivotal https://github.com/pivotal/LicenseFinder] + +== Utilisation de bibliothèques sous licence propriétaire + +Les bibliothèques sous licence propriétaire sont en principe problématiques dans les projets open source et ne peuvent généralement pas être utilisées, en particulier si le code source a été publié sous une licence virale telle que l'AGPL. + +Veuillez vous adresser au fournisseur et au service juridique de l'office concerné afin de vérifier si et à quelles conditions la bibliothèque propriétaire peut être utilisée dans votre projet. + +=== Utilisation de gestionnaires de paquets + +Pratiquement tous les langages de programmation répandus proposent des gestionnaires de paquets pour gérer leurs dépendances, tels qu'Apache Maven pour les projets Java, NPM pour les projets JavaScript ou NuGet pour les projets .NET. + +Lors de l'utilisation d'un gestionnaire de paquets, les dépendances utilisées par le projet ne font plus directement partie du code source de celui-ci, par exemple par la copie du code source de la dépendance dans le projet ou par la copie des dépendances sous forme binaire. Le projet obtient au contraire toutes ses dépendances via les déclarations du gestionnaire de paquets. + +Cela permet de lister et de référencer correctement toutes les dépendances. Cela empêche en outre la modification involontaire du code des dépendances. Si des modifications sont nécessaires, elles doivent être effectuées directement à la source de la dépendance. + +=== Déclaration de la licence du projet dans le descripteur du gestionnaire de paquets + +Le projet devrait déclarer sa licence dans le descripteur approprié du gestionnaire de paquets, au moyen de l'identifiant SPDX,footnote:[Identifiant SPDX – https://spdx.org/] afin que la licence du projet puisse être restituée par le gestionnaire de paquets. Cela est particulièrement important pour les bibliothèques, afin que leurs utilisateurs puissent interroger automatiquement leur licence via le gestionnaire de paquets. + +=== Attribution et mentions de copyright + +De nombreuses bibliothèques sont soumises à une licence qui exige de leur utilisateur une mention de copyright d'origine ou une attribution. + +Il s'agit notamment des licences suivantes (extrait) : + +Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons « Attribution » (CC BY), MIT, ISC + +Pour les autres, voir la liste des licences reconnues par l'OSI.footnote:[Les licences open source sont des licences conformes à l'Open Source Definition — en bref, elles permettent d'utiliser, de modifier et de partager librement un logiciel. https://opensource.org/licenses] + +Dans la pratique, cela concerne presque toutes les bibliothèques utilisées. Comme le nombre de bibliothèques utilisées est déjà très élevé dans les petits projets, une mention de copyright juridiquement correcte ou l'attribution nécessaire n'est possible qu'au prix d'efforts considérables. + +Il est donc recommandé de procéder comme suit : + +* Établir une liste des bibliothèques utilisées, au moyen des mécanismes du gestionnaire de paquets ou d'outils tels que le NPM Licence Checker ou le Licence Finder de Pivotal. +* Préparer la liste manuellement afin qu'elle contienne les informations suivantes : nom officiel du projet de la bibliothèque, site web du projet de la bibliothèque, licence utilisée pour la bibliothèque sous forme d'identifiant SPDX avec un lien vers le texte de la licence. +* Déposer la liste dans le code source du projet, p. ex. dans un fichier THIRD-PARTY-LICENSES.md. +* Pour les applications : intégrer un lien pointant vers THIRD-PARTY-LICENSES.md dans une boîte de dialogue « À propos » ou « À propos de cette application ». +* La boîte de dialogue « À propos » est largement utilisée à cette fin, par exemple dans Google Chrome (dans la boîte de dialogue « À propos de Chrome »). +* Pour les bibliothèques : renvoyer dans README.md à THIRD-PARTY-LICENSES.md. +* Dans le cadre du processus de revue de code, s'assurer que les modifications des bibliothèques sont reportées dans THIRD-PARTY-LICENSES.md. + +== Exemple de bloc de code THIRD-PARTY-LICENSES.md + +Ce projet utilise des logiciels open source : + +* Spring Boot, http://projects.spring.io/spring-boot/[projects.spring.io/spring-boot] sous licence http://www.apache.org/licenses/LICENSE-2.0[Apache-2.0] +* caniuse-db, https://github.com/Fyrd/caniuse[github.com/Fyrd/caniuse] sous licence https://creativecommons.org/licenses/by/4.0/[CC-BY-4.0] + +=== Documentation d'accompagnement de la liste de contrôle Em002-2.3 Validation et publication OSS + +==== Publication avec publiccode.yml + +Publiccode.yml est un standard de métadonnées pour les dépôts de logiciels contenant des logiciels développés ou acquis par des administrations publiques. L'objectif est de rendre ces logiciels plus faciles à trouver et à réutiliser. Le standard de métadonnées est établi à l'échelle internationale et décrit publiquement à l'adresse https://yml.publiccode.tools/. Un fichier publiccode.yml contient typiquement des informations telles que le titre et la description (possible en plusieurs langues), l'état de développement, les coordonnées de contact, les informations de licence, etc. Des extensions spécifiques au pays sont prévues pour la Suisse. + +Un fichier yml doit être créé dans le répertoire principal du dépôt pour chaque logiciel. Si la solution se compose de plusieurs dépôts (auxiliaires), un seul fichier suffit, celui-ci décrivant le cas d'application de la solution. + +À partir des données structurées contenues dans les fichiers publiccode.yml, un https://www.opensource.admin.ch/[catalogue OSS] (https://www.opensource.admin.ch[opensource.admin.ch]) est généré pour l'ensemble de l'administration fédérale. Le catalogue offre une vue d'ensemble des logiciels publiés et facilite la recherche et la réutilisation de solutions existantes. + +Si un nouveau dépôt ou une nouvelle organisation est créé, cela doit être annoncé par courriel à opensource@bk.admin.ch en vue de l'inscription au catalogue OSS. + +Outre le catalogue OSS, un éditeur graphique et un validateur pour les fichiers publiccode.yml sont également disponibles. + +Catalogue OSS et éditeur : https://www.opensource.admin.ch/ + +=== Autres sources et licence + +La liste de contrôle, la documentation d'accompagnement et les modèles qui s'y rapportent se fondent en partie sur les sources suivantes : + +* Google Open Source Docs de Google LLC, sous licence 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 de 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/] +endif::[] + +ifeval::["{lang}" == "it"] +*Avvertenza:* 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.footnote:[Raccomandazione per l'informatica dell'Amministrazione federale secondo ++[++P035++]++ _capitolo 4.6_]footnote:[Per le definizioni delle classificazioni INTERNO e CONFIDENZIALE si veda l'_ordinanza dell'8 novembre 2023 sulla sicurezza delle informazioni in seno alla Confederazione e all'esercito (OSIC; RS 128.1)_]footnote:[Cfr. nota a piè di pagina 1]footnote:[Ambiti di pianificazione secondo la _strategia TIC della Confederazione 2020-2023 del 3 aprile 2020 (SB000)_] Per maggiori informazioni si veda il {url-repo}/tree/main[README] principale. + +''''' + +== Riassunto per la direzione + +Le presenti istruzioni descrivono la procedura per la pubblicazione del codice sorgente del software che le autorità federali sviluppano o fanno sviluppare per adempiere i loro compiti, conformemente all'art. 9 LMeCA.footnote:[Legge federale _++[++EMOTA2023++]++_] Sono previste eccezioni se diritti di terzi o motivi rilevanti per la sicurezza escludono o limitano tale pubblicazione. Pubblicare significa che chiunque può utilizzare, sviluppare e diffondere il software. Non sono riscosse tasse di licenza. + +Le presenti istruzioni si rivolgono alle persone responsabili della pubblicazione del codice sorgente e incaricate della sua attuazione. + +[mermaid,align="center",alt="Panoramica del processo di pubblicazione OSS"] +.... +flowchart TD + S(["Inizio"]) + A["Valutazione preliminare"] + B["Analisi e preparazione"] + C["Pubblicazione"] + S --> A + A --> B + B --> C +.... + +La materia è suddivisa in tre parti principali: + +* La prima parte (capitolo 3) tratta le *valutazioni preliminari* e le eccezioni secondo la LMeCA. +* La seconda parte (capitolo 4), *Analisi e preparazione*, esamina il codice sorgente e lo prepara secondo le necessità. Vi si effettua inoltre la scelta della licenza. +* La terza parte (capitolo 5), *Pubblicazione e annuncio*, descrive la pubblicazione vera e propria e ulteriori misure quali la comunicazione e la costituzione di una community adeguata. + +*Tre liste di controllo* accompagnano e documentano il processo. + +Complementi tecnici figurano nell'allegato. + +== Introduzione + +Nella pubblicazione di software open source occorre distinguere tra il *contributo di codice sorgente e documentazione a software open source esistente* e la *pubblicazione come progetto open source indipendente*. + +Il primo caso comprende tipicamente correzioni di errori ed estensioni funzionali. A seconda del tipo di licenza e dell'impiego del software, il codice sorgente deve o può essere pubblicato sotto la licenza esistente del progetto open source. Può essere necessario rispettare un accordo di pubblicazione. + +Nel secondo caso, l'avvio di un nuovo progetto open source, la governance e la licenza possono in linea di principio essere scelte liberamente. L'unico elemento da considerare è la licenza sotto la quale sono pubblicati gli eventuali elementi software integrati nel nuovo progetto. Ulteriori dettagli sulla scelta della licenza figurano nel documento link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. Se da una community può derivare un valore aggiunto per l'Amministrazione federale o se questa intende creare un ecosistema, va inoltre compilata la link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS] conformemente alla link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +La pubblicazione di software open source è più di una semplice misura tecnica. Significa anche instaurare una cultura dell'apertura corrispondente e coinvolgere le persone. Una cultura open source di successo è una combinazione di apertura, eccellenza tecnica, forte interazione sociale e impegno condiviso. + +Il grafico seguente descrive le istruzioni e le diverse configurazioni. + +[mermaid,align="center",alt="Albero decisionale per la pubblicazione di software"] +.... +flowchart TD + Start(["Inizio
sviluppato dal 1.1.2024"]) + subgraph B1["1. Valutazione preliminare"] + T{"Tipo di software"} + end + subgraph B2["2. Analisi e preparazione"] + I{"I terzi sono
interessati al software?"} + GJ["Chiarire la governance e
la collaborazione [Em002-4.1]"] + GT["Chiarire la governance e
la collaborazione [Em002-4.1]"] + O{"Sviluppo di software
open source?"} + end + subgraph B3["3. Pubblicazione"] + M["Effettuare una pubblicazione minima"] + P["Pubblicazione del software"] + D["Sviluppo di software
open source"] + C["Costituire e curare
una community [Em002-4]"] + end + Start --> T + T -->|"Sviluppo proprio"| I + T -->|"Sviluppo congiunto"| GJ + T -->|"Progetto di terzi"| GT + I -->|"No"| M + I -->|"Sì, o ipotizzabile"| O + GJ --> O + GT --> D + O -->|"No"| P + O -->|"Sì"| D + P --> C + D --> C + M --> E1(["Fine"]) + C --> E2(["Fine"]) +.... + +Figura 1 – Albero decisionale per la pubblicazione di software + +== Processo di valutazione preliminare + +*Obiettivo:* comprendere i vantaggi e le possibili conseguenze di una pubblicazione del software. Decidere se il software può essere pubblicato e, in caso affermativo, se la costituzione di una community attiva ne vale la pena. Nota: la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare OSS] dovrebbe essere compilata il prima possibile nel progetto, poiché ciò può influenzare il modo in cui il software viene sviluppato. + +=== Pubblicazione secondo la LMeCA + +Secondo l'art. 9 della legge federale del 17 marzo 2023 ++[++EMOTA2023++]++ sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA), l'Amministrazione federale (concretamente l'art. 2 cpv. 1) deve pubblicare il codice sorgente del software che sviluppa o fa sviluppare per adempiere i suoi compiti. Si applicano eccezioni se diritti di terzi o motivi rilevanti per la sicurezza lo escludono o lo limitano. + +Per il software su misura realizzato su mandato della Confederazione si applicano in linea di principio le condizioni generali della Confederazione ++[++BBL-AGB++]++. Secondo il loro numero 25.1, la proprietà del codice sorgente e della documentazione passa al servizio acquirente (la Confederazione). Se il software è stato acquistato congiuntamente da più organizzazioni o altre istituzioni, occorre verificare chi detiene i diritti sul codice. La proprietà può per esempio spettare a un'associazione costituita a tale scopo. + +Il semplice utilizzo di software standard non rientra nell'art. 9 LMeCA e una pubblicazione non sarebbe comunque di regola possibile, poiché i diritti sul software standard restano spesso al fornitore (CG della Confederazione per l'acquisto di software standard). Le estensioni su misura di software standard si prestano invece pienamente a una pubblicazione. Esse appartengono normalmente alla Confederazione. Meri adattamenti di configurazione si prestano meno a una pubblicazione. Il tema è trattato in link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e del software open source] nonché nei documenti ++[++KBB-MB++]++ e ++[++BBL-WL++]++. In linea di principio le estensioni sottostanno sempre all'art. 9 LMeCA. + +==== Il software in rapporto alla LMeCA + +L'attuale norma ISO/IEC 24765 contiene tre definizioni di software: + +. un programma o un insieme di programmi utilizzati per far funzionare i computer +. i programmi e la relativa documentazione +. i programmi e, ove applicabile, la documentazione associata nonché altri dati necessari al funzionamento del computer. + +Sulla base di questa definizione anche script, macro o Infrastructure as Code (IaC) di minore entità sono classificati come software. La LMeCA si riferisce al codice sorgente all'articolo 9 capoverso 1. Secondo tale interpretazione una pubblicazione ai sensi della definizione 1 sarebbe sufficiente. Una pubblicazione priva della documentazione associata ha tuttavia scarso valore, poiché il software non può essere utilizzato ai sensi della definizione 2. + +Per realizzare sinergie con terzi occorre basarsi sulla definizione 3. Riguardo ai dati ciò significa concretamente i dati di base e le configurazioni di base (per esempio valori di enumerazione e dati di base che dovrebbero parimenti essere resi disponibili come open source). + +Progetti, script o esempi di codice di minore entità possono anche essere pubblicati congiuntamente in un unico repository, se l'autorità federale lo ritiene opportuno. In tal caso le presenti istruzioni e le corrispondenti liste di controllo possono essere compilate una sola volta. + +Nel decidere che cosa pubblicare e come, occorre considerare la proporzionalità e l'onere. + +==== Tipo di software + +Come mostra la figura 1, si distingue tra sviluppo proprio, sviluppo congiunto e progetti di terzi. Ogni costellazione comporta implicazioni diverse. Indipendentemente da come il software viene sviluppato, esso rientra nell'art. 9 LMeCA. + +Nello sviluppo proprio la Confederazione crea essa stessa il software o lo fa creare di conseguenza. Sceglie la governance e conserva i diritti sul codice sorgente. + +Nello sviluppo congiunto la Confederazione crea il software insieme ad altre organizzazioni. La governance e i diritti sul software devono essere disciplinati mediante la forma organizzativa scelta. + +Se la Confederazione contribuisce direttamente a software di terzi, anche tale codice sorgente rientra nell'art. 9 LMeCA. Occorre assicurare che ciò avvenga nell'interesse delle autorità federali, che la partecipazione soddisfi i requisiti del progetto e che l'Amministrazione federale rispetti la governance. + +Ciò avviene mediante la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare OSS] e la link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS]. + +==== Codice preesistente + +Per il software datato (*software preesistente*) l'onere successivo per una pubblicazione è maggiore rispetto al caso in cui essa fosse stata pianificata sin dall'inizio. Per il software preesistente vale la pena sostenere tale onere soltanto se un potenziale utente intende utilizzare il software. Indipendentemente da ciò, la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare OSS] dovrebbe essere compilata per documentare le decisioni determinanti. + +Le applicazioni il cui sviluppo è stato avviato dalle autorità federali il 1° gennaio 2024 o dopo tale data, oppure che sono sviluppate su mandato della Confederazione sulla base di un contratto concluso dopo il 1° gennaio 2024, non sono considerate preesistenti e sottostanno in ogni caso all'obbligo di pubblicazione secondo l'art. 9 cpv. 1 LMeCA. + +L'obbligo di pubblicazione secondo la LMeCA non dipende dall'utilità per i terzi. + +==== Librerie, plug-in e add-on + +In taluni casi il software non è un'applicazione autonoma, bensì soltanto una parte di essa. La LMeCA e l'ordinanza non definiscono ulteriormente il codice sorgente. Le istruzioni si applicano anche a librerie, plug-in e add-on disaccoppiati, che rientrano nella LMeCA. + +*Compiti:* + +* Raccogliere le informazioni contenute in link:em002-5.pdf[Em002-5 Promemoria Strumenti OSS]. Esso descrive sia informazioni generali sul software open source sia informazioni specifiche sull'applicazione della LMeCA. +* Verificare se le condizioni previste dalla LMeCA sono soddisfatte. +* Compilare la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare OSS]. Di regola è opportuno coinvolgere direttamente le persone di contatto del fornitore del software o del team di sviluppo. +* Se necessario, compilare la link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS]. + +*Decisione:* il software deve essere pubblicato e in che modo? + +=== Eccezione: diritti di terzi + +Occorre rinunciare a una pubblicazione se essa violerebbe diritti di terzi. Se il software è stato sviluppato da impiegati della Confederazione, i diritti spettano al datore di lavoro.footnote:[Art. 332 CO in combinato disposto con l'art. 6 cpv. 2 LPers] Nei contratti di fornitura di personale a prestito e di prestazioni informatiche i diritti sono di norma trasferiti alla Confederazione e dovrebbero essere fatti valere. + +Se il software è stato o viene sviluppato sulla base delle condizioni generali della Confederazione Svizzera (stato 2024),footnote:[Condizioni generali della Confederazione Svizzera, in particolare il numero 25.1 – https://www.bkb.admin.ch/bkb/de/home/themen/agb.html#accordion_21321111141713247349255] i diritti di proprietà intellettuale spettano al committente, salvo diversa pattuizione contrattuale. + +Un'applicazione è tipicamente composta da numerosi singoli componenti ed elementi. Per alcuni tipi ciò diventa problematico se essi stessi non sono open source o non possono essere pubblicati sotto una licenza open source nell'ambito dell'applicazione. + +*Librerie* + +A seconda del linguaggio di programmazione, le librerie sono compilate direttamente con l'applicazione, collegate oppure fornite come pacchetti. Esse costituiscono parte integrante dell'applicazione. + +Se l'applicazione contiene librerie proprietarie o soggette a licenza, l'open sourcing diventa più difficile. In linea di principio il codice sorgente del resto dell'applicazione può essere pubblicato, ma i potenziali utenti o sviluppatori dovrebbero acquistare la libreria in questione prima che l'applicazione diventi utilizzabile o estendibile. + +Se la proprietà della libreria problematica spetta al fornitore dell'applicazione, vale la pena chiedere un chiarimento giuridico per stabilire se la Confederazione disponga di diritti trasferibili su tali librerie. + +Ove possibile, le librerie proprietarie e soggette a licenza dovrebbero essere evitate negli sviluppi propri o sostituite se possibile prima della pubblicazione. Considerato l'obiettivo dell'articolo 9 LMeCA, occorre pubblicare il maggior numero possibile di funzionalità utilizzate dalle amministrazioni pubbliche. Singole librerie che impediscono la pubblicazione del codice rappresentano pertanto un debito tecnico che dovrebbe essere documentato e, all'occasione, eliminato. + +*Banche dati e altri sistemi di archiviazione* + +Se l'applicazione utilizza sistemi di archiviazione proprietari e soggetti a licenza quali Microsoft SQL Server, ciò non costituisce un ostacolo a una pubblicazione open source. + +Occorre tuttavia esaminare se possano essere supportate anche banche dati aperte quali PostgreSQL. Ciò può ridurre i costi d'esercizio e abbassare le barriere d'accesso per i potenziali utenti. + +*Server applicativi e sistemi operativi* + +Se l'applicazione richiede sistemi operativi o server applicativi sotto licenza (p. es. Microsoft Windows Server o RedHat JBoss), ciò non costituisce un ostacolo a una pubblicazione open source. + +Raccomandiamo di chiedere al fornitore del software se e quali librerie di terzi sotto licenza siano utilizzate come componenti dell'applicazione. + +Se la realizzazione del software è stata acquistata congiuntamente da più organizzazioni o altre istituzioni, la proprietà spetta di regola a un'associazione o a un'altra persona giuridica costituita a tale scopo. + +*Altra proprietà intellettuale* + +Tra i diritti di terzi rientrano non soltanto i diritti d'autore, ma anche altra proprietà intellettuale (marchi, brevetti). I brevetti non impediscono fondamentalmente che un software sia pubblicato come open source, ma possono impedirne l'utilizzo o l'estensione. Sebbene i brevetti siano piuttosto rari in Svizzera, di regola vale la pena chiedere brevemente al fornitore del software se sia già stato effettuato un esame. + +*Acquisizione dei diritti necessari* + +Per soddisfare le prescrizioni legali della LMeCA, l'autorità federale ha, in qualità di committente, la possibilità di assicurarsi i diritti sui risultati dei lavori. Tale presupposto per una pubblicazione può essere definito come criterio in sede di acquisto. L'acquisizione successiva dei diritti necessari sul software può risultare più complessa. + +Se l'autorità federale non intende pubblicare essa stessa il software, può per esempio delegare tale compito al mandatario o trasferire di conseguenza i diritti di pubblicazione. In tal caso essa trasferisce i diritti (e gli obblighi) necessari al fornitore e/o a terzi e li incarica della pubblicazione. Il diritto viene così di fatto trasferito a terzi a condizione della pubblicazione o del supporto del software corrispondente. + +Anche in questo caso ++[++KBB-MB++]++ contiene indicazioni importanti. + +*Procedura* + +[mermaid,align="center",alt="Processo di gestione dell'eccezione relativa ai diritti di terzi"] +.... +flowchart TD + S(["Inizio"]) + Q1{"Acquisto di una licenza o di una
soluzione esistente come oggetto
d'acquisto centrale?"} + Q2{"Gli sviluppi successivi
sono definibili?"} + Q3{"I diritti spettano
alla Confederazione?"} + Q4{"È necessaria l'acquisizione
di diritti di terzi?"} + Q5{"Una parte con diritti della
Confederazione può essere
delimitata in modo mirato?"} + R1["Eccezione giustificata:
diritti di terzi"] + R2["Pubblicazione parziale da
parte della Confederazione"] + R3["Pubblicazione da parte
della Confederazione"] + S --> Q1 + Q1 -->|"No"| Q3 + Q1 -->|"Sì"| Q2 + Q2 -->|"Sì"| Q3 + Q2 -->|"No"| R1 + Q3 -->|"Sì"| R3 + Q3 -->|"No"| Q4 + Q4 -->|"Sì"| R3 + Q4 -->|"No"| Q5 + Q5 -->|"Sì"| R2 + Q5 -->|"No"| R1 +.... + +Figura 2 – Eccezione: diritti di terzi (considerare sempre anche ++[++KBB-MB++]++ e link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e del software open source]) + +Un'eccezione giustificata per i diritti di terzi risulta non solo dall'acquisto di licenze o di software esistente, ma anche dallo sviluppo di software su software esistente sotto licenza. + +Una pubblicazione parziale è possibile nella costellazione seguente: il software contiene parti proprietarie o protette; queste possono essere distinte dallo sviluppo successivo; sono coinvolti altri diritti di proprietà intellettuale. + +*Compiti:* + +* Verificare se l'organizzazione detiene i diritti di protezione determinanti sul software. +* Verificare se i diritti possono essere acquisiti. +* Se necessario, ottenere l'autorizzazione scritta dei titolari dei diritti. +* Assicurarsi che l'applicazione non contenga parti proprietarie o protette. +* Verificare che non sussistano ostacoli dovuti alla protezione brevettuale (per quanto possibile e ragionevole). +* Verificare se la pubblicazione debba essere effettuata da terzi. +* Verificare se lo sviluppo debba basarsi sullo sviluppo di software open source (mediante la link:em002-4.pdf[Em002-4 Guida alle community OSS]). + +*Decisione:* il software può essere pubblicato senza violare diritti di terzi? + +=== Eccezione: motivi rilevanti per la sicurezza + +Il software che non può essere pubblicato per motivi rilevanti per la sicurezza è esentato dalla pubblicazione. + +I dati veri e propri di un software non sono interessati dalla pubblicazione del codice sorgente. Tali dati sono di regola sensibili e non vengono pubblicati. Può tuttavia accadere che, oltre ai dati di contenuto, determinati algoritmi e procedimenti visibili nel codice sorgente non debbano diventare pubblici (p. es. capacità cibernetiche offensive, dettagli del rilevamento delle frodi). La sicurezza può riferirsi alla riservatezza, all'integrità, alla disponibilità o alla tracciabilità. + +*Raccomandazione:* + +Il software dovrebbe essere sviluppato deliberatamente in modo che non sorga alcun rischio supplementare nemmeno in caso di pubblicazione del codice sorgente. L'ipotesi secondo cui la mancata pubblicazione protegge da attacchi riusciti è ingannevole («security through obscurity»). + +*Procedura:* + +[NOTE] +==== +Determinante è sempre il software e non la sua finalità. Il trattamento di dati critici non costituisce a priori un aspetto rilevante per la sicurezza. +==== + +[mermaid,align="center",alt="Processo di gestione dell'eccezione relativa ai motivi di sicurezza"] +.... +flowchart TD + S(["Inizio"]) + Q1{"Motivi rilevanti
per la sicurezza?"} + Q2{"Il software rilevante per la
sicurezza può essere disaccoppiato?"} + Q3{"Motivi temporanei?"} + M["Misure per
la pubblicazione"] + R1["Pubblicare una parte
del software"] + R2["Eccezione:
motivi rilevanti per la sicurezza"] + R3["Eccezione temporanea"] + R4["Pubblicare"] + S --> Q1 + Q1 -->|"Uno o più punti si applicano"| Q2 + Q1 -->|"Non applicabile"| Q3 + Q2 -->|"Sì"| R1 + Q2 -->|"No"| R2 + Q3 -->|"Uno o più punti si applicano"| R3 + Q3 -->|"Nessun motivo temporaneo"| M + M --> R4 +.... + +Figura 3 – Eccezione: motivi rilevanti per la sicurezza + +I motivi seguenti possono essere considerati rilevanti per la sicurezza a seconda del progetto: + +* La pubblicazione del software aumenterebbe sensibilmente un rischio per la sicurezza delle informazioni.footnote:[Legge sulla sicurezza delle informazioni, LSIn. Art. 6 Sicurezza delle informazioni. https://www.fedlex.admin.ch/eli/cc/2022/232/de#art_6] +* Per gli algoritmi di prevenzione delle frodi e analoghi si può se del caso rinunciare a una pubblicazione. +* Tecnologie di cibersicurezza particolarmente sensibili. +* Software essenziale per l'esercizio di infrastrutture critiche. +* Quando la pubblicazione violerebbe altre basi legali. + +I seguenti motivi temporanei possono ancora impedire una pubblicazione. Quest'ultima sarà tuttavia resa possibile in seguito mediante misure adeguate. + +* Il codice preesistente non ha ancora potuto essere ripulito e contiene eventualmente problemi rilevanti per la sicurezza. +* Gli audit di sicurezza del codice non sono ancora stati svolti. +* Il processo di sviluppo non è ancora sufficientemente maturo per consentire una pubblicazione sicura. Se il processo di sviluppo non è sufficientemente consolidato, è possibile che vengano pubblicate parti non destinate a terzi. Per esempio le direttive sui commenti al codice e la generazione dei dati di test devono essere adattate al nuovo scenario di pubblicazione e funzionare in modo affidabile. + +Mediante le misure seguenti il software può essere pubblicato nonostante i motivi rilevanti per la sicurezza: + +* Separare dal software le configurazioni (p. es. tipo di cifratura utilizzata). +* Esternalizzare in configurazioni o impostazioni le informazioni tecnicamente sensibili e non pubbliche (p. es. processi, calcoli). +* Pianificare, attuare ed esercitare regolarmente misure organizzative, personali e tecniche adeguate. +* Pianificare e svolgere attività di qualità adeguate al momento della pubblicazione. Cfr. il capitolo seguente «Analisi e preparazione». + +*Compiti:* + +* Esaminare il software quanto ai motivi rilevanti per la sicurezza che osterebbero a una pubblicazione. +* Stimare l'onere necessario per eliminare i motivi temporanei. +* Pianificare misure volte a separare le informazioni rilevanti per la sicurezza dal codice sorgente del software. +* Assicurarsi che l'applicazione non contenga procedimenti che non devono diventare pubblici. + +*Decisione:* + +Sussistono motivi imperativi rilevanti per la sicurezza che rendono impossibile la pubblicazione? + +=== Chiarimento della pubblicazione + +Questa fase chiarisce chi pubblicherà il software. Se il software è stato realizzato da un fornitore esterno, la pubblicazione può essere affidata anche a tale fornitore. In questa fase è importante stabilire dove sarà pubblicato il codice sorgente e definire una governance corrispondente. + +Se il software è stato sviluppato internamente alla Confederazione e questa non può o non intende pubblicarlo essa stessa, può essere conferito un mandato di pubblicazione a un fornitore oppure i diritti possono essere ceduti (trasferimento degli obblighi a terzi). + +*Pubblicazione minima e supporto* + +La LMeCA non prevede requisiti in materia di pubblicazione. Una pubblicazione minima del codice sorgente soddisfa la prescrizione legale. Non sono richieste ulteriori attività. La questione se e in quale misura sia offerto un supporto e con quale intensità il progetto sia curato può essere affrontata mediante la link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +*Sviluppo di software open source (OSSD)* + +Nello sviluppo di software open source (OSSD), oltre alla pubblicazione del codice sorgente, l'intero processo di sviluppo si svolge pubblicamente. Tutto, dai requisiti (issue) al codice sorgente, è trasparente. L'OSSD è supportato da strumenti di comunicazione pubblici (mailing list, forum ecc.), da un sistema di gestione delle versioni (git), da elenchi di errori e funzionalità, da una roadmap e da strumenti per sviluppatori. Grazie a questo metodo di lavoro trasparente ne beneficia l'intera community e diventa possibile la collaborazione oltre i confini organizzativi. Con questo approccio, al termine del progetto non è necessaria alcuna ulteriore attività di pubblicazione, poiché ciò è già stato considerato all'inizio del progetto. + +*Compiti* + +* Elaborare una stima approssimativa dell'onere per la fase di analisi. A seconda delle dimensioni e della complessità dell'applicazione, l'onere varia tra tre giorni e due settimane. +* Liberare risorse per le fasi successive, in particolare per l'analisi. +* Approvare in linea di principio la pubblicazione dell'applicazione come open source. + +*Decisione:* + +L'accordo di principio e la fattibilità per pubblicare l'applicazione come open source sono dati. + +=== Ridurre al minimo l'onere + +Le liste di controllo e le istruzioni sono strutturate in modo da ridurre al minimo l'onere legato alle pubblicazioni. Una pianificazione anticipata e coerente della pubblicazione all'inizio del progetto e uno sviluppo orientato alla pubblicazione riducono al minimo l'onere. Un certo onere amministrativo e determinati costi sono inevitabili ++[++Le2023++]++. Essi possono eventualmente essere recuperati mediante community con costi di sviluppo condivisi (cfr. link:em002-4.pdf[Em002-4 Guida alle community OSS]). + +=== Scelta della lingua di pubblicazione + +La scelta della lingua deve tenere conto sia del potenziale pubblico target sia del metodo di lavoro del team. Fortunatamente le traduzioni sono diventate molto più semplici grazie ai nuovi strumenti. Entrano in considerazione le lingue ufficiali della Confederazionefootnote:[https://www.fedlex.admin.ch/eli/cc/1999/404/it#art_70] e l'inglese. + +Se il progetto ha rilevanza internazionale, l'inglese dovrebbe essere la lingua target. Per una pubblicazione successiva un cambio di lingua ha naturalmente poco senso. + +Come minimo il file README.md dovrebbe essere disponibile in più lingue, affinché gli interessati possano vedere subito se il progetto è rilevante per loro. + +La comunicazione pubblica dovrebbe considerare in primo luogo il pubblico target. Occorre inoltre tenere presente che si tratta di comunicazione pubblica della Confederazione. + +*Nota*: con la pubblicazione l'Amministrazione federale accede a un nuovo canale di comunicazione pubblica. Se ciò non avviene con cura e professionalità, l'immagine pubblica della Confederazione può rapidamente risentirne. + +== Analisi e preparazione + +*Obiettivo:* i lavori necessari a una pubblicazione open source sono conclusi. Le decisioni relative alla licenza e al tipo di community sono state prese. Ciò avviene mediante la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[lista di controllo Em002-2.2 Analisi e preparazione OSS]. + +=== Analisi del codice sorgente + +Il codice sorgente da pubblicare e gli altri documenti correlati sono analizzati prima della pubblicazione. Tale analisi garantisce che non vengano pubblicate informazioni confidenziali. + +Se è prevista la pubblicazione di un ampio volume di codice sorgente, si raccomanda di utilizzare strumenti automatizzati adeguati per le attività seguenti. + +I dettagli sono definiti nella sezione E. + +*Compiti* + +* Verificare come sono state attuate la qualità del codice esistente e le direttive (p. es. ISO/IEC 25010:2023footnote:[ISO/IEC 25010:2023 - Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.iso.org/standard/78176.html]). +* Assicurarsi che non siano contenuti dati (di test) sensibili, p. es. dati basati su persone o casi reali. +* Aggiornare la documentazione del software (cfr. allegato). +* Cancellare i file superflui o i documenti e dati obsoleti. +* Verificare il codice sorgente alla ricerca di segreti o credenziali.footnote:[https://www.ncsc.admin.ch/ncsc/it/home/aktuell/im-fokus/2022/git.html] +* Svolgere test di sicurezza mirati e istituire in seguito un programma di bug bounty (pubblico).footnote:[https://www.ncsc.admin.ch/ncsc/it/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Verificare tutte le librerie utilizzate quanto alle licenze e allestire i relativi elenchi (attribuzioni). Se una libreria è disponibile sotto più licenze, ciò va indicato di conseguenza negli elenchi. +* Descrivere il deployment (pipeline CI/CD) ed eventualmente allestire un'istanza dimostrativa. + +Queste attività sono indipendenti dalla pubblicazione, ma costituiscono presupposti per una buona qualità del software e per garantire la conformità. L'osservanza di tali misure semplifica la collaborazione, accresce la qualità dei contributi esterni e migliora l'immagine del software o dell'autorità. + +=== Scelta della licenza + +*Cfr. link:em002-3.pdf[Em002-3 Guida alle licenze OSS].* + +Andrebbero utilizzati testi di licenza affermati a livello internazionale, ove ciò sia possibile e opportuno. Le pretese di responsabilità dei licenziatari vanno escluse nella misura consentita dal diritto. + +*Compiti* + +* Verificare eventuali dipendenze da licenze esistenti. +* Per il codice di terzi, verificare la compatibilità delle condizioni d'uso con la licenza prevista e, se necessario, sostituire il codice.footnote:[Cfr. Em002-3 riguardo alla scelta di codice o librerie di terzi per uno stack tecnologico e riguardo alla compatibilità della licenza.] +* Scegliere la licenza adeguata. + +La compatibilità delle licenze può essere verificata con strumenti quali ORT Toolkit,footnote:[https://oss-review-toolkit.org/] Black Duck,footnote:[https://www.blackducksoftware.com] FOSSAfootnote:[https://www.fossa.com] o FOSSology.footnote:[https://www.fossology.org] Il ToDo Group footnote:[https://landscape.todogroup.org/] offre una panoramica aggiornata degli strumenti. + +*Decisione:* + +* Stabilire e documentare sotto quale licenza il software sarà pubblicato. + +=== Documentazione open source + +Con la pubblicazione si attende un minimo di documentazione. Nell'ecosistema open source si sono affermati diversi documenti. Essi offrono ai visitatori una rapida panoramica del software, licenza compresa. + +Sono attesi i documenti seguenti: + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Documento* |*Descrizione / contenuto:* +|README(.md) |Funge da documento introduttivo e offre una rapida panoramica di scopo, portata, stato, licenza e gruppi target del progetto. +|LICENSE |Descrizione della licenza scelta nel progetto +|CONTRIBUTING(.md) |Descrive il processo per contribuire al progetto. +|CODE++_++OF++_++CONDUCT(.md) |Il codice di condotta stabilisce le norme sociali attese all'interno del progetto. +|CHANGELOG(.md) |Tiene un elenco delle modifiche nelle versioni del software. +|THIRD-PARTY-LICENSES(.md) |Descrizione delle licenze di terzi o dei componenti utilizzati. +|Getting started |Breve guida all'installazione e all'utilizzo del software. +|Create Gitignore |Descrive i documenti che non saranno pubblicati, p. es. configurazioni, dati di test o contenuti generati. Le informazioni protette e sensibili dovrebbero essere gestite al di fuori del progetto, in strumenti e archivi appositi e adeguati. +|publiccode.yml |Metadati strutturati per la descrizione del software, sulla base dello standard https://yml.publiccode.tools/. Il formato definito rende la pubblicazione più facilmente reperibile e riutilizzabile. Ulteriori informazioni nell'allegato F. +|=== + +Tabella 1 – Documenti open source + +Ulteriori dettagli tecnici su questi documenti sono descritti nell'allegato. + +*Compiti* + +* Allestire la documentazione standard. +* Riportare copyright, indicazioni di licenza e clausola di esclusione della responsabilità in tutti i file. +* A seconda della piattaforma di pubblicazione possono essere aggiunte descrizioni supplementari. + +*Decisione:* + +* Decisione definitiva di pubblicare l'applicazione come open source. + +== Pubblicazione e annuncio + +*Obiettivo:* l'applicazione è pubblicata come open source e facilmente reperibile da terzi. Tutti i componenti sono pronti per la pubblicazione e la community è costituita o consolidata. Ciò avviene mediante la link:em002-2-3-checklist-oss-release-and-publication.pdf[lista di controllo Em002-2.3 Rilascio e pubblicazione OSS]. In una certa misura si tratta di ricapitolare decisioni già prese. + +=== Scelta della piattaforma + +Esistono diversi modi per pubblicare codice sorgente. La tabella seguente offre una panoramica dei possibili sistemi di gestione del codice sorgente (SCM) e delle piattaforme. + +La piattaforma adeguata va scelta prima della pubblicazione vera e propria. Alcune autorità federali sono già presenti su GitHub.footnote:[Il sito https://ossbenchmark.com offre una panoramica delle organizzazioni e autorità attive su GitHub.] In tal caso è opportuno utilizzare piattaforme già consolidate. + +*Raccomandazione:* + +Attualmente raccomandiamo di istituire un'organizzazione su GitHub per ogni autorità federale ai fini della pubblicazione del codice sorgente. All'interno di tale organizzazione possono essere creati i progetti (repository) corrispondenti e gestiti gli utenti con le relative autorizzazioni. In futuro dovrebbe essere istituita una piattaforma federale centrale. Per garantire una gestione ottimale degli utenti e preservare la reputazione della Confederazione Svizzera, è importante utilizzare un numero minore di repository, ma meglio gestiti. + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Piattaforma* |*Caratteristiche* +|GitHubfootnote:[https://github.com/about/] |Piattaforma online di Microsoft, ampiamente diffusa. Una grande quantità di software open source è ospitata su GitHub. Offre molti strumenti supplementari oltre all'SCM. Disponibile in versione Free ed Enterprise (abbonamento). +|GitLabfootnote:[https://about.gitlab.com/] |Piattaforma online dell'omonima impresa GitLab, essa stessa pubblicata sotto una licenza open source. Offre molti strumenti supplementari oltre all'SCM. Può anche essere gestita localmente, offrendo così un certo grado di sovranità. Disponibile in versione Free ed Enterprise (abbonamento). +|Bitbucketfootnote:[https://bitbucket.org/product/en] |Piattaforma online di Atlassian, specificamente integrata nel suo ecosistema. Disponibile in versione Free ed Enterprise (abbonamento). +|Sistema SCM interno |Se è messa a disposizione una piattaforma SCM propria, anch'essa può pubblicare e rendere disponibili determinati repository o progetti. L'esercizio deve essere assicurato. +|Piattaforma federale |Attualmente non esiste una piattaforma federale centrale per la pubblicazione di software. Una misura in tal senso è proposta in link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale]. +|Sito web, server FTP pubblico ecc. |La LMeCA non definisce come il software debba essere pubblicato. Una pubblicazione minimafootnote:[Una pubblicazione minima comprende soltanto la pubblicazione del codice sorgente e di altri artefatti minimi. Questo tipo di pubblicazione soddisfa le prescrizioni della LMeCA. Con essa non si consegue tuttavia alcun valore aggiunto.] può avvenire anche su un sito web o altre risorse accessibili al pubblico. Ciò non è tuttavia adatto a una collaborazione duratura nel senso dell'open source. +|=== + +Tabella 2 – Piattaforme per la pubblicazione di software open source + +Se il software è pubblicato congiuntamente a un partner o a un'organizzazione esterna, occorre assicurarsi che siano disponibili le autorizzazioni e gli accessi adeguati al codice sorgente. + +*Compiti* + +* Valutare la piattaforma adeguata, compresa l'organizzazione o il progetto corrispondente. +* Se non ancora chiarito, stabilire la denominazione del progetto o del repository. +* Definire e verificare le autorizzazioni sul repository. +* Assicurare una governance adeguata e un'eventuale replica del codice sorgente. + +*Decisione:* + +* La piattaforma per la pubblicazione è stata scelta in modo appropriato. + +=== Pubblicazione del software + +Una volta chiariti i presupposti, il software può essere pubblicato. + +*Compiti* + +* Verificare i presupposti mediante la link:em002-2-3-checklist-oss-release-and-publication.pdf[lista di controllo Em002-2.3 Rilascio e pubblicazione OSS]. +* L'accesso alla piattaforma è disponibile e la governance è chiarita. +* Pubblicazione del codice sorgente e della documentazione da parte del team di sviluppo. + +=== Comunicazione + +Dopo la pubblicazione vera e propria, ulteriori attività di comunicazione possono essere avviate dall'autorità federale interessata e al suo interno. Esse favoriscono la diffusione e apportano il valore aggiunto desiderato dalla pubblicazione. + +*Compiti* + +* Descrizione nell'hosting del repository, impostazioni di sicurezza ecc. +* Comunicazione interna ed eventualmente esterna +* Redigere un messaggio destinato alla community. +* Far conoscere l'applicazione all'interno dell'organizzazione e negli organi specializzati, promuoverne l'utilizzo e i contributi. +* Creare un file publiccode.ymlfootnote:[Lo standard di metadati https://yml.publiccode.tools/ descrive il software. Il formato definito rende la pubblicazione più facilmente reperibile e riutilizzabile. Ulteriori informazioni nell'allegato F.] nel repository per il catalogo OSS dell'Amministrazione federale.footnote:[Catalogo OSS: https://www.opensource.admin.ch] + +=== Costituzione e cura della community + +Pubblicando un software può nascere una community in grado di contribuire allo stesso mediante contributi (pull request), domande, proposte di documentazione ecc. Per disporre di una community attiva è necessario un onere considerevole sia per la costituzione sia per la cura continua. Una community ben funzionante riduce al minimo i fork indesiderati del software. L'obiettivo è qui attivare il valore aggiunto della community mediante attività mirate. Anche in caso di pubblicazione minima andrebbe definito come trattare riscontri e domande sul software. + +*Compiti* + +* Chiarire chi siano i potenziali utenti o gli interessati. +* Determinare la forma adeguata per l'applicazione concreta mediante la link:em002-4.pdf[Em002-4 Guida alle community OSS]. +* Costituire la community. +* Attività di costituzione della community. + +== Allegato + +=== Modifiche rispetto alla versione precedente + +* Capitoli 4.3 e 5.3: pubblicazione completata con publicode.yml +* È stato aggiunto l'allegato F «Public Code» +* Diverse modifiche e miglioramenti redazionali minori + +=== Riferimenti + +Cfr. _Em002 Linee guida strategiche per il software open source nell'Amministrazione federale_. + +=== Abbreviazioni + +Cfr. link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] ed link:em002-6.pdf[Em002-6 FAQ sull'OSS]. + +=== Documentazione di accompagnamento link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo Analisi e preparazione OSS] – Documentazione + +=== Documentazione del codice sorgente + +La documentazione dovrebbe far parte del codice sorgente del progetto, affinché le modifiche alla documentazione siano archiviate in modo inalterabile e la documentazione sia versionata parallelamente al progetto. Ciò garantisce automaticamente che la documentazione, se correttamente curata, non diverga dallo stato di sviluppo del progetto e che la documentazione relativa a versioni precedenti del progetto possa essere consultata in qualsiasi momento. + +Inoltre ciò offre a terzi la possibilità di contribuire facilmente a modifiche della documentazione. + +Come linguaggio di marcatura per la formattazione del testo andrebbe utilizzato Markdown, in quanto facile da scrivere, ampiamente diffuso e leggibile dalle macchine. I documenti Markdown sono inoltre visualizzati in un formato target ben leggibile da tutte le piattaforme correnti. I documenti Markdown possono essere resi in qualsiasi formato target indipendentemente dalla piattaforma utilizzata, mediante generatori di siti statici quali Jekyll, MkDocs, Gatsby o Sphinx, per esempio con le prescrizioni di identità visiva di un'amministrazione. + +=== Destinatari e struttura della documentazione + +La documentazione di progetto dovrebbe rivolgersi sia agli utenti finali sia agli specialisti tecnici e non concentrarsi quindi esclusivamente sulla tecnica. Per la scelta della lingua si veda il capitolo 3.6. Ciò favorisce la diffusione del software. + +Un file README.md funge da documento introduttivo. I file con questo nome sono riconosciuti da tutte le piattaforme correnti e visualizzati come punto d'ingresso alla documentazione.footnote:[Maggiori informazioni sulla creazione di un file readme: https://www.makeareadme.com/] + +README.md dovrebbe offrire una rapida panoramica di scopo, portata, stato, licenza e gruppi target del progetto. Concretamente README.md dovrebbe contenere i punti seguenti: + +* Nome del software +* Breve descrizione dello scopo e della funzione del software. Portata e possibili limiti +* Istruzioni d'installazione +* Utilizzo del software +* Rinvio a un'eventuale istanza dimostrativa +* Indicazioni di supporto e contatto +* Come contribuire al software open source (Contributing) +* Licenza utilizzata (Licence) +* Stato del progetto / stato di sviluppo + +=== Evidenziare l'open source e archiviare la licenza + +Subito dopo la dichiarazione d'intenti andrebbe indicato in modo chiaro e inequivocabile che il progetto è software open source. La licenza utilizzata dal progetto andrebbe indicata con il corrispondente identificatore SPDXfootnote:[Identificatore SPDX – https://spdx.org/about] e collegata al testo concreto della licenza contenuto nel file LICENSE. I modelli di licenza contengono tipicamente una parte variabile (p. es. nome del progetto, anno di copyright, nome dell'autore) da adattare nel file LICENSE. + +La maggior parte delle piattaforme riconosce le licenze contenute in un file LICENSE e offre informazioni chiare sulla licenza, p. es. una breve sintesi delle condizioni di licenza. + +Si raccomanda di aggiungere a ogni file sorgente creato un'intestazione minima di licenza e copyright. Le intestazioni esistenti nei file esistenti non andrebbero modificate. Se si contribuisce a un progetto con regole chiare sulle intestazioni, queste vanno rispettate. + +Per maggiori dettagli si veda: Producing Open Source Software: State That the Project is Free.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Stato di sviluppo attuale + +Per mostrare rapidamente lo stato del progetto, lo stato di sviluppo attuale andrebbe documentato in README.md. Per i lettori è importante sapere se il progetto si trova in uno stato maturo o all'inizio dello sviluppo, se è attivamente curato e con quale frequenza vengono pubblicate nuove versioni. + +Questa sezione può descrivere quale tipo di sostegno da parte di terzi sia attualmente più importante per il progetto. Potrebbe trattarsi per esempio di uno sviluppatore con conoscenze tecnologiche specifiche o di una persona incaricata di rielaborare la documentazione del progetto. + +Per maggiori dettagli si veda Producing Open Source Software: Development Status.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Istanza dimostrativa + +Per le applicazioni si raccomanda di mettere a disposizione un'istanza dimostrativa, affinché l'applicazione possa essere provata senza oneri d'installazione. A seconda del tipo di applicazione, l'istanza dimostrativa può essere l'installazione produttiva o un ambiente di test. È importante che i lettori possano accedere all'istanza corrispondente nel modo più autonomo e diretto possibile. + +In alternativa molti progetti open source mettono a disposizione strumenti per avviare facilmente l'applicazione. Ciò può avvenire per esempio mediante container, applicazioni portatili o script d'installazione. + +=== Persona di contatto specializzata e titolarità del progetto + +Il file README.md dovrebbe indicare la principale persona di contatto specializzata, affinché altre amministrazioni e organizzazioni interessate possano mettersi in contatto nel modo più diretto possibile. + +Gli indirizzi e-mail personali non andrebbero utilizzati. + +Il file README.md dovrebbe inoltre descrivere brevemente quale organizzazione sia titolare del progetto, in particolare se per esso è stata costituita un'associazione. + +== Documentazione d'installazione + +Per le applicazioni, README.md dovrebbe rinviare a una documentazione d'installazione che descriva i requisiti hardware e software, quali componenti infrastrutturali (per esempio banche dati) siano utilizzati e come l'applicazione possa essere installata ed esercita. + +=== Developer Guidelines + +Il punto d'ingresso alle Developer Guidelines andrebbe archiviato in un file Markdown CONTRIBUTING.md, collegato in README.md. Le Developer Guidelines fanno parte della documentazione estesa destinata agli sviluppatori che desiderano contribuire al progetto e si concentrano in primo luogo sulla collaborazione e la comunicazione nel progetto piuttosto che sulla tecnica. + +Le Developer Guidelines dovrebbero contenere i punti seguenti e rinviare se del caso ai documenti corrispondenti: + +* Un rinvio al codice di condotta del progetto. Il codice di condotta stabilisce le norme sociali attese all'interno del progetto. +* Si raccomanda di scegliere come codice di condotta il Contributor Covenant Code of Conduct, pubblicato sotto licenza CC-BY-4.0,footnote:[https://creativecommons.org/licenses/by/4.0/] oppure di basarvisi.footnote:[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html] +* Un'indicazione secondo cui il progetto effettua revisioni del codice sotto forma di pull request GitHub, con rinvio alla documentazione GitHub sulle pull request. + +Infine occorre rinviare alla Developer Documentation. + +=== Developer Documentation + +Mentre le Developer Guidelines descrivono la collaborazione e le norme sociali del progetto, la Developer Documentation si concentra sugli aspetti tecnici della partecipazione allo sviluppo del progetto. Essa dovrebbe descrivere almeno i punti seguenti: + +* Quali dipendenze tecniche presenta il progetto e quali strumenti sono necessari per il suo sviluppo. +* Quali regole formali si applicano al codice sorgente del progetto, per esempio in materia di formattazione. +* Come è organizzato il codice sorgente del progetto e come le funzioni possono essere testate tecnicamente. +* Uno schizzo dell'architettura con una descrizione sommaria della stessa, preferibilmente con delimitazione del contesto e vista sommaria dei componenti.footnote:[Quadro architetturale MMB (metodo di modellizzazione della Confederazione) o arc42. http://arc42.org/] +* Per le applicazioni: come l'applicazione può essere avviata a scopo di sviluppo o debug e quali componenti infrastrutturali sono necessari a tal fine. + +== Documentazione di accompagnamento della link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[lista di controllo Em002-2.2 Analisi e preparazione OSS] – Codice sorgente + +=== Cronologia del codice sorgente + +Il codice sorgente di un progetto è di norma archiviato in un sistema di gestione del codice sorgente (SCM) quale GitHub. Tali sistemi memorizzano non soltanto lo stato attuale del codice sorgente, ma anche le modifiche apportate nel tempo. Ciò comprende in particolare le cancellazioni nel codice sorgente, inclusi i file cancellati. + +L'SCM contiene inoltre metainformazioni sulle modifiche del codice sorgente, quali il nome e l'indirizzo e-mail dell'autore o le firme PGP per commit e tag firmati. + +=== Dati sensibili, protetti o confidenziali + +Il codice sorgente e la sua cronologia possono contenere dati accessibili al pubblico, quali un elenco dei codici postali, dati generati casualmente o dati sintetici. + +Il codice sorgente e la sua cronologia non devono contenere dati o informazioni (personali) sensibili o confidenziali ai sensi della legge federale sulla protezione dei dati (LPD) e della legge sulla sicurezza delle informazioni (LSIn). Ciò comprende in particolare: + +* Nomi utente e password o altri segreti quali chiavi private, token di accesso o certificati. +* Nomi DNS interni, URL, nomi host, indirizzi IP, strutture di rete o nomi di unità. +* Nomi, indirizzi, immagini o dati personali analoghi senza il consenso della persona interessata +* Dati anonimizzati o pseudonimizzati (poiché è possibile annullare l'anonimizzazione o la pseudonimizzazione) + +Anche se lo stato attuale del codice sorgente è privo di dati o informazioni sensibili, protetti o confidenziali, tali dati o informazioni possono comunque essere recuperati dalla cronologia del sistema SCM se in passato hanno mai fatto parte del codice sorgente o delle metainformazioni dell'SCM. La pulizia dello stato attuale del codice sorgente non rimuove completamente tali informazioni.footnote:[Una possibilità per ripulire un repository è offerta dallo strumento https://rtyley.github.io/bfg-repo-cleaner/[BFG Repo-Cleaner]] + +In caso di dubbio si raccomanda pertanto di rimuovere completamente la cronologia dopo la pulizia del codice sorgente, prima di pubblicare quest'ultimo. + +I nomi e gli indirizzi e-mail degli autori del codice sorgente sono di norma disponibili direttamente nel codice sorgente o nei metadati dell'SCM, per esempio nei commit GitHub o nei tag GitHub annotati. Dal profilo giuridico ciò non è problematico, poiché spetta all'impresa di sviluppo disciplinare la pubblicazione di tali informazioni. Si raccomanda tuttavia di sensibilizzare l'impresa di sviluppo o i collaboratori interni della Confederazione sul fatto che i nomi e gli indirizzi e-mail degli autori del codice sorgente possono essere divulgati al momento della pubblicazione del software. + +=== Rimozione delle indicazioni sugli autori + +La cronologia del software può essere modificata per nascondere le indicazioni sugli autori. Alcuni strumentifootnote:[https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/] possono automatizzare ampiamente questa fase. + +La rimozione delle indicazioni sugli autori elimina l'attribuzione, la tracciabilità e le informazioni di contatto. L'onere che ne deriva non va sottovalutato, a seconda del volume di codice sorgente. Per questi motivi la rimozione degli autori non è raccomandata. I nomi possono essere pubblicati se a) è stato ottenuto il consenso delle persone interessate e b) non vi si oppongono motivi rilevanti per la sicurezza. + +=== Considerazione delle licenze delle librerie + +Praticamente ogni progetto utilizza librerie di terzi (librerie software, dipendenze) per accedere a funzioni di uso frequente senza doverle programmare. Tali librerie dipendono di norma da altre librerie, con conseguenti dipendenze a più livelli (dipendenze transitive). A seconda del linguaggio di programmazione, anche piccoli progetti possono presentare centinaia di dipendenze. + +I risultati di tale accertamento vanno considerati nella scelta della licenza conformemente alla link:em002-3.pdf[Em002-3 Guida alle licenze OSS] e nella link:em002-2-3-checklist-oss-release-and-publication.pdf[lista di controllo Em002-2.3 Rilascio e pubblicazione OSS]. + +Per ciascuna di tali dipendenze occorre assicurarsi che la sua licenza sia compatibile con quella del progetto. Sono particolarmente problematiche le dipendenze che non sono soggette a una licenza open source, che non hanno dichiarato alcuna licenza o che utilizzano una licenza virale non corrispondente a quella del progetto. Alcune librerie sono licenziate sotto più di una licenza e consentono all'utente di sceglierne una. + +* In tutti i principali linguaggi di programmazione le dipendenze del progetto (comprese quelle transitive) e le relative licenze possono essere elencate automaticamente. Tra questi figurano: +* Il plugin Project Info Reports per il gestore di pacchetti Apache Maven per progetti Java, che mediante il rapporto sulle dipendenze genera un output HTML di tutte le librerie utilizzate, licenza dichiarata compresa.footnote:[Info sul plugin https://maven.apache.org/plugins/maven-project-info-reports-plugin/plugin-info.html] +* Il NPM Licence Checker per il gestore di pacchetti NPM per progetti JavaScript, che può restituire tutte le librerie utilizzate, licenza dichiarata compresa, in vari formati, p. es. CSV.footnote:[NPM Licence Checker https://github.com/davglass/license-checker] +* Il Licence Finder di Pivotal, che supporta diversi gestori di pacchetti e linguaggi di programmazione, tra cui Ruby Gems, Python Eggs e Godeps.footnote:[Licence Finder di Pivotal https://github.com/pivotal/LicenseFinder] + +== Utilizzo di librerie con licenze proprietarie + +Le librerie soggette a una licenza proprietaria sono in linea di principio problematiche nei progetti open source e di regola non possono essere utilizzate, in particolare se il codice sorgente è stato pubblicato sotto una licenza virale quale l'AGPL. + +Vi preghiamo di rivolgervi al fornitore e al servizio giuridico dell'ufficio interessato per verificare se e a quali condizioni la libreria proprietaria possa essere utilizzata nel vostro progetto. + +=== Utilizzo di gestori di pacchetti + +Praticamente tutti i linguaggi di programmazione diffusi mettono a disposizione gestori di pacchetti per amministrare le proprie dipendenze, quali Apache Maven per i progetti Java, NPM per i progetti JavaScript o NuGet per i progetti .NET. + +Utilizzando un gestore di pacchetti, le dipendenze impiegate dal progetto non fanno più direttamente parte del suo codice sorgente, per esempio mediante la copia del codice sorgente della dipendenza nel progetto o la copia delle dipendenze in forma binaria. Il progetto ottiene invece tutte le sue dipendenze tramite le dichiarazioni del gestore di pacchetti. + +Ciò consente di elencare e referenziare correttamente tutte le dipendenze. Impedisce inoltre la modifica involontaria del codice delle dipendenze. Se sono necessarie modifiche, esse vanno effettuate direttamente alla fonte della dipendenza. + +=== Dichiarazione della licenza del progetto nel descrittore del gestore di pacchetti + +Il progetto dovrebbe dichiarare la propria licenza nel descrittore appropriato del gestore di pacchetti, utilizzando l'identificatore SPDX,footnote:[Identificatore SPDX – https://spdx.org/] affinché la licenza del progetto possa essere restituita dal gestore di pacchetti. Ciò è particolarmente importante per le librerie, affinché i loro utenti possano interrogarne automaticamente la licenza tramite il gestore di pacchetti. + +=== Attribuzione e indicazioni di copyright + +Molte librerie sono soggette a una licenza che richiede al loro utente un'indicazione di copyright originale o un'attribuzione. + +Tra queste figurano le licenze seguenti (estratto): + +Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons «Attribution» (CC BY), MIT, ISC + +Per le altre si veda l'elenco delle licenze riconosciute dall'OSI.footnote:[Le licenze open source sono licenze conformi all'Open Source Definition — in breve, consentono di utilizzare, modificare e condividere liberamente il software. https://opensource.org/licenses] + +Nella pratica ciò riguarda quasi tutte le librerie utilizzate. Poiché il numero di librerie impiegate nei piccoli progetti è già molto elevato, un'indicazione di copyright giuridicamente corretta o l'attribuzione necessaria è possibile soltanto con un onere considerevole. + +Si raccomanda pertanto di procedere come segue: + +* Allestire un elenco delle librerie utilizzate, mediante i meccanismi del gestore di pacchetti o strumenti quali il NPM Licence Checker o il Licence Finder di Pivotal. +* Preparare manualmente l'elenco affinché contenga le informazioni seguenti: nome ufficiale del progetto della libreria, sito web del progetto della libreria, licenza utilizzata per la libreria sotto forma di identificatore SPDX con collegamento al testo della licenza. +* Collocare l'elenco nel codice sorgente del progetto, p. es. in un file THIRD-PARTY-LICENSES.md. +* Per le applicazioni: inserire un collegamento a THIRD-PARTY-LICENSES.md in una finestra di dialogo «Informazioni su» o «Informazioni su questa applicazione». +* La finestra di dialogo «Informazioni su» è ampiamente utilizzata a tale scopo, per esempio in Google Chrome (nella finestra «Informazioni su Chrome»). +* Per le librerie: rinviare in README.md a THIRD-PARTY-LICENSES.md. +* Nell'ambito del processo di code review, assicurarsi che le modifiche alle librerie siano riportate in THIRD-PARTY-LICENSES.md. + +== Esempio di blocco di codice THIRD-PARTY-LICENSES.md + +Questo progetto utilizza software open source: + +* Spring Boot, http://projects.spring.io/spring-boot/[projects.spring.io/spring-boot] sotto licenza http://www.apache.org/licenses/LICENSE-2.0[Apache-2.0] +* caniuse-db, https://github.com/Fyrd/caniuse[github.com/Fyrd/caniuse] sotto licenza https://creativecommons.org/licenses/by/4.0/[CC-BY-4.0] + +=== Documentazione di accompagnamento della lista di controllo Em002-2.3 Rilascio e pubblicazione OSS + +==== Pubblicazione con publiccode.yml + +Publiccode.yml è uno standard di metadati per repository di software contenenti software sviluppato o acquistato da amministrazioni pubbliche. L'obiettivo è rendere tale software più facilmente reperibile e riutilizzabile. Lo standard di metadati è affermato a livello internazionale ed è descritto pubblicamente all'indirizzo https://yml.publiccode.tools/. Un file publiccode.yml contiene tipicamente informazioni quali titolo e descrizione (possibile in più lingue), stato di sviluppo, indicazioni di contatto, informazioni sulla licenza ecc. Per la Svizzera sono previste estensioni specifiche per il Paese. + +Per ogni software va creato un file yml nella directory principale del repository. Se la soluzione si compone di più repository (ausiliari), è sufficiente un unico file, poiché esso descrive il caso d'applicazione della soluzione. + +Sulla base dei dati strutturati contenuti nei file publiccode.yml viene generato, per l'intera Amministrazione federale, un https://www.opensource.admin.ch/[catalogo OSS] (https://www.opensource.admin.ch[opensource.admin.ch]). Il catalogo offre una panoramica del software pubblicato e agevola il reperimento e il riutilizzo di soluzioni esistenti. + +Se viene creato un nuovo repository o una nuova organizzazione, ciò va segnalato per l'inserimento nel catalogo OSS all'indirizzo e-mail opensource@bk.admin.ch. + +Oltre al catalogo OSS è disponibile anche un editor grafico e validatore per i file publiccode.yml. + +Catalogo OSS ed editor: https://www.opensource.admin.ch/ + +=== Ulteriori fonti e licenza + +La lista di controllo, la documentazione di accompagnamento e i relativi modelli si basano in parte sulle fonti seguenti: + +* Google Open Source Docs di Google LLC, sotto licenza 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 di 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/] +endif::[] + +ifeval::["{lang}" == "rm"] +*Exclusiun da responsabladad:* 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.footnote:[Recumandaziun per l'informatica da l'administraziun federala tenor ++[++P035++]++ _chapitel 4.6_]footnote:[Per las definiziuns da las classificaziuns INTERN e CONFIDENZIAL vesair l'_ordinaziun dals 8 da november 2023 davart la segirezza da las infurmaziuns tar la Confederaziun e l'armada (OSIn; CS 128.1)_]footnote:[Vesair nota a pe 1]footnote:[Secturs da planisaziun tenor la _strategia TIC da la Confederaziun 2020-2023 dals 3 d'avrigl 2020 (SB000)_] Ulteriuras infurmaziuns chattais Vus en il {url-repo}/tree/main[README]. + +''''' + +== Resumaziun per la direcziun + +Questas instrucziuns descrivan il proceder per la publicaziun dal code da funtauna dal software che las autoritads federalas sviluppan u fan sviluppar per ademplir lur incumbensas, tenor l'art. 9 EMBAG.footnote:[Lescha federala _++[++EMOTA2023++]++_] Excepziuns datti, sche dretgs da terzas persunas u motivs relevants per la segirezza excludan u restrenschan questa publicaziun. Publitgar munta che mintgin dastga utilisar, sviluppar vinavant e derasar il software. I na vegnan incassadas naginas taxas da licenza. + +Questas instrucziuns s'adresseschan a las persunas ch'èn responsablas per la publicaziun dal code da funtauna e che la realiseschan. + +[mermaid,align="center",alt="Survista dal process da publicaziun OSS"] +.... +flowchart TD + S(["Cumenzament"]) + A["Sclerida preliminara"] + B["Analisa e preparaziun"] + C["Publicaziun"] + S --> A + A --> B + B --> C +.... + +La materia è repartida en trais parts principalas: + +* L'emprima part (chapitel 3) tracta las *scleridas preliminaras* e las excepziuns tenor l'EMBAG. +* La segunda part (chapitel 4), *Analisa e preparaziun*, examinescha il code da funtauna e il prepara tenor basegn. Ultra da quai vegn fatga la tscherna da la licenza. +* La terza part (chapitel 5), *Publicaziun ed annunzia*, descriva la publicaziun propria ed ulteriuras mesiras sco la communicaziun e la construcziun d'ina communitad adattada. + +*Trais glistas da controlla* accumpognan e documenteschan il process. + +Cumplettaziuns tecnicas èn inditgadas en l'agiunta. + +== Introducziun + +Tar la relaschada da software open source sto vegnir distinguì tranter il *contribuir da code da funtauna e da documentaziun a software open source existent* e la *publicaziun sco project open source independent*. + +Il emprim cas cumpiglia tipicamain reparaziuns da sbagls ed extensiuns funcziunalas. Tut tenor il tip da licenza e l'utilisaziun dal software sto u po il code da funtauna vegnir relaschà sut la licenza existenta dal project open source. Eventualmain sto vegnir observada ina cunvegna da relaschada. + +En il segund cas, il cumenzament d'in nov project open source, pon la governanza e la licenza vegnir tschernidas fundamentalmain libramain. Da resguardar è unicamain la licenza, sut la quala èn publitgads eventuals elements da software integrads en il nov project. Ulteriurs detagls davart la tscherna da la licenza sa chattan en il document link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. Sch'i sa lascha realisar in plivalur per l'administraziun federala tras ina communitad u sche l'administraziun federala vul crear in ecosistem, sto vegnir emplenida supplementarmain la link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS] tenor la link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +La relaschada da software open source è dapli ch'ina pura mesira tecnica. Ella munta era da stabilir ina cultura averta correspundenta e da prender cun sai las persunas. Ina cultura open source cun success è ina maschaida d'avertadad, d'excellenza tecnica, d'ina fitg buna interacziun sociala e d'in engaschament cuminaivel. + +La grafica suandanta descriva las instrucziuns e las differentas caracteristicas. + +[mermaid,align="center",alt="Planta da decisiun per la relaschada da software"] +.... +flowchart TD + Start(["Cumenzament
sviluppà a partir dals 1.1.2024"]) + subgraph B1["1. Sclerida preliminara"] + T{"Gener dal software"} + end + subgraph B2["2. Analisa e preparaziun"] + I{"Han terzas persunas
in interess al software?"} + GJ["Sclerir la governanza e
la collavuraziun [Em002-4.1]"] + GT["Sclerir la governanza e
la collavuraziun [Em002-4.1]"] + O{"Svilup da software
open source?"} + end + subgraph B3["3. Publicaziun"] + M["Realisar ina relaschada minimala"] + P["Publicaziun dal software"] + D["Svilup da software
open source"] + C["Construir e tgirar
ina communitad [Em002-4]"] + end + Start --> T + T -->|"Svilup agen"| I + T -->|"Svilup cuminaivel"| GJ + T -->|"Project da terzas persunas"| GT + I -->|"Na"| M + I -->|"Gea, u imaginabel"| O + GJ --> O + GT --> D + O -->|"Na"| P + O -->|"Gea"| D + P --> C + D --> C + M --> E1(["Fin"]) + C --> E2(["Fin"]) +.... + +Illustraziun 1 – Planta da decisiun per la relaschada da software + +== Process da la sclerida preliminara + +*Finamira:* Chapir ils avantatgs e las consequenzas pussaivlas d'ina publicaziun dal software. Decider, sche il software po vegnir publitgà e, sche gea, sche la construcziun d'ina communitad activa paja. Indicaziun: La link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara OSS] duess vegnir emplenida uschè baud sco pussaivel en il project, perquai che quai po influenzar la moda sco che il software vegn sviluppà. + +=== Relaschada tenor l'EMBAG + +Tenor l'art. 9 da la lescha federala dals 17 da mars 2023 ++[++EMOTA2023++]++ davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG) sto l'administraziun federala (concretamain l'art. 2 al. 1) publitgar il code da funtauna dal software ch'ella sviluppa u fa sviluppar per ademplir sias incumbensas. Excepziuns valan, sche dretgs da terzas persunas u motivs relevants per la segirezza excludan u restrenschan quai. + +Per software individual creà per incumbensa da la Confederaziun valan fundamentalmain las cundiziuns generalas da contract da la Confederaziun ++[++BBL-AGB++]++. Tenor la cifra 25.1 prevesan quellas che la proprietad dal code da funtauna e da la documentaziun passia al recepient da prestaziuns (la Confederaziun). Sche il software è vegnì acquistà cuminaivlamain da pliras organisaziuns u autras instituziuns, sto vegnir examinà, tgi ch'ha ils dretgs sin il code. Per exempel po la proprietad sa chattar tar in'associaziun fundada per quest intent. + +La pura utilisaziun da software standard na croda betg sut l'art. 9 EMBAG, ed ina relaschada na fiss per ordinari tuttina betg pussaivla, perquai ch'ils dretgs sin software standard restan savens tar il purschider (CGC da la Confederaziun per l'acquist da software standard). Extensiuns individualas da software standard s'adattan percunter fitg bain per ina publicaziun. Normalmain èn quellas en la proprietad da la Confederaziun. Puras adattaziuns da configuraziun s'adattan pli pauc per ina publicaziun. Il tema vegn tractà en link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source] sco er en ils documents ++[++KBB-MB++]++ e ++[++BBL-WL++]++. Fundamentalmain suttastattan extensiuns adina a l'art. 9 EMBAG. + +==== Il software en relaziun cun l'EMBAG + +La norma actuala ISO/IEC 24765 cuntegna trais definiziuns per software: + +. in program u in set da programs per manar computers +. programs e la documentaziun appartegnenta +. programs e, sch'applitgabel, la documentaziun associada sco er ulteriuras datas necessarias per il manaschi dal computer. + +Sin la basa da questa definiziun valan era scripts, macros u Infrastructure as Code (IaC) pli pitschens sco software. L'EMBAG sa referescha en l'artitgel 9 alinea 1 al code da funtauna. Tenor questa interpretaziun bastass ina publicaziun tenor la definiziun 1. Ina publicaziun senza la documentaziun appartegnenta è dentant da pitschen valur, perquai che il software na po betg vegnir utilisà tenor la definiziun 2. + +Per realisar sinergias cun terzas persunas sto vegnir prendida sco basa la definiziun 3. Concernent las datas munta quai concretamain datas da basa e configuraziuns da basa (per exempel valurs d'enumeraziun e datas da basa che duessan era vegnir messas a disposiziun sco open source). + +Projects, scripts u exempels da code pli pitschens pon era vegnir publitgads ensemen en in sulet repositori, sche l'autoritad federala considerescha quai sco raschunaivel. En quest cas pon questas instrucziuns e las glistas da controlla correspundentas vegnir emplenidas ina giada. + +Tar la decisiun, tge ch'i vegn publitgà e co, ston vegnir resguardads la proporziunalitad e la lavur. + +==== Gener dal software + +Sco mussà en l'illustraziun 1 vegn distinguì tranter svilup agen, svilup cuminaivel e projects da terzas persunas. Mintga constellaziun ha autras consequenzas. Independentamain da co che il software vegn sviluppà, croda el sut l'art. 9 EMBAG. + +Tar il svilup agen crescha la Confederaziun sezza il software u il fa crear correspundentamain. Ella tscherna la governanza e resta cun ils dretgs sin il code da funtauna. + +Tar il svilup cuminaivel crea la Confederaziun il software ensemen cun autras organisaziuns. La governanza ed ils dretgs sin il software ston vegnir reglads tras la furma d'organisaziun tschernida. + +Sche la Confederaziun contribuescha directamain a software da terzas persunas, croda era quest code da funtauna sut l'art. 9 EMBAG. I sto vegnir garantì che quai capitia en l'interess da las autoritads federalas, che la participaziun correspundia a las pretensiuns dal project e che l'administraziun federala observia la governanza. + +Quai capita cun agid da la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara OSS] e da la link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS]. + +==== Code existent + +Tar software vegl (*software existent*) è la lavur posteriura per ina publicaziun pli gronda che sche la relaschada fiss vegnida planisada dal cumenzament. Tar software existent paja questa lavur mo, sch'in utilisader potenzial vul duvrar il software. Independentamain da quai duess la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara OSS] vegnir emplenida per documentar las decisiuns relevantas. + +Applicaziuns, cun il svilup da las qualas las autoritads federalas han cumenzà ils 1. da schaner 2024 u pli tard, u che vegnan sviluppadas per incumbensa da la Confederaziun sin la basa d'in contract concludì suenter ils 1. da schaner 2024, na valan betg sco existentas e suttastattan en mintga cas a l'obligaziun da publicaziun tenor l'art. 9 al. 1 EMBAG. + +L'obligaziun da publicaziun tenor l'EMBAG na dependa betg dal profit per terzas persunas. + +==== Bibliotecas, plug-ins ed add-ons + +En tscherts cas n'è il software betg in'applicaziun independenta, mabain mo parts da quella. L'EMBAG e l'ordinaziun na defineschan betg pli detagliadamain il code da funtauna. Las instrucziuns valan era per bibliotecas, plug-ins ed add-ons deculiads; quels crodan sut l'EMBAG. + +*Incumbensas:* + +* Rimnar infurmaziuns da link:em002-5.pdf[Em002-5 Fegl d'infurmaziun Meds OSS]. Quel descriva tant infurmaziuns generalas davart software open source sco er infurmaziuns specificas davart l'applicaziun da l'EMBAG. +* Examinar, sche las premissas tenor l'EMBAG èn ademplidas. +* Emplenir la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara OSS]. Per ordinari è raschunaivel d'integrar directamain las persunas da contact dal furnitur dal software resp. dal svilup. +* Sche necessari emplenir la link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS]. + +*Decisiun:* Sto il software vegnir publitgà e co duai quai capitar? + +=== Excepziun: Dretgs da terzas persunas + +I sto vegnir renunzià ad ina publicaziun, sche quella violass dretgs da terzas persunas. Sche il software è vegnì sviluppà da emploiads da la Confederaziun, appartegnan ils dretgs al patrun.footnote:[Art. 332 DO en colliaziun cun l'art. 6 al. 2 LPers] En contracts davart il prest da persunal e prestaziuns informaticas vegnan ils dretgs usitadamain transferids a la Confederaziun e duessan vegnir fatgs valair. + +Sche il software è vegnì u vegn sviluppà sin la basa da las cundiziuns generalas da contract da la Confederaziun svizra (stadi 2024),footnote:[Cundiziuns generalas da contract da la Confederaziun svizra, en spezial la cifra 25.1 – https://www.bkb.admin.ch/bkb/de/home/themen/agb.html#accordion_21321111141713247349255] appartegnan ils dretgs da proprietad immateriala al mandant, uschenavant che nagut auter n'è vegnì convegnì contractualmain. + +In'applicaziun consista tipicamain da numerusas cumponentas e parts singulas. Tar tscherts geners vegn quai problematic, sch'ellas n'èn sezzas betg open source u na pon betg vegnir publitgadas sut ina licenza open source sco part da l'applicaziun. + +*Bibliotecas* + +Tut tenor la lingua da programmaziun vegnan las bibliotecas u compiladas directamain cun l'applicaziun, colliadas u furnidas sco pachets. Ellas furman ina part integrala da l'applicaziun. + +Sche l'applicaziun cuntegna bibliotecas proprietaras u suttamessas ad ina licenza, vegn l'open sourcing pli difficil. Fundamentalmain po il code da funtauna da la rimanenza da l'applicaziun vegnir publitgà, ma utilisaders u sviluppaders potenzials stuessan acquistar la biblioteca pertutgada, avant che l'applicaziun vegn utilisabla u extendibla. + +Sche la proprietad da la biblioteca problematica sa chatta tar il furnitur da l'applicaziun, paja ina sclerida giuridica, sche la Confederaziun ha dretgs transferibels sin questas bibliotecas. + +Nua ch'igl è pussaivel duessan bibliotecas proprietaras e suttamessas ad ina licenza vegnir evitadas tar svilups agens u vegnir remplazzadas sche pussaivel avant la relaschada. Cun vista a la finamira da l'artitgel 9 EMBAG duess vegnir publitgada uschè bler sco pussaivel da la funcziunalitad duvrada da l'administraziun publica. Bibliotecas singulas che impedeschan la publicaziun dal code represchentan perquai debits tecnics che duessan vegnir documentads ed eliminads en ina buna occasiun. + +*Bancas da datas ed auters memorisaders da datas* + +Sche l'applicaziun utilisescha memorisaders da datas proprietars e suttamess ad ina licenza sco Microsoft SQL Server, na s'oppona quai betg ad ina publicaziun open source. + +I duess dentant vegnir examinà, sche bancas da datas avertas supplementaras sco PostgreSQL pon vegnir sustegnidas. Quai po spargnar custs da manaschi e reducir las barrieras d'access per utilisaders potenzials. + +*Servers d'applicaziun e sistems da manaschi* + +Sche l'applicaziun dovra sistems da manaschi u servers d'applicaziun licenziads (p.ex. Microsoft Windows Server u RedHat JBoss), na s'oppona quai betg ad ina publicaziun open source. + +Nus recumandain da dumandar tar il purschider dal software, sche e tge bibliotecas licenziadas da terzas persunas ch'èn utilisadas sco cumponentas da l'applicaziun. + +Sche la creaziun dal software è vegnida acquistada cuminaivlamain da pliras organisaziuns u autras instituziuns, sa chatta la proprietad per ordinari tar in'associaziun u in'autra persuna giuridica fundada per quest intent. + +*Ulteriura proprietad intellectuala* + +Tar ils dretgs da terzas persunas appartegnan betg mo ils dretgs d'autur, mabain era ulteriura proprietad intellectuala (marcas, patents). Patents n'impedeschan betg fundamentalmain che software vegnia publitgà sco open source, ma els pon impedir sia utilisaziun u extensiun. Schebain che patents èn en Svizra pli tgunsch inusitads, paja per ordinari ina curta dumonda tar il purschider dal software, sch'ina examinaziun ha gia gì lieu. + +*Acquist dals dretgs necessaris* + +Per ademplir las prescripziuns legalas da l'EMBAG ha l'autoritad federala sco mandanta la pussaivladad da s'assicurar ils dretgs sin ils resultats da la lavur. Questa premissa per ina publicaziun po vegnir fixada sco criteri tar l'acquist. L'acquist posteriur dals dretgs necessaris sin il software po vegnir pli cumplex. + +Sche l'autoritad federala na vul betg publitgar sezza il software, po ella per exempel delegar questa incumbensa a l'incumbensà u transferir correspundentamain ils dretgs da publicaziun. En quest cas transferescha ella ils dretgs (e las obligaziuns) necessaris al furnitur e/u a terzas persunas ed ils incumbensescha cun la publicaziun. Uschia vegn il dretg transferì factic a terzas persunas sut la cundiziun da la relaschada resp. dal support dal software correspundent. + +Era qua cuntegna ++[++KBB-MB++]++ indicaziuns impurtantas. + +*Proceder* + +[mermaid,align="center",alt="Process per il tractament da l'excepziun dretgs da terzas persunas"] +.... +flowchart TD + S(["Cumenzament"]) + Q1{"Acquist d'ina licenza u d'ina
schliaziun existenta sco object
d'acquist central?"} + Q2{"Èn ils svilups vinavant
definibels?"} + Q3{"Appartegnan ils dretgs
a la Confederaziun?"} + Q4{"È l'acquist da dretgs da
terzas persunas necessari?"} + Q5{"Po ina part cun dretgs tar la
Confederaziun vegnir delimitada
en moda mirada?"} + R1["Excepziun motivada:
dretgs da terzas persunas"] + R2["Relaschada parziala da
la Confederaziun"] + R3["Relaschada da la Confederaziun"] + S --> Q1 + Q1 -->|"Na"| Q3 + Q1 -->|"Gea"| Q2 + Q2 -->|"Gea"| Q3 + Q2 -->|"Na"| R1 + Q3 -->|"Gea"| R3 + Q3 -->|"Na"| Q4 + Q4 -->|"Gea"| R3 + Q4 -->|"Na"| Q5 + Q5 -->|"Gea"| R2 + Q5 -->|"Na"| R1 +.... + +Illustraziun 2 – Excepziun: Dretgs da terzas persunas (adina era resguardar ++[++KBB-MB++]++ e link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source]) + +In'excepziun motivada pervia da dretgs da terzas persunas resulta betg mo da l'acquist da licenzas u da software existent, mabain era dal svilup da software sin software existent licenzià. + +Ina relaschada parziala è pussaivla en la suandanta constellaziun: il software cuntegna parts proprietaras u protegidas; quellas sa laschan differenziar dal svilup vinavant; auters dretgs da proprietad intellectuala èn pertutgads. + +*Incumbensas:* + +* Examinar, sche l'organisaziun posseda ils dretgs da protecziun relevants sin il software. +* Examinar, sche ils dretgs pon vegnir acquistads. +* Sche necessari obtegnair il permiss en scrit dals possessurs dals dretgs. +* Garantir che l'applicaziun na cuntegnia naginas parts proprietaras u protegidas. +* Examinar ch'i n'existan nagins impedaments pervia da la protecziun da patent (uschenavant che quai è pussaivel ed adequat). +* Examinar, sche la relaschada duai vegnir fatga da terzas persunas. +* Examinar, sche il svilup duai sa basar sin il svilup da software open source (cun agid da la link:em002-4.pdf[Em002-4 Guida da communitads OSS]). + +*Decisiun:* Po il software vegnir publitgà senza violar dretgs da terzas persunas? + +=== Excepziun: Motivs relevants per la segirezza + +Software che na po betg vegnir publitgà per motivs relevants per la segirezza è exceptà da la publicaziun. + +Las datas propias d'in software n'èn betg pertutgadas da la publicaziun dal code da funtauna. Questas datas èn per ordinari sensiblas e na vegnan betg publitgadas. I po dentant esser che, ultra da las datas da cuntegn, tscherts algoritmus e process visibels en il code da funtauna na duain betg vegnir publics (p.ex. abilitads cyber offensivas, detagls da la renconuschientscha da fraud). La segirezza po pertutgar la confidenzialitad, l'integritad, la disponibladad u la traçabilitad. + +*Recumandaziun:* + +Software duess vegnir sviluppà conscientamain uschia, che nagin ristg supplementar na nascha era tar ina publicaziun dal code da funtauna. La supposiziun ch'ina nunpublicaziun protegia cunter attatgas cun success è ingiannaivla («security through obscurity»). + +*Proceder:* + +[NOTE] +==== +Determinant è adina il software e betg l'intent dal software. L'elavuraziun da datas criticas n'è betg a priori in aspect relevant per la segirezza. +==== + +[mermaid,align="center",alt="Process per il tractament da l'excepziun motivs relevants per la segirezza"] +.... +flowchart TD + S(["Cumenzament"]) + Q1{"Motivs relevants
per la segirezza?"} + Q2{"Po il software relevant per la
segirezza vegnir deculià?"} + Q3{"Motivs temporars?"} + M["Mesiras per
la publicaziun"] + R1["Relaschar ina part
dal software"] + R2["Excepziun:
motivs relevants per la segirezza"] + R3["Excepziun temporara"] + R4["Relaschar"] + S --> Q1 + Q1 -->|"In u plirs puncts èn applitgabels"| Q2 + Q1 -->|"Betg applitgabel"| Q3 + Q2 -->|"Gea"| R1 + Q2 -->|"Na"| R2 + Q3 -->|"In u plirs puncts èn applitgabels"| R3 + Q3 -->|"Nagins motivs temporars"| M + M --> R4 +.... + +Illustraziun 3 – Excepziun: Motivs relevants per la segirezza + +Ils suandants motivs pon valair per mintga project sco relevants per la segirezza: + +* La publicaziun dal software augmentass essenzialmain in ristg per la segirezza da las infurmaziuns.footnote:[Lescha davart la segirezza da las infurmaziuns, LSIn. Art. 6 Segirezza da las infurmaziuns. https://www.fedlex.admin.ch/eli/cc/2022/232/de#art_6] +* Tar algoritmus per la prevenziun da fraud ed algoritmus sumegliants po eventualmain vegnir renunzià ad ina publicaziun. +* Tecnologias da cybersegirezza spezialmain sensiblas. +* Software central per il manaschi d'infrastructuras criticas. +* Sche la publicaziun violass autras basas legalas. + +Ils suandants motivs temporars pon anc impedir ina publicaziun. Quella vegn dentant pussibilitada pli tard tras mesiras adequatas. + +* Il code existent n'ha anc betg pudì vegnir rundà e cuntegna eventualmain problems relevants per la segirezza. +* Audits da segirezza dal code n'èn anc betg vegnids fatgs. +* Il process da svilup n'è anc betg avunda madir per ina publicaziun segira. Sche il process da svilup n'è betg suffizientamain stabilì, exista la pussaivladad che parts vegnian publitgadas che n'èn betg destinadas a terzas persunas. Per exempel ston las directivas per commentar il code e la generaziun da datas da test vegnir adattadas al nov scenari da publicaziun e funcziunar a moda fidada. + +Cun las suandantas mesiras po software vegnir publitgà malgrà motivs relevants per la segirezza: + +* Separar las configuraziuns (p.ex. gener da la cifraziun utilisada) dal software. +* Transferir infurmaziuns tecnicamain sensiblas e betg publicas (p.ex. process, quints) en configuraziuns u parameters. +* Planisar, realisar ed exercitar regularmain mesiras organisatoricas, persunalas e tecnicas adequatas. +* Planisar ed exequir activitads da qualitad adequatas tar la publicaziun. Vesair il chapitel suandant «Analisa e preparaziun». + +*Incumbensas:* + +* Examinar il software concernent motivs relevants per la segirezza che s'opponan ad ina publicaziun. +* Stimar la lavur per eliminar ils motivs temporars. +* Planisar mesiras per separar infurmaziuns relevantas per la segirezza dal code da funtauna dal software. +* Garantir che l'applicaziun na cuntegnia nagins process che na dastgan betg vegnir publics. + +*Decisiun:* + +Existan motivs cuncludents relevants per la segirezza che rendan impussibla ina publicaziun? + +=== Sclerida da la publicaziun + +En quest pass vegn scleri, tgi che publitgescha il software. Sche il software è vegnì creà d'in purschider extern, po la publicaziun era vegnir transferida a quel purschider. En quest pass è impurtant da determinar, nua ch'il code da funtauna vegn publitgà, e da fixar ina governanza correspundenta. + +Sche il software è vegnì sviluppà internamain en la Confederaziun e sche quella na po u na vul betg il publitgar sezza, po vegnir dà in mandat da publicaziun ad in furnitur u pon ils dretgs vegnir cedids (transferiment da las obligaziuns a terzas persunas). + +*Relaschada minimala e support* + +L'EMBAG na fa naginas prescripziuns davart la publicaziun. Ina relaschada minimala dal code da funtauna adempla la prescripziun legala. Ulteriuras activitads n'èn betg necessarias. La dumonda, sche e en tge dimensiun ch'i vegn purschì support e quant activamain che il project vegn tgirà, sa lascha respunder cun agid da la link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +*Svilup da software open source (OSSD)* + +Tar il svilup da software open source (OSSD) vegn, supplementarmain a la publicaziun dal code da funtauna, l'entir process da svilup exequì publicamain. Tut, da las pretensiuns (issues) fin al code da funtauna, è transparent. L'OSSD vegn sustegnì tras utensilis da communicaziun publics (glistas da mail, forums etc.), in sistem da gestiun da versiuns (git), glistas da sbagls e da funcziuns, ina roadmap ed utensilis per sviluppaders. Tras questa moda da lavurar transparenta profitescha l'entira communitad e la collavuraziun sur cunfins organisatorics vegn pussibilitada. Cun quest access n'è naginas ulteriuras activitads da publicaziun necessarias a la fin dal project, perquai che quai è gia vegnì resguardà al cumenzament dal project. + +*Incumbensas* + +* Far ina stimaziun gruassa da la lavur per la fasa d'analisa. Tut tenor la grondezza e la cumplexitad da l'applicaziun sa chatta la lavur tranter trais dis e duas emnas. +* Relaschar resursas per ils pass vinavant, en spezial per l'analisa. +* Acconsentir fundamentalmain da publitgar l'applicaziun sco open source. + +*Decisiun:* + +Il consentiment fundamental e la realisabladad per publitgar l'applicaziun sco open source èn dads. + +=== Reducir la lavur + +Las glistas da controlla e las instrucziuns èn construidas uschia che la lavur per relaschadas resta uschè pitschna sco pussaivel. Ina planisaziun consequenta ed anticipada da la relaschada al cumenzament dal project ed in svilup orientà a la relaschada reduceschan la lavur. Ina tscherta lavur administrativa e tscherts custs resultan inevitablamain ++[++Le2023++]++. Quels sa laschan eventualmain reguadagnar via communitads cun custs da svilup dividids (vesair link:em002-4.pdf[Em002-4 Guida da communitads OSS]). + +=== Tscherna da la lingua da publicaziun + +Tar la tscherna da la lingua ston vegnir resguardads tant il public da destinaziun potenzial sco er la moda da lavurar dal team. Per fortuna èn las translaziuns daventadas deteriormain pli simplas cun novs utensilis. Sco opziuns vegnan en dumonda las linguas ufficialas da la Confederaziunfootnote:[https://www.fedlex.admin.ch/eli/cc/1999/404/rm#art_70] e l'englais. + +Sche il project è relevant internaziunalmain, duess l'englais esser la lingua da destinaziun. Per ina publicaziun posteriura n'ha ina midada da lingua naturalmain pauc senn. + +Almain la README.md duess esser avant maun en pliras linguas, per che ils interessads renconuschian immediatamain, sche il project è relevant per els. + +La communicaziun publica duess resguardar en emprima lingia il public da destinaziun. Da resguardar è ultra da quai ch'i sa tracta da communicaziun publica da la Confederaziun. + +*Indicaziun*: Cun la publicaziun entra l'administraziun federala in nov chanal da communicaziun publica. Sche quai na capita betg cun quità e professiunalmain, po la reputaziun publica da la Confederaziun svelt patir. + +== Analisa e preparaziun + +*Finamira:* Las lavurs necessarias per ina publicaziun open source èn terminadas. Las decisiuns davart la licenza ed il gener da communitad èn prendidas. Quai capita cun agid da la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[glista da controlla Em002-2.2 Analisa e preparaziun OSS]. + +=== Analisa dal code da funtauna + +Il code da funtauna da publitgar ed ulteriurs documents appartegnents vegnan analisads avant la publicaziun. Questa analisa garantescha che naginas infurmaziuns confidenzialas na vegnian publitgadas. + +Sch'in vast code da funtauna è previs per la publicaziun, è recumandabel d'utilisar utensilis automatisads adattads per las suandantas activitads. + +Ils detagls èn fixads en la secziun E. + +*Incumbensas* + +* Examinar, co che la qualitad dal code existenta e las directivas èn vegnidas realisadas (p.ex. ISO/IEC 25010:2023footnote:[ISO/IEC 25010:2023 - Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.iso.org/standard/78176.html]). +* Garantir che naginas datas (da test) sensiblas na sajan cuntegnidas, p.ex. datas che sa basan sin persunas u cas reals. +* Actualisar la documentaziun dal software (vesair agiunta). +* Stizzar datotecas nunnecessarias u documents e datas antiquads. +* Examinar il code da funtauna concernent secrets/datas d'access.footnote:[https://www.ncsc.admin.ch/ncsc/de/home/aktuell/im-fokus/2022/git.html] +* Exequir tests da segirezza mirads ed installar suenter in program da bug bounty (public).footnote:[https://www.ncsc.admin.ch/ncsc/de/home/infos-fuer/infos-it-spezialisten/themen/bug-bounty-programme.html] +* Examinar tuttas bibliotecas utilisadas concernent las licenzas e crear las glistas correspundentas (attribuziuns). Sch'ina biblioteca è disponibla sut pliras licenzas, sto quai vegnir inditgà correspundentamain en las glistas. +* Descriver il deployment (pipeline CI/CD) ed eventualmain installar ina instanza da demonstraziun. + +Questas activitads èn independentas da la publicaziun, ma furman premissas per ina buna qualitad dal software e per garantir la conformitad. L'observaziun da questas mesiras simplifitgescha la collavuraziun, augmenta la qualitad da las contribuziuns externas e meglierescha la reputaziun dal software resp. da l'autoritad. + +=== Tscherna da la licenza + +*Vesair link:em002-3.pdf[Em002-3 Guida da licenzas OSS].* + +Texts da licenza stabilids internaziunalmain duessan vegnir utilisads, nua che quai è pussaivel e raschunaivel. Pretensiuns da responsabladad dals prenditurs da licenza ston vegnir excludidas uschè lunsch sco quai è giuridicamain pussaivel. + +*Incumbensas* + +* Examinar eventualas dependenzas da licenzas existentas. +* Per code da terzas persunas examinar las cundiziuns d'utilisaziun concernent la cumpatibilitad cun la licenza previsa e remplazzar il code sche necessari.footnote:[Vesair Em002-3 concernent la tscherna da code resp. bibliotecas da terzas persunas per in stack da tecnologia e concernent la cumpatibilitad da la licenza.] +* Tscherner la licenza adattada. + +La cumpatibilitad da las licenzas sa lascha examinar cun utensilis sco ORT Toolkit,footnote:[https://oss-review-toolkit.org/] Black Duck,footnote:[https://www.blackducksoftware.com] FOSSAfootnote:[https://www.fossa.com] u FOSSology.footnote:[https://www.fossology.org] Il ToDo Group footnote:[https://landscape.todogroup.org/] porscha ina survista actuala dals utensilis. + +*Decisiun:* + +* Fixar e documentar, sut tge licenza che il software vegn publitgà. + +=== Documentaziun open source + +Cun la publicaziun vegn spetgà in minimum da documentaziun. En l'ecosistem open source èn sa stabilids plirs documents. Quels dattan als visitaders ina svelta invista en il software, inclusiv la licenziaziun. + +Ils suandants documents vegnan spetgads: + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Document* |*Descripziun / cuntegn:* +|README(.md) |Serva sco document d'entrada e dat ina svelta survista da l'intent, da l'extensiun, dal status, da la licenza e da las gruppas da destinaziun dal project. +|LICENSE |Descripziun da la licenza tschernida en il project +|CONTRIBUTING(.md) |Descriva il process, co ch'ins po contribuir al project. +|CODE++_++OF++_++CONDUCT(.md) |Il code of conduct fixescha las normas socialas spetgadas entaifer il project. +|CHANGELOG(.md) |Maina ina glista da las midadas en las versiuns dal software. +|THIRD-PARTY-LICENSES(.md) |Descripziun da las licenzas da terzas persunas resp. da las cumponentas utilisadas. +|Getting started |Curta instrucziun per installar ed utilisar il software. +|Create Gitignore |Descriva documents che na vegnan betg publitgads, p.ex. configuraziuns, datas da test u cuntegns generads. Infurmaziuns protegidas e sensiblas duessan vegnir administradas ordaifer il project en utensilis e memorisaders adattads e previs per quai. +|publiccode.yml |Metadatas structuradas per descriver il software, sin la basa dal standard https://yml.publiccode.tools/. Il format fixà renda la publicaziun pli facil da chattar e da reutilisar. Ulteriuras infurmaziuns en l'agiunta F. +|=== + +Tabella 1 – Documents open source + +Ulteriurs detagls tecnics davart quests documents èn descrits en l'agiunta. + +*Incumbensas* + +* Crear la documentaziun standard. +* Inditgar copyright, indicaziuns da licenza ed exclusiun da responsabladad en tuttas datotecas. +* Tut tenor la plattafurma da publicaziun pon vegnir fatgas descripziuns supplementaras. + +*Decisiun:* + +* Decisiun definitiva da publitgar l'applicaziun sco open source. + +== Publicaziun ed annunzia + +*Finamira:* L'applicaziun è publitgada sco open source e leva da chattar per terzas persunas. Tuttas cumponentas èn prontas per la publicaziun e la communitad è construida u stabilida. Quai capita cun agid da la link:em002-2-3-checklist-oss-release-and-publication.pdf[glista da controlla Em002-2.3 Relaschada e publicaziun OSS]. En tscherta dimensiun vegnan recapituladas decisiuns gia prendidas. + +=== Tscherna da la plattafurma + +I dat pliras pussaivladads da publitgar code da funtauna. La tabella suandanta dat ina survista dals pussaivels sistems da source code management (SCM) e da las plattafurmas. + +La plattafurma adattada sto vegnir tschernida avant la publicaziun propria. Tschertas autoritads federalas èn gia represchentadas sin GitHub.footnote:[La pagina d'internet https://ossbenchmark.com dat ina survista da las organisaziuns e da las autoritads ch'èn activas sin GitHub.] En quest cas è raschunaivel d'utilisar plattafurmas gia stabilidas. + +*Recumandaziun:* + +Nus recumandain actualmain d'installar per mintga autoritad federala ina organisaziun sin GitHub per publitgar code da funtauna. Entaifer questa organisaziun pon vegnir creads projects correspundents (repositoris) ed administrads utilisaders cun las autorisaziuns adattadas. En l'avegnir duess vegnir construida ina plattafurma federala centrala. Per garantir ina administraziun dals utilisaders optimala e per mantegnair la reputaziun da la Confederaziun svizra, è impurtant d'utilisar pli pauc repositoris, ma quels meglier administrads. + +[width="100%",cols="<50%,<50%",options="header",] +|=== +|*Plattafurma* |*Caracteristicas* +|GitHubfootnote:[https://github.com/about/] |Plattafurma online da Microsoft cun gronda derasaziun. Ina gronda quantitad da software open source vegn hostada sin GitHub. Porscha ultra dal SCM blers utensilis supplementars. Disponibla en ina versiun Free ed ina versiun Enterprise (abunament). +|GitLabfootnote:[https://about.gitlab.com/] |Plattafurma online da l'interpresa dal medem num GitLab, ch'è sezza publitgada sut ina licenza open source. Porscha ultra dal SCM blers utensilis supplementars. Po era vegnir manada localmain, quai che dat ina tscherta suveranitad. Disponibla en ina versiun Free ed ina versiun Enterprise (abunament). +|Bitbucketfootnote:[https://bitbucket.org/product/en] |Plattafurma online da Atlassian, integrada spezialmain en ses ecosistem. Disponibla en ina versiun Free ed ina versiun Enterprise (abunament). +|Sistem SCM intern |Sch'ina atgna plattafurma SCM vegn messa a disposiziun, po era quella publitgar e render disponibels tscherts repos/projects. Il manaschi sto esser garantì. +|Plattafurma federala |Actualmain n'exista nagina plattafurma federala centrala per publitgar software. Ina mesira correspundenta vegn proponida en link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala]. +|Pagina d'internet, server FTP public etc. |L'EMBAG na fixescha betg, co che software sto vegnir publitgà. Ina relaschada minimalafootnote:[Ina publicaziun minimala cumpiglia mo la publicaziun dal code da funtauna e d'ulteriurs artefacts minimals. Quest gener da publicaziun adempla las prescripziuns da l'EMBAG. In plivalur na vegn dentant betg cuntanschì cun la publicaziun.] po era avair lieu sin ina pagina d'internet u sin autras resursas accessiblas publicamain. Per ina collavuraziun persistenta en il senn da l'open source n'è quai dentant betg adattà. +|=== + +Tabella 2 – Plattafurmas per publitgar software open source + +Sche il software vegn publitgà ensemen cun in partenari u ina organisaziun externa, sto vegnir fatg adatg che las autorisaziuns e ils accesses correspundents al code da funtauna sajan avant maun. + +*Incumbensas* + +* Evaluar la plattafurma adattada, inclusiv l'organisaziun/il project correspundent. +* Sche quai n'è anc betg scleri, fixar la denominaziun dal project/repositori. +* Fixar ed examinar las autorisaziuns sin il repo. +* Garantir ina governanza adequata ed ina eventuala replicaziun dal code da funtauna. + +*Decisiun:* + +* La plattafurma per la publicaziun è vegnida tschernida adequatamain. + +=== Publicaziun dal software + +Sche las premissas èn scleridas, po il software vegnir publitgà. + +*Incumbensas* + +* Examinar las premissas cun agid da la link:em002-2-3-checklist-oss-release-and-publication.pdf[glista da controlla Em002-2.3 Relaschada e publicaziun OSS]. +* L'access a la plattafurma exista e la governanza è scleria. +* Publicaziun dal code da funtauna e da la documentaziun tras il svilup. + +=== Communicaziun + +Suenter la publicaziun propria pon vegnir inizialisadas tras ed entaifer l'autoritad federala pertutgada ulteriuras activitads da communicaziun. Quellas sustegnan la derasaziun e portan il plivalur giavischà da la publicaziun. + +*Incumbensas* + +* Descripziun en il hosting dal repo, parameters da segirezza etc. +* Communicaziun interna ed eventualmain externa +* Redigir ina communicaziun a la communitad. +* Render enconuschenta l'applicaziun entaifer l'organisaziun ed en gremis spezialisads, promover sia utilisaziun e las contribuziuns. +* Crear ina datoteca publiccode.ymlfootnote:[Il standard da metadatas https://yml.publiccode.tools/ descriva il software. Il format fixà renda la publicaziun pli facil da chattar e da reutilisar. Ulteriuras infurmaziuns en l'agiunta F.] en il repositori per il catalog OSS da l'administraziun federala.footnote:[Catalog OSS: https://www.opensource.admin.ch] + +=== Construcziun e tgira da la communitad + +Tar la publicaziun da software po nascher ina communitad che po contribuir al software tras contribuziuns (pull requests), dumondas, propostas da documentaziun etc. Per ina communitad activa è necessaria ina lavur considerabla tant per la construcziun sco er per la tgira permanenta. Ina communitad che funcziuna bain reducescha forks nungiavischads dal software. La finamira è qua d'activar il plivalur da la communitad tras activitads miradas. Era tar ina publicaziun minimala duess vegnir fixà, co ch'i vegn tractà cun resuns e dumondas davart il software. + +*Incumbensas* + +* Sclerir, tgi che èn utilisaders potenzials u interessads. +* Determinar la furma adattada per l'applicaziun concreta cun agid da la link:em002-4.pdf[Em002-4 Guida da communitads OSS]. +* Construir la communitad. +* Activitads per construir la communitad. + +== Agiunta + +=== Midadas envers la versiun precedenta + +* Chapitels 4.3 e 5.3: Publicaziun cumplettada cun publicode.yml +* L'agiunta F «Public Code» è vegnida agiuntada +* Differentas midadas e meglieraziuns redacziunalas pitschnas + +=== Referenzas + +Vesair _Em002 Directivas strategicas per software open source en l'administraziun federala_. + +=== Abreviaziuns + +Vesair link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] ed link:em002-6.pdf[Em002-6 FAQ davart OSS]. + +=== Documentaziun accumpagnanta link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla Analisa e preparaziun OSS] – Documentaziun + +=== Documentaziun dal code da funtauna + +La documentaziun duess esser part dal code da funtauna dal project, per che midadas a la documentaziun vegnian archivadas a moda segira per la revisiun e per che la documentaziun vegnia versiunada parallelamain al project. Uschia è automaticamain garantì che la documentaziun, tar ina tgira adequata, na divergia betg dal status da svilup dal project e che la documentaziun da versiuns pli veglias dal project possia vegnir consultada da tut temp. + +Ultra da quai survegnan terzas persunas uschia la pussaivladad da contribuir simplamain midadas a la documentaziun. + +Sco lingua da marcaziun per la formataziun dal text duess vegnir utilisà Markdown, perquai ch'igl è simpel da scriver, fitg derasà e legibel per maschinas. Ultra da quai vegnan documents Markdown mussads da tuttas plattafurmas currentas en in format da destinaziun bain legibel. Documents Markdown sa laschan rendrar en mintga format da destinaziun, independentamain da la plattafurma utilisada, cun generaturs da paginas staticas sco per exempel Jekyll, MkDocs, Gatsby u Sphinx, per exempel cun las prescripziuns d'identitad visuala d'ina administraziun. + +=== Destinaturs e structura da la documentaziun + +La documentaziun dal project duess s'adressar tant als utilisaders finals sco er a las persunas spezialisadas tecnicas e betg sa concentrar exclusivamain sin la tecnica. Per la tscherna da la lingua vesair il chapitel 3.6. Quai sustegna la derasaziun dal software. + +Ina datoteca README.md serva sco document d'entrada. Datotecas cun quest num vegnan renconuschidas da tuttas plattafurmas currentas e mussadas sco punct d'entrada en la documentaziun.footnote:[Ulteriuras infurmaziuns davart il crear d'ina datoteca readme: https://www.makeareadme.com/] + +README.md duess dar ina svelta survista da l'intent, da l'extensiun, dal status, da la licenza e da las gruppas da destinaziun dal project. Concretamain duess README.md cuntegnair ils suandants puncts: + +* Num dal software +* Curta descripziun da l'intent e da la funcziun dal software. Extensiun e restricziuns pussaivlas +* Instrucziun d'installaziun +* Utilisaziun dal software +* Indicaziun d'ina eventuala instanza da demonstraziun +* Indicaziuns da support e da contact +* Co ch'ins contribuescha al software open source (Contributing) +* Licenza utilisada (Licence) +* Status dal project / stadi da svilup + +=== Sublinear l'open source ed archivar la licenza + +Directamain suenter la maxima duess vegnir tegnì en scrit cleramain e senza malchapientscha ch'i sa tracta tar il project da software open source. La licenza utilisada dal project duess vegnir inditgada cun l'identificatur SPDX correspundentfootnote:[Identificatur SPDX – https://spdx.org/about] e colliada cun il text da licenza concret en la datoteca LICENSE. Models da licenza cuntegnan tipicamain ina part variabla (p.ex. num dal project, onn dal copyright, num da l'autura u da l'autur) che sto vegnir adattada en la datoteca LICENSE. + +La gronda part da las plattafurmas renconuscha licenzas en ina datoteca LICENSE e porscha infurmaziuns cleras davart la licenza, p.ex. ina curta resumaziun da las cundiziuns da licenza. + +I vegn recumandà d'agiuntar ad ina mintga datoteca da funtauna creada da nov in header minimal da licenza e copyright. Headers existents en datotecas existentas na duessan betg vegnir midads. Sch'ins contribuescha ad in project che ha prescripziuns cleras per headers, ston quellas vegnir observadas. + +Ulteriurs detagls vesair: Producing Open Source Software: State That the Project is Free.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Stadi da svilup actual + +Per mussar svelt il stadi dal project duess il stadi da svilup actual vegnir documentà en README.md. Per ils lecturs è impurtant da savair, sche il project sa chatta en in stadi madir u al cumenzament dal svilup, sch'el vegn tgirà activamain e quant savens che novas versiuns vegnan publitgadas. + +En questa secziun po vegnir descrit, tge gener da sustegn tras terzas persunas ch'è actualmain il pli impurtant per il project. Quai pudess esser per exempel ina sviluppadra u in sviluppader cun savida tecnologica specifica u insatgi che reelavura la documentaziun dal project. + +Ulteriurs detagls vesair Producing Open Source Software: Development Status.footnote:[https://producingoss.com/en/getting-started.html#state-freedom] + +=== Instanza da demonstraziun + +Tar applicaziuns è recumandabel da metter a disposiziun ina instanza da demonstraziun, per che l'applicaziun possia vegnir empruvada senza lavur d'installaziun. Tut tenor il gener da l'applicaziun po la instanza da demonstraziun esser l'installaziun productiva u in stgalim da test. Impurtant è ch'ils lecturs possian acceder a la instanza correspundenta uschè autonomamain e directamain sco pussaivel. + +Sco alternativa mettan blers projects open source a disposiziun utensilis per startar simplamain l'applicaziun. Quai po capitar per exempel cun containers, applicaziuns portablas u scripts d'installaziun. + +=== Persuna da contact spezialisada e proprietad dal project + +En la datoteca README.md duess vegnir numnada la persuna da contact spezialisada la pli impurtanta, per che autras administraziuns ed organisaziuns interessadas possian prender contact uschè directamain sco pussaivel. + +Adressas d'e-mail persunalas na duessan betg vegnir utilisadas. + +En la datoteca README.md duess ultra da quai vegnir descrit curtamain, tge organisaziun ch'è proprietaria dal project, en spezial sch'ina associaziun è vegnida fundada per il project. + +== Documentaziun d'installaziun + +Tar applicaziuns duess README.md renviar ad ina documentaziun d'installaziun che descriva las pretensiuns da hardware e software, tge cumponentas d'infrastructura (per exempel bancas da datas) ch'èn utilisadas e co che l'applicaziun po vegnir installada e manada. + +=== Developer Guidelines + +Il punct d'entrada per las Developer Guidelines duess vegnir archivà en ina datoteca Markdown CONTRIBUTING.md ch'è colliada en README.md. Las Developer Guidelines èn part da la documentaziun extendida per sviluppaders che vulan contribuir al project e sa concentreschan en emprima lingia sin la collavuraziun e la communicaziun en il project e betg sin la tecnica. + +Las Developer Guidelines duessan cuntegnair ils suandants puncts e renviar eventualmain als documents correspundents: + +* In renviament al code of conduct dal project. Il code of conduct fixescha las normas socialas spetgadas entaifer il project. +* I vegn recumandà da tscherner sco code of conduct il Contributor Covenant Code of Conduct licenzià sut CC-BY-4.0footnote:[https://creativecommons.org/licenses/by/4.0/] u da construir sin quel.footnote:[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html] +* Ina indicaziun che il project fa code reviews en furma da pull requests GitHub, cun in renviament a la documentaziun GitHub davart las pull requests. + +A la fin duess vegnir renvià a la Developer Documentation. + +=== Developer Documentation + +Entant che las Developer Guidelines descrivan la collavuraziun e las normas socialas dal project, sa concentrescha la Developer Documentation sin ils aspects tecnics da la participaziun al svilup dal project. Ella duess descriver almain ils suandants puncts: + +* Tge dependenzas tecnicas che il project ha e tge utensilis ch'èn necessaris per il svilup dal project. +* Tge reglas formalas che valan per il code da funtauna dal project, per exempel concernent la formataziun dal code da funtauna. +* Co che il code da funtauna dal project è organisà e co che funcziuns pon vegnir testadas tecnicamain. +* In sboz d'architectura cun ina descripziun gruassa da l'architectura, preferiblamain inclusiv la delimitaziun dal context ed ina vista gruassa da las cumponentas.footnote:[Rom d'architectura MMB (metoda da modellaziun da la Confederaziun) u arc42. http://arc42.org/] +* Tar applicaziuns: Co che l'applicaziun po vegnir startada per intents da svilup u da debugging e tge cumponentas d'infrastructura ch'èn necessarias per quai. + +== Documentaziun accumpagnanta per la link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[glista da controlla Em002-2.2 Analisa e preparaziun OSS] – Code da funtauna + +=== Cronologia dal code da funtauna + +Il code da funtauna d'in project vegn usitadamain archivà en in sistem da source code management (SCM) sco GitHub. Quests sistems memoriseschan betg mo il stadi actual dal code da funtauna, mabain era las midadas ch'èn vegnidas fatgas al code da funtauna en il decurs dal temp. Da quai fan part en spezial las stizzadas en il code da funtauna, inclusiv datotecas stizzadas. + +Ultra da quai cuntegna il SCM metainfurmaziuns davart midadas al code da funtauna, sco il num e l'e-mail da l'autura u da l'autur u signaturas PGP per commits e tags signads. + +=== Datas sensiblas, protegidas u confidenzialas + +Il code da funtauna e la cronologia dal code da funtauna dal project pon cuntegnair datas disponiblas publicamain, sco in register dals numers postals, datas generadas per casualitad u datas sinteticas. + +Il code da funtauna e la cronologia dal code da funtauna na dastgan cuntegnair naginas datas u infurmaziuns (persunalas) sensiblas u confidenzialas en il senn da la lescha davart la protecziun da datas (LPD) e da la lescha davart la segirezza da las infurmaziuns (LSIn). Da quai fan part en spezial: + +* Nums d'utilisader e pleds-clav u auters secrets sco clavs privatas, tokens d'access u certificats. +* Nums DNS interns, URLs, nums d'host, adressas IP, structuras da rait u nums da drives. +* Nums, adressas, maletgs u datas persunalas sumegliantas senza il consentiment da la persuna pertutgada +* Datas anonimisadas u pseudonimisadas (perquai ch'igl è pussaivel da revocar l'anonimisaziun u la pseudonimisaziun) + +Era sche il stadi actual dal code da funtauna è liber da datas u infurmaziuns sensiblas, protegidas u confidenzialas, pon talas datas u infurmaziuns vegnir consultadas vinavant da la cronologia dal sistem SCM, sch'ellas èn mai stadas part dal code da funtauna u da las metainfurmaziuns dal SCM en il passà. Ina rundada dal stadi actual dal code da funtauna n'allontanescha betg cumplettamain questas infurmaziuns.footnote:[Ina pussaivladad da rundar in repo porscha l'utensil https://rtyley.github.io/bfg-repo-cleaner/[BFG Repo-Cleaner]] + +En cas da dubi vegn perquai recumandà d'allontanar cumplettamain la cronologia da funtauna suenter la rundada dal code da funtauna, avant sia publicaziun. + +Ils nums e las adressas d'e-mail da las auturas e dals auturs dal code da funtauna èn usitadamain disponibels directamain en il code da funtauna u en las metadatas dal SCM, per exempel en commits GitHub u en tags GitHub annotads. Dal puntg da vista giuridic n'è quai betg problematic, perquai che l'interpresa che sviluppa sto reglar la publicaziun da talas infurmaziuns. I vegn dentant recumandà da render attenta l'interpresa che sviluppa resp. ils collaboraturs interns da la Confederaziun che ils nums e las adressas d'e-mail da las auturas e dals auturs dal code da funtauna pon vegnir revelads tar la publicaziun dal software. + +=== Allontanar las indicaziuns davart ils auturs + +La cronologia dal software po vegnir midada per zuppentar las indicaziuns davart ils auturs. Utensilisfootnote:[https://www.adamdehaven.com/blog/update-commit-history-author-information-for-git-repository/] pon automatisar quest pass en gronda part. + +L'allontanar da las indicaziuns davart ils auturs elimina l'attribuziun, la traçabilitad e las infurmaziuns da contact. La lavur colliada cun quai n'è betg da sutvalitar, tut tenor il volum dal code da funtauna. Per quests motivs na vegn l'allontanar dals auturs betg recumandà. Nums dastgan vegnir publitgads, sche a) il consentiment da las persunas pertutgadas è avant maun e b) nagins motivs relevants per la segirezza na s'opponan. + +=== Resguard da las licenzas da las bibliotecas + +Bunamain mintga project utilisescha bibliotecas da terzas persunas (bibliotecas da software, dependenzas) per acceder a funcziuns duvradas savens senza las stuair programmar sez. Questas bibliotecas dependan usitadamain d'autras bibliotecas, da quai resultan dependenzas a plirs stgalims (dependenzas transitivas). Tut tenor la lingua da programmaziun pon era projects pitschens avair tschientinas da dependenzas. + +Ils resultats da questa sclerida ston vegnir resguardads tar la tscherna da la licenza tenor link:em002-3.pdf[Em002-3 Guida da licenzas OSS] ed en la link:em002-2-3-checklist-oss-release-and-publication.pdf[glista da controlla Em002-2.3 Relaschada e publicaziun OSS]. + +Per mintgina da questas dependenzas sto vegnir garantì che sia licenza saja cumpatibla cun la licenza dal project. Spezialmain problematicas èn dependenzas che na stattan betg sut ina licenza open source, che n'han declerà nagina licenza u che utiliseschan ina licenza virala che na correspunda betg a la licenza dal project. Tschertas bibliotecas èn licenziadas sut dapli ch'ina licenza e permettan a l'utilisader da tscherner ina. + +* En tuttas linguas da programmaziun impurtantas sa laschan renumbrar automaticamain las dependenzas dal project (inclusiv las dependenzas transitivas) e las licenzas da las dependenzas. Da quai fan part: +* Il plugin Project Info Reports per il manager da pachets Apache Maven per projects Java che producescha cun il dependency report ina publicaziun HTML da tuttas bibliotecas utilisadas, inclusiv la licenza declerada.footnote:[Infurmaziuns davart il plugin https://maven.apache.org/plugins/maven-project-info-reports-plugin/plugin-info.html] +* Il NPM Licence Checker per il manager da pachets NPM per projects JavaScript che po publitgar tuttas bibliotecas utilisadas, inclusiv la licenza declerada, en differents formats, p.ex. CSV.footnote:[NPM Licence Checker https://github.com/davglass/license-checker] +* Il Licence Finder da Pivotal che sustegna differents managers da pachets e linguas da programmaziun, tranter auter Ruby Gems, Python Eggs e Godeps.footnote:[Licence Finder da Pivotal https://github.com/pivotal/LicenseFinder] + +== Utilisaziun da bibliotecas cun licenzas proprietaras + +Bibliotecas sut ina licenza proprietara èn fundamentalmain problematicas en projects open source e na pon per ordinari betg vegnir utilisadas, en spezial sche il code da funtauna è vegnì publitgà sut ina licenza virala sco l'AGPL. + +As drizzai p.pl. al purschider ed al servetsch giuridic da l'uffizi pertutgà per examinar, sche e sut tge cundiziuns che la biblioteca proprietara po vegnir utilisada en Voss project. + +=== Utilisaziun da managers da pachets + +Bunamain tuttas linguas da programmaziun derasadas mettan a disposiziun managers da pachets per administrar lur dependenzas, sco Apache Maven per projects Java, NPM per projects JavaScript u NuGet per projects .NET. + +Tar l'utilisaziun d'in manager da pachets n'èn las dependenzas utilisadas dal project betg pli directamain part dal code da funtauna dal project, per exempel cun copiar il code da funtauna da la dependenza en il project u cun copiar las dependenzas en furma binara en il project. Empè da quai obtegna il project tuttas sias dependenzas via las declaraziuns dal manager da pachets. + +Quai permetta da renumbrar e da referenziar correctamain tuttas dependenzas. Ultra da quai impedescha quai la midada nunintenziunada dal code da las dependenzas. Sche midadas èn necessarias, ston ellas vegnir fatgas directamain a la funtauna da la dependenza. + +=== Declaraziun da la licenza dal project en il descriptur dal manager da pachets + +Il project duess declerar sia licenza en il descriptur correspundent dal manager da pachets, cun utilisar l'identificatur SPDX,footnote:[Identificatur SPDX – https://spdx.org/] per che la licenza dal project possia vegnir publitgada dal manager da pachets. Quai è spezialmain impurtant tar bibliotecas, per che ils utilisaders da la biblioteca possian dumandar automaticamain sia licenza via il manager da pachets. + +=== Attribuziun ed indicaziuns da copyright + +Bleras bibliotecas suttastattan ad ina licenza che pretenda dals utilisaders da la biblioteca ina indicaziun da copyright originala u ina attribuziun. + +Da quai fan part las suandantas licenzas (extract): + +Apache 2.0, ASL 1.1 (Apache 1.1), BSD, BSD 3-Clause, Creative Commons «Attribution» (CC BY), MIT, ISC + +Per las autras vesair la glista da las licenzas renconuschidas da l'OSI.footnote:[Licenzas open source èn licenzas che correspundan a l'Open Source Definition – curt ditg permettan ellas d'utilisar, da midar e da cundivider libramain software. https://opensource.org/licenses] + +En la pratica pertutga quai bunamain tuttas bibliotecas utilisadas. Perquai che il dumber da las bibliotecas utilisadas en projects pitschens è gia fitg aut, è ina indicaziun da copyright giuridicamain correcta resp. l'attribuziun necessaria mo pussaivla cun ina gronda lavur. + +I vegn perquai recumandà da proceder uschia: + +* Far ina glista da las bibliotecas utilisadas, cun ils mecanissems dal manager da pachets u cun utensilis sco il NPM Licence Checker u il Licence Finder da Pivotal. +* Preparar la glista a maun, uschia ch'ella cuntegnia las suandantas indicaziuns: num ufficial dal project da la biblioteca, pagina d'internet dal project da la biblioteca, licenza utilisada per la biblioteca sco identificatur SPDX cun link sin il text da la licenza. +* Archivar la glista en il code da funtauna dal project, p.ex. en ina datoteca THIRD-PARTY-LICENSES.md. +* Tar applicaziuns: Integrar in link sin THIRD-PARTY-LICENSES.md en in dialog «Davart» u «Davart questa applicaziun». +* Il dialog «Davart» è fitg derasà per quest intent, per exempel en Google Chrome (en il dialog «Davart Chrome»). +* Tar bibliotecas: Renviar en README.md sut THIRD-PARTY-LICENSES.md. +* En il rom dal process da code review garantir che midadas a las bibliotecas vegnian actualisadas en THIRD-PARTY-LICENSES.md. + +== Exempel da bloc da code THIRD-PARTY-LICENSES.md + +Quest project utilisescha software open source: + +* Spring Boot, http://projects.spring.io/spring-boot/[projects.spring.io/spring-boot] licenzià sut http://www.apache.org/licenses/LICENSE-2.0[Apache-2.0] +* caniuse-db, https://github.com/Fyrd/caniuse[github.com/Fyrd/caniuse] licenzià sut https://creativecommons.org/licenses/by/4.0/[CC-BY-4.0] + +=== Documentaziun accumpagnanta per la glista da controlla Em002-2.3 Relaschada e publicaziun OSS + +==== Publicaziun cun publiccode.yml + +Publiccode.yml è in standard da metadatas per repositoris da software che cuntegnan software sviluppà u acquistà d'administraziuns publicas. La finamira è da render quest software pli facil da chattar e da reutilisar. Il standard da metadatas è stabilì internaziunalmain e descrit publicamain sut https://yml.publiccode.tools/. Ina datoteca publiccode.yml cuntegna tipicamain indicaziuns sco titel e descripziun (pussaivel en pliras linguas), stadi da svilup, indicaziuns da contact, infurmaziuns davart la licenza etc. Per la Svizra èn previsas extensiuns specificas per il pajais. + +Per mintga software sto vegnir creada ina datoteca yml en l'ordinatur principal dal repositori. Sche la soluziun consista da plirs repos (d'agid), basta ina datoteca, perquai che quella descriva il cas d'applicaziun da la soluziun. + +Cun agid da las datas structuradas en las datotecas publiccode.yml vegn generà per l'entira administraziun federala in https://www.opensource.admin.ch/[catalog OSS] (https://www.opensource.admin.ch[opensource.admin.ch]). Il catalog porscha ina survista dal software publitgà e facilitescha il chattar e la reutilisaziun da soluziuns existentas. + +Sch'in nov repositori u ina nova organisaziun vegn creà, sto quai vegnir annunzià per l'admissiun en il catalog OSS per e-mail a opensource@bk.admin.ch. + +Ultra dal catalog OSS stat era a disposiziun in editur grafic ed in validatur per datotecas publiccode.yml. + +Catalog OSS ed editur: https://www.opensource.admin.ch/ + +=== Ulteriuras funtaunas e licenza + +La glista da controlla, la documentaziun accumpagnanta ed ils models appartegnents sa basan per part sin las suandantas funtaunas: + +* Google Open Source Docs da Google LLC, licenzià sut 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 da 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/] +endif::[] diff --git a/docs/em002-3.adoc b/docs/em002-3.adoc new file mode 100644 index 0000000..a364e81 --- /dev/null +++ b/docs/em002-3.adoc @@ -0,0 +1,4245 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-3 OSS Licensing Guidelines +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-3 Leitfaden OSS-Lizenzierung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-3 Guide de licences OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-3 Guida alle licenze OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-3 Guida da licenzas OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +*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 {url-repo}/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: + +[mermaid,align="center",alt="Simplified licence selection guide"] +.... +flowchart TD + S(["Start"]) + Q1{"The 'environment'
enforces the licence"} + A["Select the
forced licence"] + Q2{"Library, reference implementation
or liberal requirements"} + B["MIT"] + C["AGPL"] + S --> Q1 + Q1 -->|"Yes"| A + Q1 -->|"No"| Q2 + Q2 -->|"Yes"| B + Q2 -->|"No"| C +.... + +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.pdf[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 _[Pe1999]_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. + +[mermaid,align="center",alt="Compatibility of open source licences"] +.... +flowchart TB + subgraph P["Permissive licence"] + PD["Public Domain"] + MIT["MIT/X11"] + BSD["Modified BSD"] + AP["Apache 2.0"] + end + subgraph W["Weak copyleft"] + EUPL["EUPL"] + LGPL21["LGPLv2.1"] + LGPL21P["LGPLv2.1+"] + LGPL3["LGPLv3 / LGPLv3.1"] + MPL["MPL 1.1"] + end + subgraph SC["Strong copyleft"] + GPL2["GPLv2"] + GPL2P["GPLv2+"] + GPL3["GPLv3 / GPLv3+"] + AGPL["Affero GPLv3"] + end + PD --> MIT + MIT --> BSD + BSD --> AP + BSD --> LGPL21 + BSD --> LGPL21P + BSD --> LGPL3 + BSD --> MPL + AP --> EUPL + AP --> LGPL3 + EUPL --> LGPL21 + EUPL --> LGPL21P + EUPL --> LGPL3 + EUPL --> MPL + LGPL21P --> LGPL21 + LGPL21P --> LGPL3 + LGPL21 --> GPL2 + LGPL21 --> GPL2P + LGPL21P --> GPL2P + LGPL3 --> GPL3 + GPL2P --> GPL2 + GPL2P --> GPL3 + GPL3 -->|"+ Network protection"| AGPL + classDef pd fill:#f5f5f5,stroke:#000000,color:#000000 + classDef perm fill:#dae8fc,stroke:#000000,color:#000000 + classDef weak fill:#d5e8d4,stroke:#000000,color:#000000 + classDef strong fill:#5ea226,stroke:#000000,color:#ffffff + class PD pd + class MIT,BSD,AP perm + class EUPL,LGPL21,LGPL21P,LGPL3,MPL weak + class GPL2,GPL2P,GPL3,AGPL strong +.... + +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.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.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 + +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.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.* + +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)* + +[mermaid,align="center",alt="Extended decision tree for licence selection in the Federal Administration"] +.... +flowchart TD + S(["Start"]) + Q1{"Does the bill of materials
enforce the licence?"} + R1["Select the forced /
preferred licence"] + Q2{"Are there preferred licences
in this environment?"} + Q3{"In the list of suitable
licences in Em002-3?"} + R2["Select the next best licence from the list
according to Em002-3 after consulting
the legal service"] + Q4{"Reference implementation
as a suggestion
for third parties?"} + R3["GPL or permissive licence:
MIT, BSD, Apache"] + Q5{"Must improvements
flow back?"} + Q6{"Also with SaaS use?"} + R4["GPL, EUPL"] + R5["AGPL"] + S --> Q1 + Q1 -->|"Yes"| R1 + Q1 -->|"No"| Q2 + Q2 -->|"Yes"| Q3 + Q2 -->|"No"| Q4 + Q3 -->|"Yes"| R1 + Q3 -->|"No"| R2 + Q4 -->|"Yes"| R3 + Q4 -->|"No"| Q5 + Q5 -->|"No"| R3 + Q5 -->|"Yes"| Q6 + Q6 -->|"No"| R4 + Q6 -->|"Yes"| R5 +.... + +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.pdf[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.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. + +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.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) + +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. + +[mermaid,align="center",alt="Transfer source code and rights in different constellations"] +.... +flowchart LR + subgraph TP["Third parties"] + TP1["no documents of their own"] + TP2["CLA
DCO
OSS licence"] + TP3["CLA
DCO
OSS licence
Contract"] + TP4["no documents of their own"] + end + subgraph FA["Federal Administration"] + FA1["General Terms and Conditions
of the Confederation
Contract"] + FA2["no documents of its own"] + FA3["OSS licence
Contract
(DCO)
(CLA)"] + FA4["OSS licence
(DCO)
(CLA)"] + end + TP1 -- "creation" --> FA1 + TP2 -- "contribution by the Federal Administration" --- FA2 + TP3 <-- "collaboration" --> FA3 + TP4 -- "contribution by third parties" --> FA4 +.... + +Figure 4: Transfer source code and rights in different constellations + +Legend: + +* The boxes show *where the rights are defined* in each constellation. +* *Creation* and *contribution by third parties*: the Federal Administration has the power to shape the situation. +* *Collaboration*: the documents are agreed between the parties. +* *Contribution by the Federal Administration*: the Federal Administration has no power to shape the situation, so a review is necessary. +* The legal documents are listed in order of priority, from top to bottom; documents in brackets should rather be avoided. + +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.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.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: + +* 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 [KBB-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 + +_[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.pdf[Em002 Strategic Guidelines for Open Source Software in the Federal Administration]. + +=== Abbreviations + +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 + +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). +endif::[] + +ifeval::["{lang}" == "de"] +*Haftungsausschluss:* 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 {url-repo}/tree/main[README]. + +''''' + +== Management Summary + +Es wird empfohlen, bei einem Projektstart in der Bundesverwaltung strategisch eine der folgenden beiden Lizenzen festzulegen: + +* *AGPL-Lizenz*: Copyleft-Effekt erwünscht. Geänderter Code soll in jedem Fall wieder der Allgemeinheit zufliessen und kann dann auch von der Bundesverwaltung wieder übernommen werden. Es wird empfohlen, die neuste Version der Lizenz zu verwenden. So lässt sich der Grundsatz «public money – public code» am besten erfüllen. Rechte Dritter, insbesondere bei Weiterentwicklungen, können dies auf LGPL abschwächen. +* *MIT-Lizenz*: Dritten soll es möglich sein, auf Basis des Codes der Bundesverwaltung proprietäre Anwendungen zu entwickeln. Wird ausdrücklich eine Non-Endorsement-Klausel verlangt, so ist BSD-3-Clause vorzuziehen. + +Zur Lizenzwahl kann die folgende Entscheidungshilfe verwendet werden: + +[mermaid,align="center",alt="Vereinfachte Entscheidungshilfe zur Lizenzwahl"] +.... +flowchart TD + S(["Start"]) + Q1{"Die «Umgebung»
gibt die Lizenz vor"} + A["Vorgegebene
Lizenz wählen"] + Q2{"Bibliothek, Referenzimplementierung
oder liberale Vorgaben"} + B["MIT"] + C["AGPL"] + S --> Q1 + Q1 -->|"Ja"| A + Q1 -->|"Nein"| Q2 + Q2 -->|"Ja"| B + Q2 -->|"Nein"| C +.... + +Abbildung 1: Vereinfachte Entscheidungshilfe zur Lizenzwahl + +In gewissem Sinne bilden diese beiden Lizenzen die beiden Extreme im Spektrum der OSS-Lizenzen. Es kann durchaus sinnvoll sein, für ein konkretes Projekt eine besser geeignete Lizenz zu wählen. Dieser Leitfaden soll dabei konkrete Unterstützung bieten. + +Ergibt die Analyse der Softwarebibliotheken, dass eine andere Lizenz verwendet werden muss, so weisen die Entwickelnden die Projektleitung darauf hin. Die Analyse ist in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] dargelegt. + +Bei der Mitarbeit an bestehenden Projekten sind grundsätzlich alle OSI-kompatiblen Lizenzen akzeptabel. + +== Einleitung + +Artikel 9 des Bundesgesetzes vom 17. März 2023footnote:[SR 172.019] über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) sieht vor, dass die Bundesbehörden Software, die sie entwickeln oder entwickeln lassen, als Open-Source-Software veröffentlichen und lizenzieren müssen. + +Dieses Dokument verfolgt die folgenden Ziele: + +* Einführung in die Themen Urheberrecht an Software und OSS-Lizenzen. +* Eine Darstellung, welche OSS-Lizenzen für den Einsatz in der Bundesverwaltung unproblematisch sind. In diesem Dokument nicht genannte Lizenzen und Software unter solchen Lizenzen dürfen ohne zusätzliche Prüfung der Vertragsbestimmungen durch den zuständigen Rechtsdienst nicht verwendet werden. +* Unterstützung bei der Lizenzwahl für die Entwicklung oder Beschaffung eines Projekts nach Art. 9 EMBAG. + +== Urheberrecht und Lizenzen: Grundlagen + +Das Urheberrecht begründet sowohl Persönlichkeitsrechte als auch Vermögensrechte (Verwertungsrechte). Zu den Persönlichkeitsrechten gehört beispielsweise das Recht auf Anerkennung der Urheberschaft oder das Recht zu bestimmen, ob und wann das Werk veröffentlicht wird. Zu den Verwertungsrechten gehört beispielsweise das Recht, Werkexemplare herzustellen oder zu verbreiten. + +Das Bundesgesetz vom 9. Oktober 1992footnote:[SR 231.1] über das Urheberrecht und verwandte Schutzrechte (URG) sieht eine Reihe weiterer Persönlichkeits- und Verwertungsrechte vor (siehe Art. 8 ff. URG). Diese Rechte stehen der Urheberin oder dem Urheber unmittelbar mit der Schaffung des Werks zu. + +Art. 2 URG legt fest, unter welchen Voraussetzungen urheberrechtlicher Schutz gewährt wird. Ein geschütztes Werk im Sinne des Gesetzes liegt nur vor, wenn diese Voraussetzungen erfüllt sind. + +Die Voraussetzungen sind: + +* Das Werk muss geschaffen worden sein; das blosse Auffinden genügt nicht. Forschungsdaten etwa, also Ergebnisse von Experimenten, lassen sich nicht als Werke einstufen. +* Die Schöpfung muss «geistig» sein, also von einem Menschen stammen. +* Das Werk muss in wahrnehmbarer Weise verwirklicht worden sein. Die blosse Idee hinter einem Werk ist nicht geschützt, sondern nur seine äussere Form, z. B. ein Ausdruck eines Textes auf Papier oder die Aufführung eines Musikstücks. +* Individualität: Schliesslich muss das Werk ein gewisses Mindestmass an Individualität aufweisen. Ein Werk, das jede und jeder gleich gestalten würde, ist nicht geschützt. + +Geschützt werden können ganz unterschiedliche Werke, etwa literarische oder wissenschaftliche Texte, Musikwerke, fotografische, filmische und andere visuelle oder audiovisuelle Werke. + +Nach Art. 2 Abs. 3 URG sind auch Computerprogramme Werke, sofern die genannten Voraussetzungen erfüllt sind. + +Die Urheberrechte stehen mit ihrer Entstehung allein der Urheberin oder dem Urheber zu. Nur sie oder er kann einer anderen Person untersagen, die entsprechenden Handlungen vorzunehmen. Die Urheberin oder der Urheber kann ihre bzw. seine Rechte jedoch nicht nur selbst ausüben: + +* Sie oder er kann die Rechte an Dritte übertragen (z. B. durch Verkauf). Die neue Rechtsinhaberin oder der neue Rechtsinhaber kann diese Rechte anschliessend gleich geltend machen wie die Urheberin bzw. der Urheber selbst. +* Alternativ kann die Urheberin oder der Urheber ihre bzw. seine Rechte Dritten auch lizenzieren. Vereinfacht gesagt ist eine Lizenz ein Vertrag, mit dem die Rechtsinhaberin oder der Rechtsinhaber einem Dritten die Nutzung des Werks erlaubt. Die Urheberin oder der Urheber behält die Rechte, verzichtet jedoch gegenüber der Lizenznehmerin bzw. dem Lizenznehmer auf deren Durchsetzung. + +Wird ein Computerprogramm im Arbeitsverhältnis geschaffen, so erhält die Arbeitgeberin eine ausschliessliche Lizenz zu dessen Nutzung (Art. 17 URG). Den Arbeitnehmenden verbleiben damit im Wesentlichen nur die Persönlichkeitsrechte an der Software (bzw. je nach Rechtsauffassung nur deren Kernbereich). Dies entspricht der Rechtslage nach dem Bundespersonalgesetz. + +== OSS-Lizenzen + +=== Grundlagen + +OSS zeichnet sich im Wesentlichen durch die folgenden Merkmale aus (nach einer Definition der Open Source Initiative _[Pe1999]_footnote:[https://opensource.org/]): + +* Die unbeschränkte und unentgeltliche Weiterverbreitung der Software ist erlaubt; +* Die Software liegt im Quellcode vor; +* Änderungen an der Software und deren Weiterverbreitung unter derselben Lizenz sind grundsätzlich erlaubt; +* Keine Personen oder Personengruppen dürfen von der Nutzung der Software ausgeschlossen werden, und keine Anwendungsbereiche dürfen ausgeschlossen werden (insbesondere nicht die kommerzielle Nutzung); und +* Die Verbreitung der Software zusammen mit anderer Software (etwa Closed-Source-Software) darf nicht eingeschränkt werden. + +Die häufigsten Motive für den Einsatz von OSS sind zunächst die Kosteneinsparungen durch die Nutzung des bereits beträchtlichen Pools frei verwendbarer Software. Unternehmen, die häufig OSS einsetzen, können oft erhebliche Teile ihres IT-Budgets durch den Einsatz von OSS einsparen. + +Frei verfügbarer Code lässt sich zudem leicht an die eigenen Bedürfnisse anpassen. Überdies vermeidet die Wahl von OSS einen Vendor-Lock-in.footnote:[https://de.wikipedia.org/wiki/Lock-in-Effekt] + +=== Open-Source-Lizenzen + +Open-Source-Lizenzen sind in erster Linie normale Lizenzverträge für Computerprogramme. + +Anders als normale Lizenzverträge kommen OSS-Lizenzverträge jedoch ohne Weiteres zustande, sobald nur eine der in der Lizenz beschriebenen freien Nutzungsformen ausgeübt wird (etwa durch Kopieren, Weiterverbreiten oder Ändern von Software). + +=== Copyleft versus permissiv + +==== Allgemeines + +Eine Open-Source-Lizenz nach der OSI kann eine «Copyleft»-Bestimmung enthalten. Änderungen an entsprechend lizenzierter Software müssen wieder unter denselben Bedingungen angeboten werden, die für die ursprüngliche Software galten. Wer solche Änderungen vornimmt, muss bei der Verbreitung der Open-Source-Software in Form von maschinenlesbarem Objektcode den Empfangenden auch den Quellcode anbieten. + +In der Formulierung der Free Software Foundation schützt der Copyleft-Effekt die Freiheit der Entwickelnden und stellt damit sicher, dass einmal freie Software immer frei bleibt. + +Bei Copyleft-Lizenzen findet eine Art Austausch zwischen der Community und den nutzenden Unternehmen statt. Die Nutzenden, die im Gegenzug für die Vorteile aus dem bestehenden Softwarepool verpflichtet sind, ihre eigenen Entwicklungen wieder unter die jeweilige Lizenz zu stellen, tragen so zur Weiterentwicklung des Softwarepools bei. Im Ergebnis profitieren beide Seiten. + +Die Copyleft-Bestimmung hat einen gewissen «Ansteckungseffekt»: Wird copyleft-lizenzierte Software in zuvor proprietäre Software integriert, so muss die ursprünglich proprietäre Software unter einer kompatiblen Open-Source-Lizenz offengelegt werden. + +Beim Einsatz von copyleft-lizenziertem Quellcode ist daher darauf zu achten, ihn nur dort zu integrieren, wo die entstehende Software unter einer Open-Source-Lizenz veröffentlicht werden kann und soll. + +Enthält eine Open-Source-Lizenz keine Copyleft-Bestimmung (permissive Open-Source-Lizenz), so kann die Lizenz für überarbeitete Fassungen des Codes frei gewählt werden. Insbesondere ist es auch möglich, Änderungen wieder unter eine proprietäre Softwarelizenz zu stellen und den entsprechenden Quellcode in proprietäre Software zu integrieren. + +Im Wesentlichen lassen sich Open-Source-Lizenzen in *die folgenden Kategorien* einteilen: + +. Open-Source-Lizenzen mit *starkem Copyleft*; +. Open-Source-Lizenzen mit *schwachem Copyleft*; und +. *permissive* bzw. *Non-Copyleft*-Open-Source-Lizenzen. + +==== Open-Source-Lizenzen mit starkem Copyleft + +Bei Verwendung einer Open-Source-Lizenz mit starkem Copyleft müssen neue, von der ursprünglichen Software abgeleitete Versionen, sofern sie an Dritte weitergegeben werden, unter die Bedingungen der ursprünglichen Lizenz gestellt und diesen Dritten als Quellcode zur Verfügung gestellt werden. + +Als massgebende Open-Source-Lizenzen mit starkem Copyleft gelten am Markt die folgenden beiden: + +* GNU General Public Licence (GPL); ein grosser Teil der OSS ist heute darunter lizenziert +* GNU Affero General Public Licence (AGPL) + +Der Hauptunterschied zwischen GPL und AGPL betrifft die Art der Nutzung, die das Copyleft auslöst. Bei GPL-Software muss der geänderte Quellcode nur angeboten werden, wenn die neue Softwareversion Dritten als ausführbares Programm angeboten wird (z. B. als mobile App). Wird die Software nur über das Internet zur Verfügung gestellt (aus der eigenen Cloud von eigenen Servern), etwa in Form von «Software as a Service» (SaaS) oder einer Programmierschnittstelle (API), so löst dies kein Copyleft aus. + +Steht die Software unter der AGPL, so muss der geänderte Quellcode auch dann mitgeliefert werden, wenn die Funktionalität der Software über eine Website oder eine Programmierschnittstelle angeboten wird. Die AGPL ist damit noch strenger als die GPL. + +Bei Lizenzen mit starkem Copyleft betrifft das Copyleft nicht nur das jeweilige Softwaremodul (Bibliothek), sondern das gesamte Softwareprogramm, in das ein copyleft-lizenziertes Softwaremodul eingebettet sein kann. Der erwähnte «Ansteckungseffekt» greift somit. + +==== Open-Source-Lizenzen mit schwachem Copyleft + +Auch Lizenzen mit schwachem Copyleft verlangen, dass Änderungen an ihrem Quellcode den empfangenden Dritten unter der ursprünglichen Open-Source-Lizenz freigegeben werden. + +Anders als Lizenzen mit starkem Copyleft bewirken sie jedoch nicht, dass andere abgrenzbare Softwarekomponenten (andere Bibliotheken oder das Hauptprogramm selbst) mit ihrer Lizenz «infiziert» werden. Dies erlaubt die Integration von Open-Source-Software mit schwachem Copyleft in proprietäre Software oder in Software mit anderen OSS-Lizenzen, ohne dass diese unter der ursprünglichen Lizenz freigegeben werden muss. + +Dies sind die am häufigsten verwendeten Open-Source-Lizenzen mit schwachem Copyleft: + +* GNU Lesser General Public Licence (LGPL) +* Mozilla Public Licence 2.0 (MPL) +* Common Development and Distribution Licence (CDDL) +* Eclipse Public Licence (EPL)footnote:[Neben der Eclipse Public Licence (EPL-1.0) gibt es auch die Eclipse Distribution Licence (EDL-1.0). + +Während die EDL der BSD-3-Clause entspricht, ist die EPL eine Lizenz mit schwachem Copyleft.] +* Microsoft Reciprocal Licence (Ms-RL) +* European Union Public Licence (EUPL)footnote:[Die EUPL selbst hat ein starkes Copyleft, doch ist aufgrund der Öffnungsklausel ein Übergang zu Lizenzen mit schwachem Copyleft möglich, sodass der Schutz begrenzt ist.] + +==== Permissive Open-Source-Lizenzen + +Lizenzen ohne Copyleft-Effekt zeichnen sich dadurch aus, dass sie den Lizenznehmenden keine Vorgaben zur Lizenzierung ihrer abgeleiteten Software machen und daher weder ihr neuer Quellcode noch Änderungen an der Open-Source-Software den empfangenden Dritten offengelegt werden müssen. Dies ermöglicht die Entwicklung proprietärer Softwareprodukte durch die Integration von Software unter permissiven Open-Source-Lizenzen. + +Beispiele permissiver Lizenzen sind: + +* MIT Licence +* Apache Licence 2.0 +* Berkeley Software Distribution (BSD) Licence (BSD 2-Clause und BSD 3-Clause) +* Microsoft Public Licence (Ms-PL) + +=== Kompatibilität von Open-Source-Lizenzen + +Programme bestehen in der Regel aus einer Vielzahl von Softwarekomponenten und -modulen, die auf unterschiedliche Weise miteinander verbunden sein können. In der Softwareentwicklung werden bestehende Open-Source-Komponenten häufig in proprietäre, interne Anwendungen und Lösungen integriert. Sobald diese von aussen über eine Website, APIs, Softwareverteilung oder auf andere Weise zugänglich werden, ist auf die Kompatibilität der jeweiligen Open-Source-Lizenzen zu achten, denn dann kann das Copyleft greifen. + +Dürfen abgeleitete Werke, die unter einer bestimmten Lizenz stehen, nur unter denselben Lizenzbedingungen verbreitet werden, so hat dies zur Folge, dass andere Open-Source-Lizenzen mit anderen oder widersprüchlichen Lizenzpflichten für abgeleitete Werke nicht verwendet werden können. + +Manche Open-Source-Lizenzen enthalten sogenannte Öffnungsklauseln, die die Verwendung des darunter lizenzierten Codes in Projekten erlauben, die unter anderen Lizenzen stehen. So erlaubt etwa die LGPL, Version 2.1, auch die Verwendung des Codes unter der GPL. Die GPLv3 enthält unter anderem eine Kompatibilitätsklausel für die AGPL und die Apache License 2.0. Die EUPL ist sehr offen gestaltet und enthält im Anhang eine lange Liste kompatibler Lizenzen, insbesondere solcher mit schwachem Copyleft wie der LGPL. Dies hat zur Folge, dass der in der Lizenz eigentlich vorgesehene starke Copyleft-Schutz indirekt abgeschwächt wird. + +Die folgende Grafik bildet die Abhängigkeiten der wichtigsten Open-Source-Lizenzen ab (Goldstein 2018). Die Darstellung beruht auf der Visualisierung von David A. Wheeler, der die Kompatibilitäten der verschiedenen Lizenzen und ihrer Versionsnummern analysiert hat (Wheeler 2007), und wurde zusammen mit Angaben von https://www.gnu.org/licenses/license-list.de.html[https://www.gnu.org/licenses/license-list.de.html] weiterentwickelt.footnote:[Eine weitere, erweiterte Darstellung verwendet GEANT in seinem 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. Dort finden sich einige zusätzliche Lizenzen.] + +Die Grafik ist wie folgt zu lesen: Code nach einer früher in der Kette aufgeführten Lizenz kann in Software übernommen werden, die unter einer später in der Kette aufgeführten Lizenz veröffentlicht wird. So kann etwa Code unter der modifizierten BSD unter eine LGPL- oder GPL-Lizenzvariante gestellt werden, aber nicht umgekehrt. Public Domain bedeutet, dass das Werk keinen urheberrechtlichen Beschränkungen unterliegt. + +[mermaid,align="center",alt="Kompatibilität von Open-Source-Lizenzen"] +.... +flowchart TB + subgraph P["Permissive Lizenz"] + PD["Public Domain"] + MIT["MIT/X11"] + BSD["Modifizierte BSD"] + AP["Apache 2.0"] + end + subgraph W["Schwaches Copyleft"] + EUPL["EUPL"] + LGPL21["LGPLv2.1"] + LGPL21P["LGPLv2.1+"] + LGPL3["LGPLv3 / LGPLv3.1"] + MPL["MPL 1.1"] + end + subgraph SC["Starkes Copyleft"] + GPL2["GPLv2"] + GPL2P["GPLv2+"] + GPL3["GPLv3 / GPLv3+"] + AGPL["Affero GPLv3"] + end + PD --> MIT + MIT --> BSD + BSD --> AP + BSD --> LGPL21 + BSD --> LGPL21P + BSD --> LGPL3 + BSD --> MPL + AP --> EUPL + AP --> LGPL3 + EUPL --> LGPL21 + EUPL --> LGPL21P + EUPL --> LGPL3 + EUPL --> MPL + LGPL21P --> LGPL21 + LGPL21P --> LGPL3 + LGPL21 --> GPL2 + LGPL21 --> GPL2P + LGPL21P --> GPL2P + LGPL3 --> GPL3 + GPL2P --> GPL2 + GPL2P --> GPL3 + GPL3 -->|"+ Netzwerkschutz"| AGPL + classDef pd fill:#f5f5f5,stroke:#000000,color:#000000 + classDef perm fill:#dae8fc,stroke:#000000,color:#000000 + classDef weak fill:#d5e8d4,stroke:#000000,color:#000000 + classDef strong fill:#5ea226,stroke:#000000,color:#ffffff + class PD pd + class MIT,BSD,AP perm + class EUPL,LGPL21,LGPL21P,LGPL3,MPL weak + class GPL2,GPL2P,GPL3,AGPL strong +.... + +Abbildung 2: Kompatibilität von Open-Source-Lizenzen (in Anlehnung an die Grafik von David A. Wheeler, 2007 und https://www.gnu.org/licenses/license-list.de.html) + +Wichtig: Da Lizenzkompatibilitäten stets relevant sind, sollten die Entwicklungsteams bzw. Leistungserbringer die Entwicklungs-Stacks mit Bibliotheken vorgängig auf mögliche Kompatibilitätsprobleme prüfen. Das heisst: Bevor der Einsatz einer Bibliothek durchgewinkt wird, sollte neben Sicherheit und Homogenität im Entwicklungs-Stack geprüft werden, ob die Lizenz der Bibliothek mit den massgebenden, von der Bundesverwaltung bevorzugten Lizenzen kompatibel ist. + +[[licences-for-pure-usage]] +== Lizenzen für die reine Nutzung + +Dieses Kapitel behandelt die Situation, in der Software unter einer OSS-Lizenz genutzt werden soll, diese Software jedoch nicht verändert werden soll oder Änderungen nur intern genutzt werden. + +Die folgenden Lizenzen sind bei der Nutzung von Software durch Bundesbehörden grundsätzlich unproblematisch. Die entsprechenden Bedingungen, namentlich ein allfälliges Copyleft, sind jedoch einzuhalten. + +Unter Umständen bestimmt die Lizenz eines bereits bestehenden Softwaremoduls die möglichen Lizenzen für das Gesamtprodukt (siehe Kapitel 4.4). + +Manche Lizenzen sind in Kombination inkompatibel (siehe Abbildung 2). + +[cols="1,1,3",options="header"] +|=== +|Lizenz |Copyleft |Besonderheiten + +|*MIT* +|Nein +|Bevorzugte Lizenz der Bundesverwaltung, wenn eine Weiterverbreitung angestrebt wird und Dritten erlaubt werden soll, daraus wieder proprietäre Software zu entwickeln. + +|*Apache 2.0* +|Nein +|Apache ist eine sehr verbreitete Lizenz, bekannt durch die Projekte unter der Apache Foundation. Nutzung der Marken der Lizenzgebenden ausgeschlossen, ausser zur Beschreibung des Werks. + +|*GPL v3* +|Ja +a|Dies ist DIE klassische Copyleft-Lizenz. + +Das Copyleft gilt auch, wenn GPL-lizenzierte Teile in ein Gesamtprogramm eingebunden werden. Verbot von Digital Rights Management. Besondere Kompatibilitätsregeln. + +|*LGPLv3* +|Schwach +a|Reduzierte Copyleft-Lizenz, eigens für Softwarebibliotheken entwickelt. + +Anders als die GPL erlaubt die LGPL, geschlossenen (also proprietären) Code unter bestimmten Bedingungen mit LGPL-Code zu kombinieren. + +Beispiele sind Standardbibliotheken wie glibc. Die LGPL erlaubt, das Programm, als dessen Teil die Bibliothek verbreitet wird, unter die GPL zu stellen. + +|*Affero GPLv3 (AGPL)* +|Ja +a|Auch die SaaS-Nutzung löst Copyleft aus. Im Übrigen analog zur GPLv3. + +Diese Lizenz schliesst die Lücke der GPL, die dazu führte, dass bei der Nutzung für SaaS-Angebote keine Freigabe nötig war. + +Mit dieser Lizenz kann die Bundesverwaltung sicherstellen, dass Erweiterungen des Codes auch bei SaaS der Allgemeinheit zugutekommen, und unterstützt den Grundsatz *«public money – public code»* am besten. + +|*BSD-3* +|Nein +a|Allgemeine, liberale Lizenz. + +Namen der Autorinnen und Autoren dürfen nicht zur Bewerbung abgeleiteter Werke verwendet werden (Werbeklausel) + +|*European Union Public Licence (EUPL)* +|Schwach +a|Besondere Lizenz, die für die EU verwendet wird. + +Besonders geeignet als Grundlage für europäische Projekte. + +Lizenz unter Berücksichtigung des europäischen Rechts. Freigabe unter bestimmten kompatiblen Lizenzen ausdrücklich erlaubt. +|=== + +Tabelle 1: Für die Bundesbehörden unproblematische Lizenzen (nach _[Sc2024]_) + +Andere Lizenzen dürfen verwendet werden. In diesen Fällen kann es nötig sein, den Rechtsdienst des jeweiligen Amtes beizuziehen. + +== Lizenz für eigene Projekte bzw. Creation und für Contributions + +Dieses Kapitel betrifft die folgenden Fälle: + +* Weiterentwicklung / Contribution +** bei der Bundesbehörden bestehende Software weiterentwickeln; oder +** neue Software entwickeln, dabei aber auf bestehende OSS-Softwarebibliotheken zurückgreifen; und +** die entsprechende Software Dritten zur Verfügung stellen. Zu den Dritten zählen auch Organisationen der dezentralen Bundesverwaltung, sofern sie eine eigene Rechtspersönlichkeit haben. Werden die Weiterentwicklungen nur intern genutzt und nicht Dritten zur Verfügung gestellt, so gilt nur <>. +* Eigene Projekte / Creation / Veröffentlichung: Dieses Kapitel betrifft Fälle, in denen die Bundesbehörden neue Software entwickeln. Dies dürfte selten sein, da die meisten Entwicklungen auf bestehende Open-Source-Softwarebibliotheken zurückgreifen. ++ +Für vollständige Neuentwicklungen sollte ein Lizenztyp gewählt werden, der eine breite und nachhaltige Grundlage für Weiterentwicklungen ermöglicht. Wichtig ist dabei, dass die betreffende Lizenz in der massgebenden Entwickler-Community breit akzeptiert ist. + +Die Kompatibilitätsprüfung erfolgt nach link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS], Kapitel 7.4. Die Kompatibilität der Lizenzen zeigt Abbildung 2. + +Die folgenden Dimensionen sollten berücksichtigt werden: + +* Anwendungsfall +* Gewünschte Prüfung link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] +* Einfachheit des Community-Aufbaus link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] +* Einfachheit der Anwendung +* Rechtssicherheit +* Verbreitung + +Lizenzen nach Kapitel <> sind zu bevorzugen. + +Die folgenden *Copyleft-Lizenzen* sollten von den Bundesbehörden vorrangig verwendet werden, insbesondere wenn eine nachhaltige offene Entwicklung angestrebt wird und der vererbende Copyleft-Effekt gelten soll. Damit wird sichergestellt, dass von der Öffentlichkeit bezahlte Software und sämtliche Ableitungen davon offen bleiben. Dies erfüllt den Grundsatz «*public money – public code*» am besten und ist *die bevorzugte Empfehlung für die Bundesverwaltung.* + +Empfohlene Lizenzen in absteigender Reihenfolge: + +* *AGPL v3* +* GPL v3 +* LGPL 3.0 +* European Union Public Licence (EUPL) + +Die folgenden Lizenzen sollten von den Bundesbehörden verwendet werden, wenn *kein Copyleft gewünscht* oder erforderlich ist (in absteigender Reihenfolge): + +* *MIT* +* Apache Licence 2.0 +* BSD v3 + +Bei der Mitarbeit an bestehenden Projekten können zudem problemlos die folgenden Lizenzen verwendet werden: + +* Mozilla Public Licence +* Microsoft Public Licence + +Soll eine andere Lizenz verwendet werden, so wird empfohlen, dies in der link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] kurz zu begründen. + +*Nach Art. 9 Abs. 4 EMBAG sollen in jedem Fall international etablierte Lizenzen verwendet werden.* + +Weitere Werkzeuge zur Prüfung von Lizenzkompatibilitäten sind: + +* ORT Toolkit (https://oss-review-toolkit.org/) +* Black Duck (www.blackducksoftware.com), +* FOSSA (http://www.fossa.com[www.fossa.com]), +* das Open Source Licence Comparison Grid (https://www.cmu.edu/cttec/forms/opensourcelicensegridv1.pdf) +* FOSSology (https://www.fossology.org). +* OpenCode-Prozess: https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen[https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses] + +== Anwendungsfälle und geeignete Lizenzen + +Die folgende Tabelle und die folgende Grafik zeigen, wie anhand unterschiedlicher Anwendungsfälle geeignete Lizenzen für Open-Source-Software ausgewählt werden können. + +[cols="2,2,3",options="header"] +|=== +|*Anwendungsfall* |*Lizenz(en)* |*Begründung* + +|Bestehendes Projekt nutzen und dazu beitragen +|*Lizenz gemäss Vorgabe des Projekts* +|Aus rechtlichen Gründen erforderlich. + +|Die Lizenz ist durch die Verwendung bestehender Teile vorgegeben (Lizenzen mit Copyleft) +|*Mit den Teilen kompatible Lizenz verwenden.* +a|Aus rechtlichen Gründen erforderlich. + +Hinweis: Eine Reihe von Bibliotheken ist unter mehreren Lizenzen verfügbar. + +Nur eine der Lizenzen muss übereinstimmen. Einer der Zwecke der Mehrfachlizenzierung ist es, sicherzustellen, dass Bibliotheken sowohl mit als auch ohne Copyleft genutzt werden können. + +|Bestehendes Ökosystem mit bevorzugter Lizenz (z. B. handelt es sich um ein Plug-in für Software, die unter MIT-Lizenz veröffentlicht ist. Dann wäre die Verwendung einer MIT-Lizenz am zweckmässigsten, da alle anderen Nutzenden dies erwarten und sich die Software in das Ökosystem einfügt) +|*Lizenz verwenden, wenn sie auf der Liste steht, ansonsten möglichst dieselbe Lizenz verwenden* +|Die Akzeptanz in der Community ist zentral. + +|Ziel ist eine möglichst breite Verbreitung, z. B. bei einer Referenzimplementierungfootnote:[Um beispielsweise ein Gesetz leichter umsetzbar zu machen, kann eine Referenzimplementierung von den Bundesbehörden in Auftrag gegeben werden. Siehe z. B. https://ech.ch/de/ech/ech-0238/1.0] (z. B. bei Software, die auch in kommerziellen Lösungen eingesetzt werden soll). +a|*MIT* + +BSD v3 + +Apache Licence 2.0 + +LGPL v3 +|In diesem Fall sollte kein Copyleft verwendet werden. + +|Änderungen am Code sollen an die Bundesbehörden zurückfliessen +a|*AGPL v.3* + +GNU GPL v.3 + +EUPL +|Die AGPL erzwingt die Freigabe durch Dritte auch bei der Nutzung in der Cloud, GPL und EUPL nicht. + +|SaaS-Lösungen sollen vom Rückfluss von Codeänderungen nicht ausgenommen sein +|*AGPL v.3* +|Die AGPL erzwingt die Freigabe durch Dritte auch bei der Nutzung in der Cloud. + +|Eine einfache Zusammenarbeit mit der Community ist wichtig. +a|*AGPL v.3* + +GNU GPL v3 + +Apache Licence 2.0 +a|GPL wird bevorzugt, um die Software frei zu halten. + +Apache enthält Regeln für die Community-Governance, zusätzliche Regeln für Beiträge (man darf keine andere Lizenz als Apache angeben; der Beitrag als solcher ist nicht näher geregelt, besteht also ein CLA, so geht dieses vor), eine Patentlizenz sowie Regeln zur Patentlizenzierung. Insbesondere auch, dass jemand, der Patente gegen eine andere beitragende Person geltend macht, seine Patentlizenz unter der Apache-Lizenz verliert. + +Massgebend sind die Regeln, welche die Apache Foundation für Beiträge festlegt. Apache ist daher sinnvoll, wenn die Projekt-Governance in erster Linie nach Apache aufgebaut werden soll. + +|Kleine, universell nutzbare Komponente (Bibliothek) oder kleines Stück Software, bei dem Nachhaltigkeit oder Pflege durch eine Community nicht wichtig ist +a|*MIT* + +Apache Licence 2.0 + +BSD v3 + +LGPL v3 +a|Die LGPL sieht ein Copyleft nur für die Komponente selbst vor, nicht jedoch für das gesamte Projekt, in das die Komponente eingefügt wird. + +Die anderen Lizenzen sind permissiv. + +|Es muss einfach und permissiv sein; Kontrolle ist nicht wichtig +a|*MIT* + +Apache Licence 2.0 + +BSD v3 +|Maximal permissiv + +|Es ist für die Bundesbehörden wichtig, was mit dem Code geschieht, und sie möchten möglichst viele Verbesserungen erhalten. +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Es soll verhindert werden, dass die Software proprietär wird und als Konkurrenzprodukt am Markt positioniert wird +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Es soll verhindert werden, dass die Bundesbehörden von einzelnen Lieferanten abhängig werden («Vendor-Lock-in») +a|*AGPL v.3* + +GNU GPLv3 +|Das Copyleft verhindert, dass ein Lieferant mit der Zeit eine Alleinstellung erlangt, indem er die Software des Bundes in einem proprietären Produkt nutzt, was für den Bund wiederum zu einer Abhängigkeit von diesem Lieferanten führen könnte. +|=== + +Tabelle 2: Je nach Anwendungsfall zu verwendende Lizenz für die Freigabe neuer Software nach Art. 9 EMBAG *(fett = empfohlen, sofern keine Gründe dagegensprechen)* + +[mermaid,align="center",alt="Erweiterter Entscheidungsbaum zur Lizenzwahl in der Bundesverwaltung"] +.... +flowchart TD + S(["Start"]) + Q1{"Gibt die Stückliste
die Lizenz vor?"} + R1["Vorgegebene /
bevorzugte Lizenz wählen"] + Q2{"Gibt es in dieser Umgebung
bevorzugte Lizenzen?"} + Q3{"In der Liste geeigneter
Lizenzen in Em002-3?"} + R2["Nächstbeste Lizenz aus der Liste
gemäss Em002-3 nach Rücksprache
mit dem Rechtsdienst wählen"] + Q4{"Referenzimplementierung
als Vorschlag
für Dritte?"} + R3["GPL oder permissive Lizenz:
MIT, BSD, Apache"] + Q5{"Müssen Verbesserungen
zurückfliessen?"} + Q6{"Auch bei SaaS-Nutzung?"} + R4["GPL, EUPL"] + R5["AGPL"] + S --> Q1 + Q1 -->|"Ja"| R1 + Q1 -->|"Nein"| Q2 + Q2 -->|"Ja"| Q3 + Q2 -->|"Nein"| Q4 + Q3 -->|"Ja"| R1 + Q3 -->|"Nein"| R2 + Q4 -->|"Ja"| R3 + Q4 -->|"Nein"| Q5 + Q5 -->|"Nein"| R3 + Q5 -->|"Ja"| Q6 + Q6 -->|"Nein"| R4 + Q6 -->|"Ja"| R5 +.... + +Abbildung 3: Erweiterter Entscheidungsbaum zur Lizenzwahl in der Bundesverwaltung (falls nicht AGPL oder MIT) + +Die Stückliste in Abbildung 3 ist die Software Bill of Materials (SBOM) aller bereits bestehenden Softwarebibliotheken und Teilprogramme, die in die Gesamtlösung eingeflossen sind. Jede Bibliothek hat ihre eigene Lizenz. Je nachdem, wie diese mit anderen kompatibel ist (siehe Kapitel 4.4), ist die mögliche Auswahl an Lizenzen für die Veröffentlichung eingeschränkt. + +Ein letzter Punkt kann den Entscheid ebenfalls beeinflussen: *Der Wechsel von einer restriktiveren zu einer weniger restriktiven Lizenz ist nachträglich einfacher*. Im umgekehrten Fall ist ein Forkfootnote:[Zur Definition siehe link:em002-1.pdf[Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung].] kaum zu vermeiden. + +== Besondere rechtliche Themen + +=== Internationale Aspekte + +Die wesentlichen Rechtsfragen von OSS in der Praxis sind überwiegend lizenzvertraglicher Natur. + +Bei lizenzrechtlichen Fragen gilt zunächst das von den Parteien gewählte Recht (die Mozilla Public License MPL etwa enthält in Ziffer 8 eine Rechtswahl zugunsten des Rechts der beklagten Partei). + +Fehlt eine Rechtswahl, was bei allen übrigen hier vorgestellten Lizenzen der Fall ist, so gilt in der Regel das Recht des Staates der lizenzgebenden Partei. Lizenzieren Bundesbehörden also Software von ausländischen Lizenzgebenden, so gilt das Recht des jeweiligen Landes. Sind mehrere Beitragende beteiligt, so kann dies zu komplexen Situationen führen. Umgekehrt gilt bei allfälligen Streitigkeiten zwischen ausländischen Lizenznehmenden und den Bundesbehörden als Lizenzgeberin Schweizer Recht. + +Die Frage, welche Aspekte vertraglicher und welche urheberrechtlicher Natur sind, lässt sich nicht allgemein beantworten und kann im Einzelfall recht komplex sein. Die Übertragbarkeit des Urheberrechts oder von Teilen davon oder der Umfang zulässiger Rechtseinräumungen gehören etwa zum Urheberrecht. Hier ist das Recht des jeweiligen Schutzlandes anzuwenden. Eine abweichende Rechtswahl ist nicht möglich (zum Ganzen siehe Jaeger/Metzger, 449 ff.). + +=== Haftungs- und Gewährleistungsausschluss + +Open-Source-Lizenzen schliessen regelmässig jede Gewährleistung und Haftung so weit aus, wie dies rechtlich zulässig ist. In der Praxis treten selten Haftungs- oder Gewährleistungsfragen auf; die damit verbundenen Risiken sind daher gering. + +Es ist davon auszugehen, dass bei korrekter Lizenzierung die in allen hier behandelten Lizenzen vorhandenen Haftungsausschlussklauseln greifen, sodass nur die Haftung für grobe Fahrlässigkeit und Vorsatz, allenfalls für Personenschäden, bestehen bleibt. + +Regeln zu allgemeinen Geschäftsbedingungen bleiben vorbehalten, etwa wie in Deutschland; soweit jedoch die Bundesbehörden als Lizenzgeberin Haftungssubjekt sind, gilt Schweizer Recht (siehe 8.1 oben), das die genannten Haftungs- und Gewährleistungsausschlüsse im B2B-Verkehr zulässt. + +Umgekehrt bedeutet dies aber auch, dass bei Programmfehlern ein Vorgehen gegen die Autorinnen und Autoren des enthaltenen OSS-Codes in der Regel schwierig ist. + +Das übliche Vorgehen beim Einsatz von OSS besteht daher regelmässig darin, sich mit den üblichen IT-Sicherheitsmassnahmen gegen Fehler abzusichern und die Fehlerbehebung über Wartungsverträge sicherzustellen. Ein Rückgriff auf OSS-Beitragende besteht nicht. + +=== Copyleft und Lizenzierung zwischen Stellen der Bundesverwaltung + +Das Copyleft gilt bei der Weitergabe zwischen verschiedenen Rechtsträgern (beispielsweise innerhalb eines Konzerns oder zwischen Stellen der dezentralen Bundesverwaltung mit eigener Rechtspersönlichkeit). + +Das Copyleft gilt nicht bei der Weitergabe zwischen Stellen desselben Rechtsträgers (beispielsweise innerhalb der zentralen Bundesverwaltung). + +=== Lizenzierung von Patenten + +Softwarepatente sind nach europäischer Rechtsauffassung nur in engen Grenzen möglich. Entscheidend ist, dass die Software einen technischen Beitrag leistet, also ein konkretes technisches Problem ausserhalb des Computers löst, auf dem sie läuft. Beispiele wären die Motorsteuerung in Autos oder die Steuerung eines Roboters. Software als solche, die nur auf einem Computer läuft, aber keine solche Aussenwirkung hat, ist in Europa grundsätzlich nicht patentierbar. Damit fallen die meisten Softwareprogramme nicht in den Anwendungsbereich des Patentrechts. + +In anderen Teilen der Welt, insbesondere in den USA, werden Softwarepatente etwas grosszügiger erteilt. Doch auch in den USA wird eine abstrakte Idee oder ein Geschäftsmodell nicht allein dadurch zur patentierbaren Erfindung, dass sie in Computersoftware umgesetzt wird. + +Bei manchen Lizenzen werden allfällige Patente der lizenzgebenden Partei nicht mitlizenziert. Dies sind die GPL2, die BSD-Lizenzen und die MIT-Lizenz. + +Bei Projekten, die auch ausserhalb Europas genutzt werden könnten oder die die genannte Form der Aussenwirkung aufweisen, empfiehlt es sich, die patentrechtlichen Aspekte im Einzelfall abzuklären. + +=== Duale Lizenzierung + +Die Urheberin oder der Urheber kann Software gleichzeitig unter verschiedenen Lizenzen lizenzieren. Dies wird duale Lizenzierung genannt. + +Eine interessante Form der dualen Lizenzierung liegt vor, wenn die Rechtsinhaberin die Software als OSS mit starkem Copyleft lizenziert (was deren Integration in proprietäre Software verhindert) und interessierten Lizenznehmenden zugleich eine _kostenpflichtige_ Lizenz anbietet, die ihnen die Integration der Software in ihre proprietäre Software erlaubt. + +Weil interessierte Lizenznehmende so vermeiden können, ihre proprietäre Software als OSS freizugeben, sind sie bereit, für die Lizenz zu bezahlen. Siehe auch den Anhang zu link:em002-1.pdf[Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung]. + +Für die Bundesbehörden selbst dürfte die duale Lizenzierung in den meisten Fällen uninteressant sein. Solange die Urheberrechte bei den Bundesbehörden liegen (was etwa nach den allgemeinen Geschäftsbedingungen des Bundes geregelt ist), können die Bundesbehörden allein über eine allfällige duale Lizenzierung entscheiden. + +Werden Wartung und (Weiter-)Entwicklung an Dritte ausgelagert, so kann dies anders sein. Liegen die Rechte ausnahmsweise bei diesen und haben sich die Bundesbehörden nur das Recht auf Erteilung einer OSS-Lizenz mit Copyleft vorbehalten, so könnte der Dritte versucht sein, eine duale Lizenzierung vorzunehmen. Soll dies verhindert werden, so sollte es vertraglich ausgeschlossen werden. + +=== Nachträgliche Änderung von Lizenzen + +Zunächst ist festzuhalten, dass OSS-Lizenzen grundsätzlich unveränderlich und unwiderruflich sind. Lizenznehmende, die den Lizenzvertrag _vor_ einer Änderung abgeschlossen haben, können den Code weiterhin auf Grundlage der alten Lizenz nutzen, verändern und an Dritte weitergeben. + +In der Praxis führt eine Lizenzänderung oft zu einem Fork einer neuen Version der Software unter der alten Lizenz, der von den bisherigen Lizenznehmenden eigenständig weiterentwickelt wird. + +Die Einführung einer neuen Lizenz für Software ist nur möglich, wenn alle Urheberrechtsinhabenden der Software zustimmen. Änderungen sind in der Praxis vorgekommen, etwa beim Wechsel von einer permissiven zu einer Copyleft-Lizenz. + +=== Nennung von Beitragenden (Mitarbeitende und Dritte) + +Wird ein Computerprogramm im Arbeitsverhältnis geschaffen, so erhält die Arbeitgeberin eine ausschliessliche Lizenz zu dessen Nutzung (Art. 17 URG). Den Arbeitnehmenden verbleiben damit im Wesentlichen nur die Persönlichkeitsrechte an der Software (bzw. je nach Rechtsauffassung nur deren Kernbereich). Dasselbe gilt für Dritte, die Software für die Bundesbehörden entwickeln, sofern die entsprechenden AGBfootnote:[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] des Bundes gelten, welche die entstehenden Rechte an die Bundesbehörden übertragen. + +Dennoch stellt sich die Frage, ob Beitragende (Mitarbeitende, Dritte) das Recht oder die Pflicht haben sollen, sich in Open-Source-Repositories als Autorinnen und Autoren von Beiträgen zu erkennen zu geben. + +Ein Argument für die Bundesbehörden, OSS einzusetzen, ist das Angebot attraktiver Arbeitsplätze: OSS bietet Beitragenden die Möglichkeit, ihr Wissen öffentlich zu zeigen und sich so einen Ruf aufzubauen. Ihre Fähigkeiten werden überprüfbar, werden von Peers bestätigt, und wer in einem OSS-Projekt Einfluss gewonnen hat, kann dies bei der Stellensuche als Hebel nutzen. + +Ein weiteres Argument könnten die Persönlichkeitsrechte sein, deren Kernbereich der ursprünglichen Urheberin bzw. dem ursprünglichen Urheber weder vertraglich noch gesetzlich entzogen werden kann. Dieser Kernbereich ist bei Computerprogrammen jedoch klein; zu verlangen, dass die Entwicklerin oder der Entwickler eines Computerprogramms auch ein Recht auf Nennung haben sollte, ginge wohl zu weit. + +Zudem setzt ein Austausch zwischen Fachpersonen in der Community voraus, dass sie von anderen einzeln angesprochen werden können. + +Je nach Projekt kann es daher sinnvoll sein, Beitragenden die Möglichkeit zu geben, sich in der Community als Beitragende zu erkennen zu geben. + +Aus Sicht des Datenschutzes ist ein Zwang dazu zu vermeiden, wobei der Austausch in der Community keine Offenlegung von Namen voraussetzt – Pseudonyme sind eher die Regel als die Ausnahme. Wollen Beitragende ihre Namen nicht offenlegen, so sollte ihnen daher die Möglichkeit gegeben werden, unter einem Pseudonym aufzutreten. + +*Es wird empfohlen, die Namen der Entwickelnden in den Commits zu nennen, sofern das Projekt dem nicht entgegensteht.* + +*In jedem Fall sollten die Bundesbehörden als Rechtsinhaberinnen auftreten.* + +=== Urheberrecht, Lizenzen für generative KI zur Codeerstellung + +Hier beziehen wir uns nur auf Code, der mithilfe generativer KI erstellt wurde. Weitere Informationen zu diesem Thema finden sich in link:em002-6.pdf[Em002-6 FAQ zu OSS++*++ in Kapitel 2.2]. Von einem LLM erstellter Code ist selbst nicht urheberrechtlich geschützt. Die vom LLM verwendeten Trainingsdaten können jedoch urheberrechtlich geschützt sein. Entspricht der Code 1:1, so sollte auch die Lizenz übernommen werden. Wurde der Code stückweise erstellt und anschliessend von den Entwickelnden verändert, so ist das Risiko gering, dass er als abgeleitete Software gilt. Zu beachten ist, dass bestimmte LLM eine entsprechende Kennzeichnung des Codes verlangen; allfällige vertragliche Vereinbarungen dazu sind einzuhalten. + +=== Contributor Licence Agreements (CLA) und Developer Certificate of Origin (DCO) + +Arbeiten mehrere Autorinnen und Autoren am Code eines Open-Source-Projekts, so erhalten sie gemeinsame Rechte am entstehenden Code. + +Die Lizenzierung des Codes an Dritte erfolgt über die OSS-Lizenz, wobei zwischen jeder nutzenden Person und jeder Autorin bzw. jedem Autor ein eigener Lizenzvertrag entsteht (Lizenzbündel). Diese Konstellation kann zu einer unübersichtlichen Rechtslage führen, etwa in internationalen Verhältnissen (siehe 8.1 oben). Entscheiden sich Unternehmen, ihre Software unter eine OSS-Lizenz zu stellen und Beiträge Dritter anzunehmen, so haben sie mitunter das Bedürfnis, eine gewisse Kontrolle über den Code zu behalten. + +So kann es etwa interessant sein, die Möglichkeit offenzuhalten, das Projekt unter eine neue Lizenz zu stellen, oder man möchte unter Copyleft lizenzierten Code einer dualen Lizenzierung unterziehen und benötigt dafür mehr Rechte, als man von den Beitragenden über eine einfache OSS-Lizenz erhielte (siehe 8.5 oben). Contributor Licence Agreements (mitunter auch Copyright Transfer Agreements) sollen solche Probleme lösen. + +Ein *Contributor Licence Agreement (CLA)* ist eine *rechtsverbindliche Vereinbarung*, welche die *Bedingungen für Projektbeiträge* festlegt. + +Beitragende sind verpflichtet, dieser Vereinbarung zuzustimmen, bevor Inhalte zum Projekt beigetragen werden können. Im Wesentlichen räumen die Beitragenden dem Projekt und seinen Nutzenden das Recht ein, die geleisteten Beiträge zu *nutzen, zu verändern und weiterzuverbreiten*. Zudem wird bestätigt, dass die Beiträge *eigenständig verfasst oder von Dritten legitimiert wurden*. + +Das *Developer Certificate of Origin (DCO)* ist ein 2004 von der Linux Foundation *eingeführtes Prüfsystem*, das dem Contributor Licence Agreement (CLA) im Zweck ähnlich ist und ein geeignetes alternatives Instrument darstellt. Die Beitragenden bestätigen für jeden Projektbeitrag, dass *(a) sie befugt sind, den Beitrag zu leisten, (b) der Beitrag von einer mit dem Projekt kompatiblen Lizenz erfasst ist und (c) sie der Verbreitung und Nutzung des Beitrags als Open Source zustimmen*. + +Das Hauptinstrument von CLA ist entweder die Abtretung der Urheberrechte von den Beitragenden an die Hauptentwicklerin bzw. den Hauptentwickler oder die tragende Organisation (bei Copyright Transfer Agreements) oder die Einräumung einer möglichst weitgehenden, in der Regel unwiderruflichen Lizenz durch die Beitragenden an die Hauptentwicklung (z. B. hat Apache ein CLA definiert). Auch Beiträge an geschlossene Projekte unterliegen häufig einem CLA. + +CLA sind in der OSS-Community umstrittenfootnote:[Beispielsweise: https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/], unter anderem weil sie Lücken im Copyleft öffnen können. Daher gibt es inzwischen auch CLA, welche die Hauptentwicklung bei der Erteilung einer neuen Lizenz für den Code des Projekts einschränken. + +[mermaid,align="center",alt="Übertragung von Quellcode und Rechten in verschiedenen Konstellationen"] +.... +flowchart LR + subgraph TP["Dritte"] + TP1["keine eigenen Dokumente"] + TP2["CLA
DCO
OSS-Lizenz"] + TP3["CLA
DCO
OSS-Lizenz
Vertrag"] + TP4["keine eigenen Dokumente"] + end + subgraph FA["Bundesverwaltung"] + FA1["AGB des Bundes
Vertrag"] + FA2["keine eigenen Dokumente"] + FA3["OSS-Lizenz
Vertrag
(DCO)
(CLA)"] + FA4["OSS-Lizenz
(DCO)
(CLA)"] + end + TP1 -- "Erstellung" --> FA1 + TP2 -- "Beitrag der Bundesverwaltung" --- FA2 + TP3 <-- "Zusammenarbeit" --> FA3 + TP4 -- "Beitrag Dritter" --> FA4 +.... + +Abbildung 4: Übertragung von Quellcode und Rechten in verschiedenen Konstellationen + +Legende: + +* Die Kästchen zeigen, *wo die Rechte definiert sind*. +* *Erstellung* und *Beitrag Dritter*: Die Bundesverwaltung hat die Gestaltungsmacht. +* *Zusammenarbeit*: Die Dokumente werden zwischen den Parteien vereinbart. +* *Beitrag der Bundesverwaltung*: Die Bundesverwaltung hat keine Gestaltungsmacht, eine Prüfung ist nötig. +* Die Rechtsdokumente sind von oben nach unten nach Priorität geordnet; Dokumente in Klammern sind eher zu vermeiden. + +Für *Eigenentwicklungen* (Creation) bestehen keine Probleme: Nach Art. 17 URG ist die Bundesbehörde Inhaberin der Nutzungsrechte an Software, die von ihren eigenen Mitarbeitenden geschaffen wurde. Bei *Drittentwickelnden* sollten sich die Bundesbehörden die Rechte sichern (beispielsweise durch Verwendung der entsprechenden AGB des Bundes). Damit ist hier kein CLA oder DCO nötig. + +Wo Bundesbehörden Hauptentwicklerinnen sind und Beiträge sowie Zusammenarbeiten annehmen, sollte auf die Verwendung eines CLA verzichtet werden. Stattdessen können Digital Certificates of Origin (mit einem Beispiel erläutert in link:em002-4.pdf[Em002-4 Leitfaden OSS-Community], Kapitel 3.3) verwendet werden. Grundsätzlich sollten Beiträge an Projekte von Bundesbehörden auf der OSS-Lizenz aufbauen, um die Hürde für Beiträge nicht weiter zu erhöhen. + +Wird im Einzelfall nach entsprechender Prüfung dennoch ein Bedarf für ein CLA festgestellt, so sollte die Bundesbehörde das Apache-CLA verwenden.footnote:[https://www.apache.org/licenses/contributor-agreements.html] In diesem Fall sollten dieser Entscheid und das CLA in den Schlussbemerkungen sowohl der link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] als auch der link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] vermerkt werden. + +Tragen Bundesbehörden zu Drittsoftware bei, die ein CLA verlangt, so muss der Rechtsdienst im Einzelfall prüfen, ob die Bundesbehörde das bestehende CLA annehmen kann.footnote:[Für eine bestimmte Empfängerin müsste die Bundesverwaltung die Unterzeichnung eines CLA nur einmal prüfen. In anderen Organisationen wird dies daher als Angelegenheit auf hoher Ebene behandelt, wobei unterzeichnete CLA in der Vertragsablage aufbewahrt werden. CLA dürfen die Pflichten der Bundesbehörde nach Art. 9 EMBAG nicht unterlaufen.] Die folgenden Punkte sind zu bestimmen: + +* Hat eine andere Bundesbehörde das CLA bereits unterzeichnet? +* Wer prüft das CLA? +* Wer unterzeichnet es? (Die unterzeichnende Person muss befugt sein, für den Bund gegenüber Dritten zu unterschreiben) +* Wo wird es abgelegt? +* Wie wird das CLA oder DCO im Projekt dokumentiert? +* Wie wird sichergestellt, dass der freigegebene Code veröffentlicht bleibt? (Dies bleibt nach Art. 9 EMBAG in der Verantwortung der Bundesbehörde, siehe [KBB-MB].) + +Mögliche Kriterien für die Prüfung sind: + +* Vereinbarkeit mit Art. 9 EMBAG: Bleibt der Code offen? +* Sieht die Bundesbehörde Risiken für sich? +* Sieht die Bundesbehörde einen Nutzen für sich (z. B. muss der Code nicht allein gepflegt oder weiterentwickelt werden) oder für andere (innerhalb des Föderalismus der Schweiz oder europaweit lässt sich ohne Mehraufwand eine breitere Wirkung erzielen)? +* Sind die eingeräumten Rechte angemessen? +* Werden der Bundesbehörde keine (unnötigen) Pflichten auferlegt? +* Entspricht das CLA im Wesentlichen dem Apache-CLA? + +=== Probleme mit (L)GPL-3.0 und IoT + +_[BITKOM2023]_ weist auf ein Problem bei der Verwendung von (L)GPL-3.0-Lizenzen im Zusammenhang mit geräteseitiger Software hin: Solche Geräte müssten die Installation eigener bzw. neuer Softwareversionen zulassen. Dies kann aus Sicherheitsgründen unerwünscht sein. + +=== Rechtsstellung der Dokumentation + +Nach Art. 5 URG sind «Entscheidungen, Protokolle und Berichte von Behörden und öffentlichen Verwaltungen» nicht urheberrechtlich geschützt. + +Dies geht weiter als CC-0, weil die Rechtsinhaberin das Werk nicht durch weltweiten Verzicht auf alle Urheber- und verwandten Schutzrechte in die Gemeinfreiheit entlassen muss. Es ist bereits von Gesetzes wegen gemeinfrei. Die Botschaft zu Art. 5 URG hält fest: «Die Bestimmung lässt den urheberrechtlichen Schutz nach wie vor für eine ganze Reihe von Werken zu, die aus amtlicher Tätigkeit oder im Zusammenhang damit entstanden sind. + +Unterlagen verwaltungsinterner Studienkommissionen und Arbeitsgruppen, Gutachten oder Zeitschriften von Bundesämtern etwa fallen nicht unter die Norm. An deren freier Verbreitung besteht kein überwiegendes Interesse, weil sie die Rechtsstellung der Bürgerin und des Bürgers nicht beeinflussen.» + +Damit lässt sich argumentieren, dass für viele der massgebenden Dokumente und die von Bundesbehörden im Zusammenhang mit Open-Source-Software veröffentlichte Dokumentation kein urheberrechtlicher Schutz besteht. Das Kriterium ist, ob das Dokument die Rechtsstellung der Bürgerin und des Bürgers berührt und damit vom urheberrechtlichen Schutz ausgenommen ist. Ist dies nicht der Fall, so sollte für die Dokumentation eine geeignete Lizenz (CC-0footnote:[https://www.creativecommons.ch/], CC-BY, CC-BY-SA oder allenfalls LGPL) verwendet werden. + +Dennoch wäre insbesondere bei internationaler Nutzung der Dokumentation für viele Nutzende die Lage unklar. + +Wir erachten es daher als zweckmässig, wenn wie bei diesem Dokument sicherheitshalber ebenfalls eine entsprechende Freigabe aufgeführt wird. + +== Weitere Informationen zu Rechtsfragen + +Weitere Informationen zu Open-Source-Software, zu spezifischen Lizenzmerkmalen und zu vertieften rechtlichen Aspekten finden sich in zahlreichen Publikationen, die nachfolgend vorgestellt werden (siehe auch die Referenzen am Ende des Dokuments). + +* Der Text _«Open Source Software im EMBAG, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben»_ von Rika Koch und Simon Schlauri, im Tagungsband der IT-Beschaffungskonferenz 2023 in Bern, bietet zusätzliche Orientierung zur Umsetzung von Art. 9 EMBAG. +* Der _Leitfaden Open-Source-Software 2.0_ des deutschen BITKOM behandelt rechtliche Fragen rund um Open Source ausführlich _[BITKOM2023]_. Er beruht jedoch auf der Rechtslage in Deutschland. +* Wolfgang Straub untersucht in seinem Buch _Softwareschutz: Urheberrecht, Patentrecht, Open Source_ die rechtlichen Einzelheiten des Copylefts mit Bezug zum Schweizer Urheberrecht und geht der Kompatibilität von Open-Source-Lizenzen nach [St2011]. Das Kapitel zur Open-Source-Software (sowie deutsche Übersetzungen verschiedener Open-Source-Lizenzen unter Berücksichtigung der Schweizer Rechtsterminologie) sind unter _www.it-recht.ch_ frei verfügbar. +* Till Jaeger und Axel Metzger beantworten in ihrem umfassenden Buch _Open Source Software – Rechtliche Rahmenbedingungen der Freien Software [JaAx2016]_ zahlreiche Rechtsfragen rund um Open-Source-Software vertieft. Sie stützen ihre Analyse jedoch auf die Rechtslage in Deutschland. +* Kropp Jonathan/Bauer Alexander, Open Source Compliance und Litigation, CB 2019 S. 285 ff., 285. +* Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de «logiciels libres» (open source), SZW 2022 S. 69 ff. + +Zudem informieren verschiedene Online-Portale ausführlich über die Merkmale und Fragen einzelner Open-Source-Lizenzen. + +* Auf der GitHub-Plattform https://choosealicense.com lassen sich die gewünschten Ziele für ein Open-Source-Projekt auswählen, worauf die passende Open-Source-Lizenz vorgeschlagen wird. +* Unter https://opensource.guide/legal/ stellt GitHub einen Online-Leitfaden bereit, der auf spezifische Rechtsfragen eingeht. +* Unter https://www.gnu.org/licenses/license-list.de.html finden sich Kurzkommentare zu verschiedenen Lizenzen mit Angaben zur Kompatibilität, insbesondere zur GPL. +* Unter https://opensource.org/faq behandelt die Open Source Initiative zahlreiche Fragen und Antworten zu den rechtlichen Aspekten von Open-Source-Lizenzen. +* Unter https://copyleft.org/guide findet sich ein ausführlicher Leitfaden, der die Einzelheiten des Copylefts erläutert. +* Unter https://tldrlegal.com werden die wichtigsten Open-Source-Lizenzen danach zusammengefasst, was die jeweilige Lizenz erlaubt («can»), was sie verbietet («cannot») und was sie vorschreibt («must»). +* Unter https://opensource.com/tags/licensing werden laufend Artikel zu aktuellen Lizenzfragen veröffentlicht. +* Unter https://www.ifross.org/faq-haeufig-gestellte-fragen hat das private «Institut für Rechtsfragen der Freien und Open Source Software» in Berlin (ifrOSS) zahlreiche Antworten auf häufig gestellte Rechtsfragen veröffentlicht. + +Die Einhaltung von Open-Source-Lizenzen wird heute in erster Linie mit Softwarewerkzeugen umgesetzt (zu weiteren Informationen zur Open-Source-Compliance siehe auch Fröhlich-Bleuler _[Fr2012]_ sowie Kuhn, Williamson und Sandler _[KuWiSa2008]_). So sind etwa verschiedene Open-Source-Werkzeuge der Linux Foundation unter dem Begriff «fossology» unter https://www.fossology.org dokumentiert und veröffentlicht. Auch kommerzielle Anbieter wie Black Duckfootnote:[https://www.blackducksoftware.com] oder FOSSAfootnote:[https://fossa.com] bieten verschiedene proprietäre Lösungen an, mit denen die Kompatibilität der verwendeten Open-Source-Lizenzen geprüft werden kann. + +== Anhang + +=== Änderungen gegenüber der Vorversion + +* Management Summary ergänzt. +* AGPL- und MIT-Lizenz werden neu als vorzugswürdig empfohlen. +* Neu in Kapitel 8.8: Urheberrecht für mit KI erzeugten Code. +* Kapitel 8.9 CLA und CDO stark erweitert. +* Verschiedene redaktionelle Verbesserungen und Präzisierungen. +* Mehr Beispiele aufgeführt. + +=== Referenzen + +Siehe link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung]. + +=== Abkürzungen + +Siehe link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] und link:em002-6.pdf[Em002-6 FAQ zu OSS]. + +=== Beispiele von Freigaben und ihrer Lizenz + +Künftig wird diese Liste durch eine Sammlung von Metadaten über publiccode.yml ersetzt. + +=== D.1 Loom + +URL:: +https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom +Bundesbehörde:: +Cyber Command +Beschreibung:: +Loom ist eine leistungsfähige, einfach zu bedienende Dokumentensuchmaschine. Sie automatisiert die Indexierung konfigurierter Datenquellen, führt OCR durch, extrahiert Inhalte und Metadaten, ermöglicht Tagging und bietet leistungsfähige Such- und Bedienmöglichkeiten. +Jahr:: +2025 +Lizenz:: +MIT +Begründung:: +- + +=== D.2 trustbroker.swiss + +URL:: +https://github.com/trustbroker-swiss/trustbroker.swiss +Bundesbehörde:: +BK, BIT +Beschreibung:: +Trust Broker Swiss stellt Föderationsdienste zwischen Relying Parties (Anwendungen, Service Provider, andere IAM-Systeme oder Policy Enforcement Points) und Identity Providern (IdP, auch Claims Provider genannt) bereit und nutzt vertrauenswürdige Attributspeicher, um authentifizierte Nutzende anzureichern. + +Es ermöglicht Identity-/Claims-Providern und Relying Parties, Informationen über eine dritte Partei auszutauschen, welche die IdP-Spezifika verbirgt und eine einheitliche oder zumindest zusätzlich verifizierte Identität bereitstellt. +Jahr:: +2024 +Lizenz:: +AGPL +Begründung:: +Codeänderungen sollen stets offen bleiben und zurückfliessen. ++ +Für den Trust Broker wurde eine sehr detaillierte Prüfung der Lizenzfrage durchgeführt. Bei sehr grossen Projekten kann sie in dieser Detailtiefe erfolgen. Alle kompatiblen Lizenzen, die mit der Software Bill of Materials vereinbar sind, wurden in einem Lizenzpool aufgeführt. + +=== D.3 Geocat.ch + +URL:: +https://github.com/geonetwork/core-geonetwork +Bundesbehörde:: +Swisstopo +Beschreibung:: +GeoNetwork ist eine Kataloganwendung zur Verwaltung raumbezogener Ressourcen. Sie bietet leistungsfähige Funktionen zur Metadatenbearbeitung und -suche sowie einen interaktiven Webkartenbetrachter. Sie wird derzeit in zahlreichen Initiativen für Geodateninfrastrukturen weltweit eingesetzt. +Jahr:: +2012 +Lizenz:: +GPL 2.0 +Begründung:: +- + +=== D.4 GWEN / ampycloud / c4dl-multi / dvas /… + +URL:: +https://meteoswiss.github.io/ampycloud/ +Bundesbehörde:: +MeteoSchweiz +Beschreibung:: +Python-Paket zur Bestimmung des Bedeckungsgrads und der Basishöhe von Wolkenschichten anhand von Ceilometer-Daten. +Jahr:: +2023 +Lizenz:: +Verschiedene Lizenzen, FSS +Begründung:: +- + +=== D.5 Anwendung EMSG (Erhaltungsmanagement in Siedlungsgebieten) + +URL:: +https://github.com/astra-emsg/ASTRA.EMSG +Bundesbehörde:: +MeteoSchweiz +Beschreibung:: +EMSG ist eine C#-GIS-Webanwendung, die von der Schweizer Bundesverwaltung entwickelt wurde, um das Erhaltungsmanagement städtischer Strassensysteme zu verwalten. +Jahr:: +2017 +Lizenz:: +BSD +Begründung:: +- + +=== D.6 Anwendung Covid-Zertifikat + +URL:: +https://github.com/admin-ch/CovidCertificate-Documents +Bundesbehörde:: +BIT +Beschreibung:: +Schweizer Anwendung für COVID-Zertifikate +Jahr:: +2020 +Lizenz:: +MIT +Begründung:: +So permissiv wie möglich, damit alle den Code nutzen können. + +=== D.7 GovCert-Website + +URL:: +https://github.com/govcert-ch/website +Bundesbehörde:: +NCSC +Beschreibung:: +Quellcode der Website für das Computer Emergency Response Team (GovCERT) der Schweizer Bundesverwaltung +Jahr:: +2023 +Lizenz:: +MIT +Begründung:: +- + +=== D.8 Verschiedene Bibliotheken zu Open Data (z. B. Linked Data) + +URL:: +https://github.com/SwissFederalArchives +Bundesbehörde:: +BAR +Beschreibung:: +Das Repository des Schweizerischen Bundesarchivs auf GitHub bietet Zugang zu den Quellcodes unserer Anwendungen. Es erlaubt Ihnen, eigene Forks zu erstellen und über die Schnittstelle «Issues» Fehler zu melden oder erweiterte Funktionalitäten vorzuschlagen. +Jahr:: +2023 +Lizenz:: +AGPL, Apache, MIT +Begründung:: +Opendata und Open-Source-Software gehen in dieselbe Richtung. Die AGPL erlaubt maximale Offenheit. + +=== D.9 Apache FOP angepasst für archivierbares PDF + +URL:: +https://xmlgraphics.apache.org/fop/ +Bundesbehörde:: +IGE +Beschreibung:: +Das IGE wollte eine Version von Apache FOP, die archivierbare PDF erzeugen kann. Dazu wurde bei einem der Kernentwickler (Jeremias Märki) eine Erweiterung in Auftrag gegeben. Die Anpassungen flossen direkt in das Projekt ein. +Jahr:: +2007 +Lizenz:: +Apache +Begründung:: +Erweiterungen wurden an einem bestehenden Open-Source-Projekt vorgenommen. + +=== D.10 Rechtskonforme elektronische Eingabe mit eKomm + +URL:: +https://launchpad.net/ekomm +Bundesbehörde:: +IGE +Beschreibung:: +Das IGE wollte Software für die elektronische Eingabe. +Jahr:: +2009 +Lizenz:: +Apache +Begründung:: +Das IGE wollte, dass der Anbieter (Glue) die Freigabe vornimmt, und hat diese als permissiv bewilligt (Integration in eigene Anwendungen). +endif::[] + +ifeval::["{lang}" == "fr"] +*Clause de non-responsabilité :* 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 {url-repo}/tree/main[README] principal. + +''''' + +== Résumé à l'intention de la direction + +Il est recommandé de définir stratégiquement au sein de l'administration fédérale, lors du lancement d'un nouveau projet, l'une des deux licences suivantes : + +* *Licence AGPL* : effet copyleft souhaité. Le code modifié doit dans tous les cas revenir à la collectivité et peut ensuite être repris par l'administration fédérale. Il est recommandé d'utiliser la version la plus récente de la licence. C'est ainsi que le principe « public money – public code » est le mieux respecté. Les droits de tiers, en particulier en cas de développements ultérieurs, peuvent affaiblir cela jusqu'à la LGPL. +* *Licence MIT* : des tiers doivent pouvoir développer des applications propriétaires sur la base du code de l'administration fédérale. Si une clause de non-endossement est expressément exigée, la BSD-3-Clause est à privilégier. + +L'aide à la décision suivante peut être utilisée pour choisir la licence : + +[mermaid,align="center",alt="Aide à la décision simplifiée pour le choix de la licence"] +.... +flowchart TD + S(["Début"]) + Q1{"L'« environnement »
impose la licence"} + A["Choisir la licence
imposée"] + Q2{"Bibliothèque, implémentation de référence
ou exigences libérales"} + B["MIT"] + C["AGPL"] + S --> Q1 + Q1 -->|"Oui"| A + Q1 -->|"Non"| Q2 + Q2 -->|"Oui"| B + Q2 -->|"Non"| C +.... + +Figure 1 : Aide à la décision simplifiée pour le choix de la licence + +Dans une certaine mesure, ces deux licences constituent les deux extrêmes du spectre des licences OSS. Il peut être tout à fait judicieux de choisir une licence mieux adaptée à un projet concret. Le présent guide entend apporter une aide concrète à cet égard. + +Si l'analyse des bibliothèques logicielles révèle qu'une autre licence doit être utilisée, les développeurs attirent l'attention de la direction de projet sur ce point. L'analyse est exposée dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +Lors de la participation à des projets existants, toutes les licences compatibles OSI sont en principe acceptables. + +== Introduction + +L'article 9 de la loi fédérale du 17 mars 2023footnote:[RS 172.019] sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA) prévoit que les autorités fédérales doivent publier et placer sous licence open source les logiciels qu'elles développent ou font développer. + +Le présent document poursuit les objectifs suivants : + +* Introduction aux thèmes du droit d'auteur sur les logiciels et des licences OSS. +* Une présentation des licences OSS dont l'utilisation ne pose pas de problème au sein de l'administration fédérale. Les licences non mentionnées dans le présent document et les logiciels placés sous de telles licences ne peuvent pas être utilisés sans un examen supplémentaire des dispositions contractuelles par le service juridique compétent. +* Une aide au choix d'une licence pour le développement ou l'acquisition d'un projet au sens de l'art. 9 LMETA. + +== Droit d'auteur et licences : principes + +Le droit d'auteur fonde tant des droits moraux que des droits patrimoniaux (droits d'exploitation). Les droits moraux comprennent par exemple le droit à la reconnaissance de la qualité d'auteur ou le droit de décider si et quand l'œuvre est divulguée. Les droits d'exploitation comprennent par exemple le droit de confectionner ou de diffuser des exemplaires de l'œuvre. + +La loi fédérale du 9 octobre 1992footnote:[RS 231.1] sur le droit d'auteur et les droits voisins (LDA) prévoit une série d'autres droits moraux et d'exploitation (voir art. 8 ss LDA). Ces droits reviennent directement à l'auteur au moment même de la création de l'œuvre. + +L'art. 2 LDA fixe les conditions auxquelles la protection du droit d'auteur est accordée. Une œuvre protégée au sens de la loi n'existe que si ces conditions sont remplies. + +Les conditions sont les suivantes : + +* L'œuvre doit avoir été créée ; sa simple découverte ne suffit pas. Les données de recherche, par exemple, c'est-à-dire les résultats d'expériences, ne peuvent pas être qualifiées d'œuvres. +* La création doit être « intellectuelle », c'est-à-dire émaner d'un être humain. +* L'œuvre doit avoir été réalisée de manière perceptible. La simple idée sous-jacente à une œuvre n'est pas protégée, seule l'est sa forme extérieure, p. ex. l'impression d'un texte sur papier ou l'exécution d'un morceau de musique. +* Individualité : enfin, l'œuvre doit présenter un certain degré minimal d'individualité. Une œuvre que tout le monde concevrait de la même manière n'est pas protégée. + +Les œuvres les plus diverses peuvent être protégées, telles que des textes littéraires ou scientifiques, des œuvres musicales, photographiques, cinématographiques et d'autres œuvres visuelles ou audiovisuelles. + +Selon l'art. 2, al. 3, LDA, les programmes d'ordinateur sont également des œuvres si les conditions précitées sont remplies. + +Les droits d'auteur reviennent, dès leur naissance, au seul auteur. Lui seul peut interdire à autrui d'accomplir les actes correspondants. L'auteur peut toutefois exercer ses droits autrement que par lui-même : + +* Il peut transférer ses droits à des tiers (p. ex. en les vendant). Le nouveau titulaire des droits peut alors les faire valoir de la même manière que s'il était l'auteur. +* L'auteur peut également accorder une licence sur ses droits à des tiers. En termes simples, une licence est un contrat par lequel le titulaire des droits permet à un tiers d'utiliser l'œuvre. L'auteur conserve les droits, mais renonce à les faire valoir à l'égard du preneur de licence. + +Lorsqu'un programme d'ordinateur est créé dans le cadre d'un rapport de travail, l'employeur obtient une licence exclusive pour son utilisation (art. 17 LDA). Il ne reste donc pour l'essentiel aux employés que les droits moraux sur le logiciel (ou, selon l'opinion juridique, seulement leur noyau dur). Il s'agit de la même situation juridique que sous la loi sur le personnel de la Confédération. + +== Licences OSS + +=== Principes + +Les OSS se caractérisent pour l'essentiel par les éléments suivants (d'après une définition de l'Open Source Initiative _[Pe1999]_footnote:[https://opensource.org/]) : + +* la redistribution illimitée et gratuite du logiciel est autorisée ; +* le logiciel est disponible sous forme de code source ; +* les modifications du logiciel et leur redistribution sous la même licence sont en principe autorisées ; +* aucune personne ni aucun groupe de personnes ne peut être exclu de l'utilisation du logiciel, et aucun domaine d'application ne peut être exclu (en particulier pas l'utilisation commerciale) ; et +* la diffusion du logiciel avec d'autres logiciels (tels que des logiciels closed source) ne doit pas être restreinte. + +Les motifs les plus fréquents du recours aux OSS sont d'abord les économies réalisées grâce à l'utilisation du réservoir déjà considérable de logiciels librement utilisables. Les entreprises qui recourent fréquemment aux OSS parviennent souvent à économiser une part importante de leur budget informatique. + +Le code librement disponible peut en outre être facilement adapté à ses propres besoins. De plus, le choix de l'OSS évite le vendor lock-in.footnote:[https://fr.wikipedia.org/wiki/Enfermement_propriétaire] + +=== Licences open source + +Les licences open source sont avant tout des contrats de licence ordinaires pour des programmes d'ordinateur. + +Contrairement aux contrats de licence ordinaires, les contrats de licence OSS se forment toutefois sans autre dès qu'une seule des formes libres d'utilisation décrites dans la licence est exercée (par exemple par la copie, la redistribution ou la modification du logiciel). + +=== Copyleft versus permissif + +==== Généralités + +Une licence open source au sens de l'OSI peut contenir une clause de « copyleft ». Les modifications apportées à un logiciel placé sous une telle licence doivent être proposées à nouveau aux mêmes conditions que celles applicables au logiciel d'origine. Quiconque apporte de telles modifications doit, lors de la diffusion du logiciel open source sous forme de code objet lisible par machine, proposer également le code source aux destinataires. + +Formulé selon la Free Software Foundation, l'effet copyleft protège la liberté des développeurs et garantit ainsi qu'un logiciel une fois libre reste toujours libre. + +Avec les licences copyleft, une sorte d'échange s'opère entre la communauté et les entreprises utilisatrices. Les utilisateurs, tenus en contrepartie des avantages tirés du réservoir logiciel existant de replacer leurs propres développements sous la licence concernée, contribuent ainsi au développement de ce réservoir. Au final, les deux parties y gagnent. + +La clause de copyleft a un certain « effet de contagion » : si un logiciel sous licence copyleft est intégré à un logiciel jusqu'alors propriétaire, le logiciel initialement propriétaire doit être divulgué sous une licence open source compatible. + +Lors de l'utilisation de code source sous licence copyleft, il convient dès lors de veiller à ne l'intégrer que là où le logiciel qui en résulte peut et doit être publié sous une licence open source. + +Si une licence open source ne contient pas de clause de copyleft (licence open source permissive), la licence des versions révisées du code peut être choisie librement. Il est en particulier également possible de replacer des modifications sous une licence logicielle propriétaire et d'intégrer le code source correspondant dans un logiciel propriétaire. + +Pour l'essentiel, les licences open source peuvent être réparties dans *les catégories suivantes* : + +. licences open source à *copyleft fort* ; +. licences open source à *copyleft faible* ; et +. licences open source *permissives* ou *sans copyleft*. + +==== Licences open source à copyleft fort + +Lors de l'utilisation d'une licence open source à copyleft fort, les nouvelles versions dérivées du logiciel d'origine doivent, si elles sont transmises à des tiers, être placées sous les conditions de la licence d'origine et mises à la disposition de ces tiers sous forme de code source. + +Les deux licences suivantes sont considérées sur le marché comme les licences open source déterminantes à copyleft fort : + +* GNU General Public Licence (GPL) ; une grande partie des OSS est aujourd'hui placée sous cette licence +* GNU Affero General Public Licence (AGPL) + +La principale différence entre la GPL et l'AGPL porte sur le type d'utilisation déclenchant le copyleft. Avec un logiciel sous GPL, le code source modifié ne doit être proposé que si la nouvelle version du logiciel est offerte à des tiers sous forme de programme exécutable (p. ex. sous forme d'application mobile). Si le logiciel est uniquement mis à disposition via Internet (depuis son propre cloud, sur ses propres serveurs), par exemple sous forme de « Software as a Service » (SaaS) ou d'interface de programmation (API), cela ne déclenche pas le copyleft. + +Si le logiciel est placé sous AGPL, le code source modifié doit également être fourni lorsque les fonctionnalités du logiciel sont proposées via un site web ou une interface de programmation. L'AGPL est ainsi encore plus stricte que la GPL. + +Avec les licences à copyleft fort, le copyleft ne concerne pas seulement le module logiciel (bibliothèque) en question, mais l'ensemble du programme dans lequel un module sous licence copyleft peut être intégré. L'« effet de contagion » évoqué prend ainsi effet. + +==== Licences open source à copyleft faible + +Les licences à copyleft faible exigent également que les modifications de leur code source soient publiées aux tiers destinataires sous la licence open source d'origine. + +Contrairement aux licences à copyleft fort, elles n'ont toutefois pas pour effet d'« infecter » d'autres composants logiciels distinguables (d'autres bibliothèques ou le programme principal lui-même) avec leur licence. Cela permet l'intégration de logiciels open source à copyleft faible dans des logiciels propriétaires ou dans des logiciels sous d'autres licences OSS, sans devoir les publier sous la licence d'origine. + +Voici les licences open source à copyleft faible les plus fréquemment utilisées : + +* GNU Lesser General Public Licence (LGPL) +* Mozilla Public Licence 2.0 (MPL) +* Common Development and Distribution Licence (CDDL) +* Eclipse Public Licence (EPL)footnote:[Outre l'Eclipse Public Licence (EPL-1.0), il existe aussi l'Eclipse Distribution Licence (EDL-1.0). + +Alors que l'EDL correspond à la BSD 3-Clause, l'EPL est une licence à copyleft faible.] +* Microsoft Reciprocal Licence (Ms-RL) +* European Union Public Licence (EUPL)footnote:[L'EUPL elle-même comporte un copyleft fort, mais en raison de la clause d'ouverture, un passage à des licences à copyleft faible est possible, de sorte que la protection est limitée.] + +==== Licences open source permissives + +Les licences sans effet copyleft se caractérisent par le fait qu'elles n'imposent aucune exigence au preneur de licence quant à la licence de son logiciel dérivé, de sorte que ni son nouveau code source ni les modifications du logiciel open source ne doivent être divulgués aux tiers destinataires. Cela permet le développement de produits logiciels propriétaires par l'intégration de logiciels sous licences open source permissives. + +Exemples de licences permissives : + +* MIT Licence +* Apache Licence 2.0 +* Berkeley Software Distribution (BSD) Licence (BSD 2-Clause et BSD 3-Clause) +* Microsoft Public Licence (Ms-PL) + +=== Compatibilité des licences open source + +Les programmes se composent généralement d'une multitude de composants et de modules logiciels pouvant être reliés entre eux de différentes manières. Dans le développement logiciel, des composants open source existants sont souvent intégrés dans des applications et solutions internes propriétaires. Dès que celles-ci deviennent accessibles de l'extérieur via un site web, des API, une distribution logicielle ou d'une autre manière, il convient de veiller à la compatibilité des licences open source concernées, car le copyleft peut alors prendre effet. + +Si des œuvres dérivées placées sous une licence déterminée ne peuvent être diffusées que sous les mêmes conditions de licence, il en résulte que d'autres licences open source assorties d'obligations différentes ou contradictoires pour les œuvres dérivées ne peuvent pas être utilisées. + +Certaines licences open source contiennent des clauses dites d'ouverture, qui permettent l'utilisation du code placé sous ces licences dans des projets soumis à d'autres licences. Ainsi, la LGPL version 2.1 permet aussi l'utilisation du code sous GPL. La GPLv3 contient notamment une clause de compatibilité pour l'AGPL et l'Apache License 2.0. L'EUPL est conçue de manière très ouverte et contient en annexe une longue liste de licences compatibles, en particulier celles à copyleft faible telles que la LGPL. Il en résulte que la protection copyleft forte effectivement prévue dans la licence est indirectement affaiblie. + +Le schéma suivant représente les dépendances des principales licences open source (Goldstein 2018). La représentation se fonde sur la visualisation de David A. Wheeler, qui a analysé les compatibilités des différentes licences et de leurs numéros de version (Wheeler 2007) et a été développée avec des informations tirées de https://www.gnu.org/licenses/license-list.fr.html[https://www.gnu.org/licenses/license-list.fr.html].footnote:[Une autre représentation, étendue, est utilisée par GEANT dans son 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. On y trouve quelques licences supplémentaires.] + +Le schéma doit être lu comme suit : du code sous une licence figurant plus tôt dans la chaîne peut être intégré dans un logiciel publié sous une licence figurant plus tard dans la chaîne. Ainsi, du code sous BSD modifiée peut être placé sous une variante de licence LGPL ou GPL, mais non l'inverse. Public domain signifie que l'œuvre n'est soumise à aucune restriction de droit d'auteur. + +[mermaid,align="center",alt="Compatibilité des licences open source"] +.... +flowchart TB + subgraph P["Licence permissive"] + PD["Public domain"] + MIT["MIT/X11"] + BSD["BSD modifiée"] + AP["Apache 2.0"] + end + subgraph W["Copyleft faible"] + EUPL["EUPL"] + LGPL21["LGPLv2.1"] + LGPL21P["LGPLv2.1+"] + LGPL3["LGPLv3 / LGPLv3.1"] + MPL["MPL 1.1"] + end + subgraph SC["Copyleft fort"] + GPL2["GPLv2"] + GPL2P["GPLv2+"] + GPL3["GPLv3 / GPLv3+"] + AGPL["Affero GPLv3"] + end + PD --> MIT + MIT --> BSD + BSD --> AP + BSD --> LGPL21 + BSD --> LGPL21P + BSD --> LGPL3 + BSD --> MPL + AP --> EUPL + AP --> LGPL3 + EUPL --> LGPL21 + EUPL --> LGPL21P + EUPL --> LGPL3 + EUPL --> MPL + LGPL21P --> LGPL21 + LGPL21P --> LGPL3 + LGPL21 --> GPL2 + LGPL21 --> GPL2P + LGPL21P --> GPL2P + LGPL3 --> GPL3 + GPL2P --> GPL2 + GPL2P --> GPL3 + GPL3 -->|"+ protection du réseau"| AGPL + classDef pd fill:#f5f5f5,stroke:#000000,color:#000000 + classDef perm fill:#dae8fc,stroke:#000000,color:#000000 + classDef weak fill:#d5e8d4,stroke:#000000,color:#000000 + classDef strong fill:#5ea226,stroke:#000000,color:#ffffff + class PD pd + class MIT,BSD,AP perm + class EUPL,LGPL21,LGPL21P,LGPL3,MPL weak + class GPL2,GPL2P,GPL3,AGPL strong +.... + +Figure 2 : Compatibilité des licences open source (d'après le schéma de David A. Wheeler, 2007 et https://www.gnu.org/licenses/license-list.fr.html) + +Important : les compatibilités de licences étant toujours pertinentes, les équipes de développement et les prestataires devraient vérifier au préalable les piles de développement et leurs bibliothèques quant aux éventuels problèmes de compatibilité. Autrement dit, avant de valider l'utilisation d'une bibliothèque, il convient de vérifier, outre la sécurité et l'homogénéité de la pile de développement, si la licence de la bibliothèque est compatible avec les licences déterminantes privilégiées par l'administration fédérale. + +[[licences-for-pure-usage]] +== Licences pour la simple utilisation + +Ce chapitre traite de la situation dans laquelle un logiciel sous licence OSS doit être utilisé, mais ne doit pas être modifié, ou dans laquelle les modifications ne sont utilisées qu'en interne. + +Les licences suivantes ne posent en principe pas de problème lorsqu'un logiciel est utilisé par des autorités fédérales. Les conditions correspondantes, notamment un éventuel copyleft, doivent toutefois être respectées. + +Dans certaines circonstances, la licence d'un module logiciel préexistant détermine les licences possibles pour l'ensemble du produit (voir chapitre 4.4). + +Certaines licences sont incompatibles entre elles (voir figure 2). + +[cols="1,1,3",options="header"] +|=== +|Licence |Copyleft |Particularités + +|*MIT* +|Non +|Licence privilégiée de l'administration fédérale lorsqu'une large diffusion est recherchée et que des tiers doivent pouvoir en développer à nouveau des logiciels propriétaires. + +|*Apache 2.0* +|Non +|Apache est une licence très répandue, connue pour les projets placés sous l'égide de l'Apache Foundation. L'utilisation des marques des donneurs de licence est exclue, sauf pour décrire l'œuvre. + +|*GPL v3* +|Oui +a|Il s'agit de LA licence copyleft classique. + +Le copyleft s'applique aussi lorsque des parties sous GPL sont intégrées dans un programme entier. Interdiction de la gestion des droits numériques. Règles de compatibilité particulières. + +|*LGPLv3* +|Faible +a|Licence copyleft réduite, développée spécialement pour les bibliothèques logicielles. + +Contrairement à la GPL, la LGPL permet, à certaines conditions, de combiner du code fermé (c'est-à-dire propriétaire) avec du code LGPL. + +Les bibliothèques standard telles que glibc en sont des exemples. La LGPL permet de placer sous GPL le programme dont la bibliothèque est diffusée comme partie intégrante. + +|*Affero GPLv3 (AGPL)* +|Oui +a|L'utilisation en SaaS déclenche également le copyleft. Pour le reste, analogue à la GPLv3. + +Cette licence comble la lacune de la GPL, qui faisait qu'aucune publication n'était requise en cas d'utilisation pour des offres SaaS. + +Avec cette licence, l'administration fédérale peut garantir que les améliorations du code profitent aussi à la collectivité en cas de SaaS, et elle soutient au mieux le principe *« public money – public code »*. + +|*BSD-3* +|Non +a|Licence générale et libérale. + +Les noms des auteurs ne peuvent pas être utilisés pour promouvoir des œuvres dérivées (clause de publicité) + +|*European Union Public Licence (EUPL)* +|Faible +a|Licence particulière utilisée pour l'UE. + +Particulièrement utile comme base pour des projets européens. + +Licence tenant compte du droit européen. La publication sous certaines licences compatibles est expressément autorisée. +|=== + +Tableau 1 : Licences ne posant pas de problème pour les autorités fédérales (selon _[Sc2024]_) + +D'autres licences peuvent être utilisées. Dans ces cas, il peut être nécessaire de consulter le service juridique de l'office concerné. + +== Licence pour ses propres projets ou la creation et pour les contributions + +Ce chapitre concerne les cas suivants : + +* Développement ultérieur / contribution +** lorsque des autorités fédérales développent un logiciel existant ; ou +** développent un nouveau logiciel, mais s'appuient sur des bibliothèques logicielles OSS existantes ; et +** mettent le logiciel correspondant à la disposition de tiers. Les tiers comprennent également les organisations de l'administration fédérale décentralisée, pour autant qu'elles aient leur propre personnalité juridique. Si les développements ultérieurs ne sont utilisés qu'en interne et ne sont pas mis à la disposition de tiers, seul le chapitre <> s'applique. +* Projets propres / creation / publication : ce chapitre concerne les cas dans lesquels les autorités fédérales développent un nouveau logiciel. Cela devrait être rare, la plupart des développements s'appuyant sur des bibliothèques logicielles open source existantes. ++ +Pour les développements entièrement nouveaux, il convient de choisir un type de licence permettant une base large et durable pour les développements ultérieurs. Il importe à cet égard que la licence concernée soit largement acceptée dans la communauté de développeurs déterminante. + +L'examen de compatibilité est effectué selon link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS], chapitre 7.4. La compatibilité des licences est présentée à la figure 2. + +Les dimensions suivantes devraient être prises en compte : + +* Cas d'application +* Examen souhaité link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Liste de contrôle Évaluation préalable OSS] +* Facilité de constitution d'une communauté link:em002-4.pdf[Em002-4 Guide des communautés OSS] +* Facilité d'application +* Sécurité juridique +* Diffusion + +Les licences selon le chapitre <> sont à privilégier. + +Les *licences copyleft* suivantes devraient être utilisées en priorité par les autorités fédérales, en particulier si un développement ouvert et durable est recherché et si l'effet copyleft d'héritage doit s'appliquer. Cela garantit que les logiciels payés par la collectivité et tous leurs dérivés restent ouverts. C'est ainsi que le principe « *public money – public code* » est le mieux respecté, et il s'agit de *la recommandation privilégiée pour l'administration fédérale.* + +Licences recommandées par ordre décroissant : + +* *AGPL v3* +* GPL v3 +* LGPL 3.0 +* European Union Public Licence (EUPL) + +Les licences suivantes devraient être utilisées par les autorités fédérales lorsque *aucun copyleft n'est souhaité* ou requis (par ordre décroissant) : + +* *MIT* +* Apache Licence 2.0 +* BSD v3 + +Lors de la participation à des projets existants, les licences suivantes peuvent en outre être utilisées sans problème : + +* Mozilla Public Licence +* Microsoft Public Licence + +Si une autre licence doit être utilisée, il est recommandé de le justifier brièvement dans la link:em002-2-3-checklist-oss-release-and-publication.pdf[liste de contrôle Em002-2.3 Validation et publication OSS]. + +*Selon l'art. 9, al. 4, LMETA, des licences établies à l'échelle internationale devraient être utilisées dans tous les cas.* + +Autres outils de vérification des compatibilités de licences : + +* ORT Toolkit (https://oss-review-toolkit.org/) +* Black Duck (www.blackducksoftware.com), +* FOSSA (http://www.fossa.com[www.fossa.com]), +* l'Open Source Licence Comparison Grid (https://www.cmu.edu/cttec/forms/opensourcelicensegridv1.pdf) +* FOSSology (https://www.fossology.org). +* Processus OpenCode : https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen[https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses] + +== Cas d'application et licences appropriées + +Le tableau et le schéma suivants montrent comment des licences appropriées peuvent être choisies pour un logiciel open source en fonction de différents cas d'application. + +[cols="2,2,3",options="header"] +|=== +|*Cas d'application* |*Licence(s)* |*Justification* + +|Utiliser un projet existant et y contribuer +|*Licence selon les prescriptions du projet* +|Nécessaire pour des raisons juridiques. + +|La licence est imposée par l'utilisation de parties existantes (licences avec copyleft) +|*Utiliser une licence compatible avec ces parties.* +a|Nécessaire pour des raisons juridiques. + +Remarque : un certain nombre de bibliothèques sont disponibles sous plusieurs licences. + +Une seule des licences doit correspondre. L'un des buts de la licence multiple est de garantir que les bibliothèques puissent être utilisées tant avec que sans copyleft. + +|Écosystème existant avec licence privilégiée (p. ex. il s'agit d'un plug-in pour un logiciel publié sous licence MIT. L'utilisation d'une licence MIT serait alors la plus judicieuse, car tous les autres utilisateurs s'y attendent et le logiciel s'intègre dans l'écosystème) +|*Utiliser la licence si elle figure sur la liste, sinon utiliser autant que possible la même licence* +|L'acceptation dans la communauté est centrale. + +|L'objectif est la diffusion la plus large possible, p. ex. pour une implémentation de référencefootnote:[Par exemple, afin de faciliter la mise en œuvre d'une loi, une implémentation de référence peut être commandée par les autorités fédérales. Voir p. ex. https://ech.ch/de/ech/ech-0238/1.0] (p. ex. pour un logiciel destiné à être utilisé aussi dans des solutions commerciales). +a|*MIT* + +BSD v3 + +Apache Licence 2.0 + +LGPL v3 +|Dans ce cas, aucun copyleft ne devrait être utilisé. + +|Les modifications du code doivent revenir aux autorités fédérales +a|*AGPL v.3* + +GNU GPL v.3 + +EUPL +|L'AGPL impose aussi la publication par des tiers en cas d'utilisation dans le cloud, ce que ne font ni la GPL ni l'EUPL. + +|Les solutions SaaS ne doivent pas être exemptées du retour des modifications de code +|*AGPL v.3* +|L'AGPL impose aussi la publication par des tiers en cas d'utilisation dans le cloud. + +|Une collaboration aisée avec la communauté est importante. +a|*AGPL v.3* + +GNU GPL v3 + +Apache Licence 2.0 +a|La GPL est privilégiée pour maintenir le logiciel libre. + +Apache contient des règles de gouvernance communautaire, des règles supplémentaires pour les contributions (on ne peut pas indiquer une licence autre qu'Apache ; la contribution en tant que telle n'est pas réglée plus en détail, de sorte qu'un CLA existant prime), une licence de brevet et des règles de licence de brevet. En particulier, quiconque fait valoir des brevets contre un autre contributeur perd sa licence de brevet au titre de la licence Apache. + +Les règles fixées par l'Apache Foundation pour les contributions sont déterminantes. Apache est donc judicieux si la gouvernance du projet doit être construite principalement selon Apache. + +|Petit composant (bibliothèque) utilisable universellement ou petit logiciel pour lequel la durabilité ou la maintenance par une communauté n'est pas importante +a|*MIT* + +Apache Licence 2.0 + +BSD v3 + +LGPL v3 +a|La LGPL ne prévoit un copyleft que pour le composant lui-même, mais pas pour l'ensemble du projet dans lequel il est inséré. + +Les autres licences sont permissives. + +|Cela doit être simple et permissif ; le contrôle n'est pas important +a|*MIT* + +Apache Licence 2.0 + +BSD v3 +|Le plus permissif possible + +|Il importe aux autorités fédérales de savoir ce qu'il advient du code et elles souhaitent recevoir le plus d'améliorations possible. +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Il faut empêcher que le logiciel devienne propriétaire et soit positionné sur le marché comme produit concurrent +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Il faut empêcher que les autorités fédérales deviennent dépendantes de fournisseurs isolés (« vendor lock-in ») +a|*AGPL v.3* + +GNU GPLv3 +|Le copyleft empêche qu'un fournisseur acquière avec le temps une position exclusive en utilisant le logiciel de la Confédération dans un produit propriétaire, ce qui pourrait à nouveau créer pour la Confédération une dépendance envers ce fournisseur. +|=== + +Tableau 2 : Licence à utiliser selon le cas d'application pour la publication d'un nouveau logiciel conformément à l'art. 9 LMETA *(gras = recommandé lorsque rien ne s'y oppose)* + +[mermaid,align="center",alt="Arbre de décision étendu pour le choix de la licence dans l'administration fédérale"] +.... +flowchart TD + S(["Début"]) + Q1{"La nomenclature
impose-t-elle la licence ?"} + R1["Choisir la licence
imposée / préférée"] + Q2{"Existe-t-il des licences préférées
dans cet environnement ?"} + Q3{"Figure-t-elle dans la liste des
licences appropriées de l'Em002-3 ?"} + R2["Choisir dans la liste la licence appropriée
suivante selon l'Em002-3, après consultation
du service juridique"] + Q4{"Implémentation de référence
comme proposition
pour des tiers ?"} + R3["GPL ou licence permissive :
MIT, BSD, Apache"] + Q5{"Les améliorations
doivent-elles refluer ?"} + Q6{"Également en cas
d'utilisation SaaS ?"} + R4["GPL, EUPL"] + R5["AGPL"] + S --> Q1 + Q1 -->|"Oui"| R1 + Q1 -->|"Non"| Q2 + Q2 -->|"Oui"| Q3 + Q2 -->|"Non"| Q4 + Q3 -->|"Oui"| R1 + Q3 -->|"Non"| R2 + Q4 -->|"Oui"| R3 + Q4 -->|"Non"| Q5 + Q5 -->|"Non"| R3 + Q5 -->|"Oui"| Q6 + Q6 -->|"Non"| R4 + Q6 -->|"Oui"| R5 +.... + +Figure 3 : Arbre de décision étendu pour le choix de la licence dans l'administration fédérale (si ni AGPL ni MIT) + +La nomenclature de la figure 3 est la software bill of materials (SBOM) de toutes les bibliothèques logicielles et sous-programmes préexistants intégrés dans la solution globale. Chaque bibliothèque a sa propre licence. Selon la compatibilité de celle-ci avec les autres (voir chapitre 4.4), le choix possible de licences pour la publication est restreint. + +Un dernier point peut aussi influencer la décision : *le passage d'une licence plus restrictive à une licence moins restrictive est plus facile après coup*. Dans le cas inverse, un forkfootnote:[Pour la définition, voir link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale].] est presque inévitable. + +== Thèmes juridiques particuliers + +=== Aspects internationaux + +Les questions juridiques essentielles des OSS dans la pratique relèvent principalement du droit des contrats de licence. + +S'agissant des questions de droit des licences, le droit choisi par les parties s'applique en premier lieu (la Mozilla Public License MPL contient par exemple, au chiffre 8, une élection de droit en faveur du droit du défendeur). + +En l'absence d'élection de droit, ce qui est le cas de toutes les autres licences présentées ici, le droit de l'État du donneur de licence s'applique en règle générale. Ainsi, lorsque les autorités fédérales acquièrent une licence de logiciel auprès de donneurs de licence étrangers, le droit du pays concerné s'applique. Si plusieurs contributeurs sont impliqués, cela peut conduire à des situations complexes. Inversement, le droit suisse s'applique en cas de litige entre des preneurs de licence étrangers et les autorités fédérales en tant que donneuses de licence. + +La question de savoir quels aspects relèvent du contrat et lesquels du droit d'auteur ne peut pas recevoir de réponse générale et peut s'avérer très complexe dans les cas d'espèce. La transmissibilité du droit d'auteur ou de parties de celui-ci, ou encore l'étendue des droits pouvant être concédés, relèvent par exemple du droit d'auteur. Le droit du pays de protection concerné doit ici être appliqué. Une élection de droit divergente n'est pas possible (sur l'ensemble, voir Jaeger/Metzger, 449 ss). + +=== Exclusion de responsabilité et de garantie + +Les licences open source excluent régulièrement toute garantie et toute responsabilité dans la mesure permise par le droit. Dans la pratique, les questions de responsabilité ou de garantie se posent rarement ; les risques y afférents sont donc faibles. + +On peut partir du principe qu'en cas de licence correcte, les clauses d'exclusion de responsabilité présentes dans toutes les licences examinées ici déploient leurs effets, de sorte que seule subsiste la responsabilité pour négligence grave et dol, le cas échéant pour dommages corporels. + +Des règles relatives aux conditions générales demeurent réservées, comme en Allemagne par exemple ; toutefois, dans la mesure où les autorités fédérales sont sujets de responsabilité en tant que donneuses de licence, le droit suisse s'applique (voir 8.1 ci-dessus), lequel admet les exclusions de responsabilité et de garantie précitées dans les relations B2B. + +À l'inverse, cela signifie cependant aussi qu'en cas d'erreurs de programme, il est généralement difficile d'agir contre les auteurs du code OSS intégré. + +La démarche habituelle lors de l'utilisation d'OSS consiste donc régulièrement à se prémunir contre les erreurs par les mesures usuelles de sécurité informatique et à assurer la correction des erreurs au moyen de contrats de maintenance. Il n'existe pas de recours contre les contributeurs OSS. + +=== Copyleft et licences entre entités de l'administration fédérale + +Le copyleft s'applique lors de la transmission entre différentes entités juridiques (par exemple au sein d'un groupe ou entre services de l'administration fédérale décentralisée dotés de leur propre personnalité juridique). + +Le copyleft ne s'applique pas lors de la transmission entre services d'une même entité juridique (par exemple au sein de l'administration fédérale centrale). + +=== Licence de brevets + +Les brevets logiciels ne sont possibles que dans des limites étroites selon la conception juridique européenne. L'élément déterminant est que le logiciel apporte une contribution technique, c'est-à-dire résolve un problème technique concret en dehors de l'ordinateur sur lequel il s'exécute. La commande d'un moteur dans une voiture ou la commande d'un robot en seraient des exemples. Un logiciel en tant que tel, qui ne s'exécute que sur un ordinateur mais n'a pas un tel effet externe, n'est en principe pas brevetable en Europe. La plupart des programmes logiciels ne relèvent donc pas du droit des brevets. + +Dans d'autres parties du monde, en particulier aux États-Unis, les brevets logiciels sont délivrés un peu plus libéralement. Toutefois, même aux États-Unis, une idée abstraite ou un modèle d'affaires ne devient pas une invention brevetable du seul fait qu'il est mis en œuvre dans un logiciel. + +Avec certaines licences, les éventuels brevets du donneur de licence ne sont pas concédés en même temps. Il s'agit de la GPL2, des licences BSD et de la licence MIT. + +Pour les projets susceptibles d'être utilisés aussi hors d'Europe, ou qui présentent la forme d'effet externe précitée, il est recommandé de clarifier les aspects de droit des brevets au cas par cas. + +=== Double licence + +L'auteur peut placer un logiciel simultanément sous différentes licences. On parle alors de double licence. + +Une forme intéressante de double licence consiste, pour le titulaire des droits, à placer le logiciel sous OSS avec un copyleft fort (ce qui empêche son intégration dans un logiciel propriétaire) et à proposer parallèlement aux preneurs de licence intéressés une licence _payante_ leur permettant d'intégrer le logiciel dans leur logiciel propriétaire. + +Comme les preneurs de licence intéressés peuvent ainsi éviter de publier leur logiciel propriétaire en OSS, ils sont disposés à payer pour la licence. Voir aussi l'annexe de link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale]. + +Pour les autorités fédérales elles-mêmes, la double licence ne devrait présenter d'intérêt que dans de rares cas. Tant que les droits d'auteur appartiennent aux autorités fédérales (ce qui est réglé par exemple par les conditions générales de l'administration fédérale), celles-ci peuvent décider seules d'une éventuelle double licence. + +Lorsque la maintenance et le développement (ultérieur) sont externalisés à des tiers, il peut en aller autrement. Si les droits leur appartiennent exceptionnellement et que les autorités fédérales se sont seulement réservé le droit d'octroyer une licence OSS avec copyleft, le tiers pourrait être tenté de procéder à une double licence. Si cela doit être empêché, il convient de l'exclure contractuellement. + +=== Modification ultérieure des licences + +Il convient d'abord de relever que les licences OSS sont en principe immuables et irrévocables. Les preneurs de licence ayant conclu le contrat de licence _avant_ une modification peuvent continuer à utiliser, modifier et transmettre le code à des tiers sur la base de l'ancienne licence. + +Dans la pratique, un changement de licence conduit souvent à un fork d'une nouvelle version du logiciel sous l'ancienne licence, développé de manière autonome par les anciens preneurs de licence. + +L'introduction d'une nouvelle licence pour un logiciel n'est possible que si tous les titulaires des droits d'auteur sur le logiciel y consentent. Des changements sont survenus dans la pratique, par exemple lors du passage d'une licence permissive à une licence copyleft. + +=== Mention des contributeurs (employés et tiers) + +Lorsqu'un programme d'ordinateur est créé dans le cadre d'un rapport de travail, l'employeur obtient une licence exclusive pour son utilisation (art. 17 LDA). Il ne reste donc pour l'essentiel aux employés que les droits moraux sur le logiciel (ou, selon l'opinion juridique, seulement leur noyau dur). Il en va de même pour les tiers qui développent des logiciels pour les autorités fédérales, pour autant que les CGfootnote:[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] correspondantes de la Confédération s'appliquent, lesquelles transfèrent les droits qui en résultent aux autorités fédérales. + +Il se pose néanmoins la question de savoir si les contributeurs (employés, tiers) doivent avoir le droit ou l'obligation de se faire connaître comme auteurs de contributions dans les dépôts open source. + +Un argument en faveur du recours aux OSS par les autorités fédérales est l'attractivité de l'emploi : les OSS offrent aux contributeurs la possibilité de montrer publiquement leurs connaissances et de se forger ainsi une réputation. Leurs capacités deviennent vérifiables, sont attestées par des pairs, et celui qui a acquis de l'influence dans un projet OSS peut s'en servir comme levier dans sa recherche d'emploi. + +Un autre argument pourrait être les droits moraux, dont le noyau ne peut être retiré à l'auteur d'origine ni par contrat ni par la loi. Ce noyau est toutefois restreint pour les programmes d'ordinateur ; exiger que le développeur d'un programme ait aussi un droit à être nommé irait probablement trop loin. + +De plus, un échange entre spécialistes dans la communauté suppose qu'ils puissent être contactés individuellement par d'autres. + +Selon le projet, il peut donc être judicieux de donner aux contributeurs la possibilité de se faire connaître comme contributeurs au sein de la communauté. + +Du point de vue de la protection des données, toute contrainte en ce sens doit être évitée, étant précisé que l'échange au sein de la communauté ne suppose pas la divulgation des noms — les pseudonymes sont la règle plutôt que l'exception. Si des contributeurs ne souhaitent pas divulguer leur nom, il convient dès lors de leur donner la possibilité d'apparaître sous un pseudonyme. + +*Il est recommandé de mentionner les noms des développeurs dans les commits, si le projet ne s'y oppose pas.* + +*Dans tous les cas, les autorités fédérales devraient agir en qualité de titulaires des droits.* + +=== Droit d'auteur, licences pour l'IA générative servant à créer du code + +Nous ne visons ici que le code créé au moyen d'une IA générative. De plus amples informations sur ce sujet figurent dans link:em002-6.pdf[Em002-6 FAQ sur l'OSS++*++, chapitre 2.2]. Le code créé par un LLM n'est pas lui-même protégé par le droit d'auteur. Les données d'entraînement utilisées par le LLM peuvent toutefois être protégées par le droit d'auteur. Si le code correspond au 1:1, la licence devrait également être reprise. Si le code a été créé par fragments puis modifié par les développeurs, le risque qu'il soit considéré comme un logiciel dérivé est faible. Il convient de noter que certains LLM exigent que le code soit désigné en conséquence ; les éventuels accords contractuels à ce sujet doivent être respectés. + +=== Contributor Licence Agreements (CLA) et Developer Certificate of Origin (DCO) + +Lorsque plusieurs auteurs travaillent sur le code d'un projet open source, ils obtiennent des droits communs sur le code qui en résulte. + +La concession de licence du code à des tiers s'effectue via la licence OSS, un contrat de licence distinct étant conclu entre chaque utilisateur et chaque auteur (faisceau de licences). Cette constellation peut conduire à une situation juridique peu lisible, par exemple dans les relations internationales (voir 8.1 ci-dessus). Lorsque des entreprises décident de placer leur logiciel sous licence OSS et d'accepter des contributions de tiers, elles éprouvent parfois le besoin de conserver un certain contrôle sur le code. + +Ainsi, il peut être intéressant de garder ouverte la possibilité de placer le projet sous une nouvelle licence, ou de vouloir soumettre du code sous copyleft à une double licence, ce qui requiert plus de droits que ceux obtenus des contributeurs par une simple licence OSS (voir 8.5 ci-dessus). Les Contributor Licence Agreements (parfois aussi Copyright Transfer Agreements) visent à résoudre de tels problèmes. + +Un *Contributor Licence Agreement (CLA)* est un *accord juridiquement contraignant* qui définit les *conditions applicables aux contributions au projet*. + +Les contributeurs sont tenus d'approuver cet accord avant de pouvoir apporter du contenu au projet. Pour l'essentiel, les contributeurs accordent au projet et à ses utilisateurs le droit d'*utiliser, de modifier et de redistribuer* les contributions apportées. Il est en outre confirmé que les contributions *ont été rédigées de manière autonome ou légitimées par des tiers*. + +Le *Developer Certificate of Origin (DCO)* est un *système de vérification introduit* par la Linux Foundation en 2004, dont le but est proche du Contributor Licence Agreement (CLA) et qui constitue un instrument alternatif approprié. Les contributeurs confirment pour chaque contribution au projet que *(a) ils sont habilités à apporter la contribution, (b) la contribution est couverte par une licence compatible avec le projet et (c) ils consentent à la diffusion et à l'utilisation de la contribution en open source*. + +L'instrument principal des CLA est soit la cession des droits d'auteur des contributeurs au développeur principal ou à l'organisation porteuse (dans le cas des Copyright Transfer Agreements), soit l'octroi par les contributeurs au développeur principal de la licence la plus étendue possible, généralement irrévocable (Apache a p. ex. défini un CLA). Les contributions à des projets fermés sont elles aussi souvent soumises à un CLA. + +Les CLA sont controversés dans la communauté OSSfootnote:[Par exemple : https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/], notamment parce qu'ils peuvent ouvrir des brèches dans le copyleft. C'est pourquoi il existe désormais aussi des CLA qui limitent le développeur principal quant à l'octroi d'une nouvelle licence pour le code du projet. + +[mermaid,align="center",alt="Transfert du code source et des droits dans différentes constellations"] +.... +flowchart LR + subgraph TP["Tiers"] + TP1["aucun document propre"] + TP2["CLA
DCO
licence OSS"] + TP3["CLA
DCO
licence OSS
contrat"] + TP4["aucun document propre"] + end + subgraph FA["Administration fédérale"] + FA1["CG de la Confédération
contrat"] + FA2["aucun document propre"] + FA3["licence OSS
contrat
(DCO)
(CLA)"] + FA4["licence OSS
(DCO)
(CLA)"] + end + TP1 -- "création" --> FA1 + TP2 -- "contribution de l'administration fédérale" --- FA2 + TP3 <-- "collaboration" --> FA3 + TP4 -- "contribution de tiers" --> FA4 +.... + +Figure 4 : Transfert du code source et des droits dans différentes constellations + +Légende : + +* Les cadres indiquent *où les droits sont définis* dans chaque constellation. +* *Création* et *contribution de tiers* : l'administration fédérale dispose du pouvoir de façonner la situation. +* *Collaboration* : les documents sont convenus entre les parties. +* *Contribution de l'administration fédérale* : l'administration fédérale ne dispose d'aucun pouvoir de façonner la situation, un examen est nécessaire. +* Les documents juridiques sont classés par ordre de priorité, de haut en bas ; les documents entre parenthèses sont plutôt à éviter. + +Pour les *développements propres* (creation), il n'y a pas de problème : selon l'art. 17 LDA, l'autorité fédérale est titulaire des droits d'utilisation sur les logiciels créés par ses propres employés. Pour les *développeurs tiers*, les autorités fédérales devraient s'assurer les droits (par exemple en utilisant les CG correspondantes de la Confédération). Aucun CLA ni DCO n'est donc nécessaire ici. + +Lorsque des autorités fédérales sont développeurs principaux et acceptent des contributions et des collaborations, il convient de renoncer à l'utilisation d'un CLA. Des Digital Certificates of Origin (expliqués avec un exemple dans link:em002-4.pdf[Em002-4 Guide des communautés OSS], chapitre 3.3) peuvent être utilisés à la place. En principe, les contributions aux projets des autorités fédérales devraient s'appuyer sur la licence OSS afin de ne pas relever davantage la barrière à la contribution. + +Si un besoin de CLA devait néanmoins être constaté dans un cas d'espèce après examen approprié, l'autorité fédérale devrait utiliser le CLA d'Apache.footnote:[https://www.apache.org/licenses/contributor-agreements.html] Dans ce cas, cette décision et le CLA devraient être mentionnés dans les remarques finales tant de la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[liste de contrôle Em002-2.1 Évaluation préalable] que de la link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS]. + +Lorsque des autorités fédérales contribuent à un logiciel de tiers exigeant un CLA, le service juridique doit examiner au cas par cas si l'autorité fédérale peut accepter le CLA existant.footnote:[Pour un destinataire donné, l'administration fédérale n'aurait à examiner la signature d'un CLA qu'une seule fois. Dans d'autres organisations, cela est dès lors traité comme une affaire de haut niveau, les CLA signés étant conservés dans le répertoire des contrats. Les CLA ne doivent pas contourner les obligations de l'autorité fédérale au titre de l'art. 9 LMETA.] Les points suivants doivent être déterminés : + +* Une autre autorité fédérale a-t-elle déjà signé le CLA ? +* Qui examine le CLA ? +* Qui le signe ? (Le signataire doit être habilité à signer pour la Confédération à l'égard de tiers) +* Où est-il classé ? +* Comment le CLA ou le DCO est-il documenté dans le projet ? +* Comment s'assure-t-on que le code publié le reste ? (Cela demeure de la responsabilité de l'autorité fédérale au titre de l'art. 9 LMETA, voir [KBB-MB].) + +Critères possibles pour l'examen : + +* Compatibilité avec l'art. 9 LMETA : le code reste-t-il ouvert ? +* L'autorité fédérale voit-elle des risques pour elle-même ? +* L'autorité fédérale voit-elle un bénéfice pour elle-même (p. ex. le code ne doit pas être maintenu ou développé seule) ou pour d'autres (au sein du fédéralisme suisse ou à l'échelle européenne, un impact plus large peut être obtenu sans charge supplémentaire) ? +* Les droits cédés sont-ils raisonnables ? +* Aucune obligation (inutile) n'est-elle imposée à l'autorité fédérale ? +* Le CLA est-il substantiellement équivalent au CLA d'Apache ? + +=== Problèmes avec la (L)GPL-3.0 et l'IoT + +_[BITKOM2023]_ signale un problème lié à l'utilisation des licences (L)GPL-3.0 en lien avec les logiciels embarqués : de tels appareils devraient permettre l'installation de versions logicielles propres ou nouvelles. Cela peut être indésirable pour des raisons de sécurité. + +=== Statut juridique de la documentation + +Selon l'art. 5 LDA, « les décisions, procès-verbaux et rapports qui émanent des autorités et des administrations publiques » ne sont pas protégés par le droit d'auteur. + +Cela va plus loin que CC-0, car le titulaire des droits n'a pas besoin de verser l'œuvre dans le domaine public en renonçant mondialement à tous les droits d'auteur et droits voisins. Elle est déjà dans le domaine public de par la loi. Le message relatif à l'art. 5 LDA précise : « La disposition admet toujours la protection par le droit d'auteur pour toute une série d'œuvres nées d'une activité officielle ou en lien avec celle-ci. + +Les documents de commissions d'étude et de groupes de travail internes à l'administration, les expertises ou les revues des offices fédéraux, par exemple, ne tombent pas sous le coup de la norme. Il n'existe pas d'intérêt prépondérant à leur libre diffusion, car ils n'influencent pas la situation juridique du citoyen. » + +On peut ainsi soutenir que, pour bon nombre des documents pertinents et de la documentation publiée par les autorités fédérales en lien avec les logiciels open source, aucune protection par le droit d'auteur n'existe. Le critère est de savoir si le document affecte ou non le statut juridique du citoyen et échappe ainsi à la protection du droit d'auteur. Si tel n'est pas le cas, une licence appropriée (CC-0footnote:[https://www.creativecommons.ch/], CC-BY, CC-BY-SA ou éventuellement LGPL) devrait être utilisée pour la documentation. + +Néanmoins, en particulier en cas d'utilisation internationale de la documentation, la situation resterait peu claire pour de nombreux utilisateurs. + +Nous estimons donc judicieux que, comme pour le présent document, une publication correspondante soit également indiquée par sécurité. + +== Informations complémentaires sur les questions juridiques + +De plus amples informations sur les logiciels open source, sur les caractéristiques de licences spécifiques et sur des aspects juridiques approfondis figurent dans de nombreuses publications, présentées ci-après (voir aussi les références à la fin du document). + +* Le texte _« Open Source Software im EMBAG, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben »_ de Rika Koch et Simon Schlauri, dans les actes de la Conférence sur les acquisitions informatiques 2023 à Berne, offre des orientations supplémentaires sur la mise en œuvre de l'art. 9 LMETA. +* Le _Leitfaden Open-Source-Software 2.0_ de la BITKOM allemande traite en détail des questions juridiques liées à l'open source _[BITKOM2023]_. Il se fonde toutefois sur la situation juridique en Allemagne. +* Wolfgang Straub examine, dans son ouvrage _Softwareschutz: Urheberrecht, Patentrecht, Open Source_, les détails juridiques du copyleft en relation avec le droit d'auteur suisse et étudie la compatibilité des licences open source [St2011]. Le chapitre consacré aux logiciels open source (ainsi que des traductions allemandes de diverses licences open source tenant compte de la terminologie juridique suisse) sont librement accessibles sur _www.it-recht.ch._ +* Till Jaeger et Axel Metzger répondent de manière approfondie à de nombreuses questions juridiques liées aux logiciels open source dans leur ouvrage complet _Open Source Software - Rechtliche Rahmenbedingungen der Freien Software [JaAx2016]_. Ils fondent toutefois leur analyse sur la situation juridique en Allemagne. +* Kropp Jonathan/Bauer Alexander, Open Source Compliance und Litigation, CB 2019 p. 285 ss, 285. +* Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de « logiciels libres » (open source), SZW 2022 p. 69 ss. + +Divers portails en ligne fournissent en outre des informations détaillées sur les caractéristiques et les questions relatives à des licences open source spécifiques. + +* Sur la plateforme GitHub https://choosealicense.com, les objectifs souhaités pour un projet open source peuvent être sélectionnés et la licence open source appropriée est proposée. +* Sur https://opensource.guide/legal/, GitHub met à disposition un guide en ligne traitant de questions juridiques spécifiques. +* Sur https://www.gnu.org/licenses/license-list.fr.html figurent de brefs commentaires sur diverses licences avec des indications sur leur compatibilité, en particulier avec la GPL. +* Sur https://opensource.org/faq, l'Open Source Initiative traite de nombreuses questions et réponses sur les aspects juridiques des licences open source. +* Sur https://copyleft.org/guide figure un guide détaillé expliquant les détails du copyleft. +* Sur https://tldrlegal.com, les principales licences open source sont résumées selon ce que la licence concernée permet (« can »), ce qu'elle interdit (« cannot ») et ce qu'elle prescrit (« must »). +* Sur https://opensource.com/tags/licensing sont publiés en continu des articles sur des questions de licence actuelles. +* Sur https://www.ifross.org/faq-haeufig-gestellte-fragen, l'« Institut für Rechtsfragen der Freien und Open Source Software » privé de Berlin (ifrOSS) a publié de nombreuses réponses à des questions juridiques fréquentes. + +Aujourd'hui, le respect des licences open source est mis en œuvre en premier lieu à l'aide d'outils logiciels (pour de plus amples informations sur la conformité open source, voir aussi Fröhlich-Bleuler _[Fr2012]_ et Kuhn, Williamson et Sandler _[KuWiSa2008]_). Divers outils open source de la Linux Foundation sont ainsi documentés et publiés sous le terme « fossology » sur https://www.fossology.org. Des fournisseurs commerciaux tels que Black Duckfootnote:[https://www.blackducksoftware.com] ou FOSSAfootnote:[https://fossa.com] proposent également diverses solutions propriétaires permettant de vérifier la compatibilité des licences open source utilisées. + +== Annexe + +=== Modifications par rapport à la version précédente + +* Résumé à l'intention de la direction ajouté. +* Les licences AGPL et MIT sont désormais recommandées comme préférables. +* Nouveau au chapitre 8.8 : droit d'auteur pour le code généré par IA. +* Chapitre 8.9 CLA et CDO fortement étoffé. +* Diverses améliorations rédactionnelles et précisions. +* Davantage d'exemples donnés. + +=== Références + +Voir link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale]. + +=== Abréviations + +Voir link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] et link:em002-6.pdf[Em002-6 FAQ sur l'OSS]. + +=== Exemples de publications et de leur licence + +À l'avenir, cette liste sera remplacée par une collecte de métadonnées via publiccode.yml. + +=== D.1 Loom + +URL:: +https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom +Autorité fédérale:: +Cyber Command +Description:: +Loom est un moteur de recherche documentaire puissant et facile à utiliser. Il automatise l'indexation des sources de données configurées, effectue l'OCR, extrait le contenu et les métadonnées, permet le marquage et offre de puissantes fonctions de recherche et d'utilisation. +Année:: +2025 +Licence:: +MIT +Justification:: +- + +=== D.2 trustbroker.swiss + +URL:: +https://github.com/trustbroker-swiss/trustbroker.swiss +Autorité fédérale:: +ChF, OFIT +Description:: +Trust Broker Swiss fournit des services de fédération entre relying parties (applications, fournisseurs de services, autres systèmes IAM ou policy enforcement points) et fournisseurs d'identité (IdP, également appelés claims providers), en recourant à des magasins d'attributs de confiance pour enrichir les utilisateurs authentifiés. + +Il permet aux fournisseurs d'identité/de claims et aux relying parties d'échanger des informations via un tiers qui masque les spécificités de l'IdP et fournit une identité unifiée ou du moins vérifiée en sus. +Année:: +2024 +Licence:: +AGPL +Justification:: +Les modifications du code doivent toujours rester ouvertes et revenir au projet. ++ +Un examen très détaillé de la question de la licence a été réalisé pour le Trust Broker. Pour de très grands projets, il peut être mené à ce niveau de détail. Toutes les licences compatibles avec la software bill of materials ont été recensées dans un pool de licences. + +=== D.3 Geocat.ch + +URL:: +https://github.com/geonetwork/core-geonetwork +Autorité fédérale:: +Swisstopo +Description:: +GeoNetwork est une application de catalogue pour la gestion de ressources géoréférencées. Elle offre de puissantes fonctions d'édition et de recherche de métadonnées ainsi qu'un visualiseur de cartes web interactif. Elle est actuellement utilisée dans de nombreuses initiatives d'infrastructures de données spatiales à travers le monde. +Année:: +2012 +Licence:: +GPL 2.0 +Justification:: +- + +=== D.4 GWEN / ampycloud / c4dl-multi / dvas /… + +URL:: +https://meteoswiss.github.io/ampycloud/ +Autorité fédérale:: +MétéoSuisse +Description:: +Paquet Python permettant de déterminer la proportion de couverture du ciel et la hauteur de base des couches nuageuses à partir de données de célomètre. +Année:: +2023 +Licence:: +Diverses licences, FSS +Justification:: +- + +=== D.5 Application EMSG (gestion du patrimoine en milieu urbain) + +URL:: +https://github.com/astra-emsg/ASTRA.EMSG +Autorité fédérale:: +MétéoSuisse +Description:: +EMSG est une application web SIG en C# développée par l'administration fédérale suisse pour gérer la gestion du patrimoine des systèmes routiers urbains. +Année:: +2017 +Licence:: +BSD +Justification:: +- + +=== D.6 Application certificat Covid + +URL:: +https://github.com/admin-ch/CovidCertificate-Documents +Autorité fédérale:: +OFIT +Description:: +Application suisse pour les certificats COVID +Année:: +2020 +Licence:: +MIT +Justification:: +Aussi permissive que possible afin que chacun puisse utiliser le code. + +=== D.7 Site web GovCert + +URL:: +https://github.com/govcert-ch/website +Autorité fédérale:: +NCSC +Description:: +Code source du site web de l'équipe d'intervention en cas d'urgence informatique (GovCERT) de l'administration fédérale suisse +Année:: +2023 +Licence:: +MIT +Justification:: +- + +=== D.8 Diverses bibliothèques sur les données ouvertes (p. ex. linked data) + +URL:: +https://github.com/SwissFederalArchives +Autorité fédérale:: +AFS +Description:: +Le dépôt des Archives fédérales suisses sur GitHub donne accès aux codes sources de nos applications. Il vous permet de créer vos propres forks et de signaler des erreurs ou de proposer des fonctionnalités étendues via l'interface « Issues ». +Année:: +2023 +Licence:: +AGPL, Apache, MIT +Justification:: +Les données ouvertes et les logiciels open source vont dans la même direction. L'AGPL permet une ouverture maximale. + +=== D.9 Apache FOP adapté pour des PDF archivables + +URL:: +https://xmlgraphics.apache.org/fop/ +Autorité fédérale:: +IPI +Description:: +L'IPI souhaitait une version d'Apache FOP capable de générer des PDF archivables. À cette fin, une extension a été commandée auprès de l'un des développeurs principaux (Jeremias Märki). Les adaptations ont été intégrées directement dans le projet. +Année:: +2007 +Licence:: +Apache +Justification:: +Des extensions ont été apportées à un projet open source existant. + +=== D.10 Dépôt électronique conforme au droit avec eKomm + +URL:: +https://launchpad.net/ekomm +Autorité fédérale:: +IPI +Description:: +L'IPI souhaitait un logiciel pour le dépôt électronique. +Année:: +2009 +Licence:: +Apache +Justification:: +L'IPI souhaitait que le fournisseur (Glue) procède à la publication et l'a autorisée en mode permissif (intégration dans ses propres applications). +endif::[] + +ifeval::["{lang}" == "it"] +*Avvertenza:* 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 {url-repo}/tree/main[README] principale. + +''''' + +== Riassunto per la direzione + +Si raccomanda di stabilire strategicamente nell'Amministrazione federale, all'avvio di un nuovo progetto, una delle due licenze seguenti: + +* *Licenza AGPL*: effetto copyleft auspicato. Il codice modificato deve in ogni caso ritornare alla collettività e può poi essere ripreso anche dall'Amministrazione federale. Si raccomanda di utilizzare la versione più recente della licenza. È così che il principio «public money – public code» è meglio soddisfatto. I diritti di terzi, in particolare in caso di ulteriori sviluppi, possono attenuare ciò fino alla LGPL. +* *Licenza MIT*: terzi devono poter sviluppare applicazioni proprietarie sulla base del codice dell'Amministrazione federale. Se è espressamente richiesta una clausola di non avallo, è da preferire la BSD-3-Clause. + +Per la scelta della licenza può essere utilizzato il seguente ausilio decisionale: + +[mermaid,align="center",alt="Ausilio decisionale semplificato per la scelta della licenza"] +.... +flowchart TD + S(["Inizio"]) + Q1{"L'«ambiente»
impone la licenza"} + A["Scegliere la licenza
imposta"] + Q2{"Libreria, implementazione di riferimento
o requisiti liberali"} + B["MIT"] + C["AGPL"] + S --> Q1 + Q1 -->|"Sì"| A + Q1 -->|"No"| Q2 + Q2 -->|"Sì"| B + Q2 -->|"No"| C +.... + +Figura 1: Ausilio decisionale semplificato per la scelta della licenza + +In una certa misura queste due licenze costituiscono i due estremi dello spettro delle licenze OSS. Può essere del tutto opportuno scegliere una licenza più adatta a un progetto concreto. La presente guida intende fornire un aiuto concreto in tal senso. + +Se l'analisi delle librerie software rivela che occorre utilizzare un'altra licenza, gli sviluppatori ne informano la direzione del progetto. L'analisi è esposta in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +Nella collaborazione a progetti esistenti sono in linea di principio accettabili tutte le licenze compatibili con l'OSI. + +== Introduzione + +L'articolo 9 della legge federale del 17 marzo 2023footnote:[RS 172.019] sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA) prevede che le autorità federali debbano pubblicare e licenziare come software open source il software che sviluppano o fanno sviluppare. + +Il presente documento persegue i seguenti obiettivi: + +* Introduzione ai temi del diritto d'autore sul software e delle licenze OSS. +* Una presentazione delle licenze OSS il cui impiego non pone problemi nell'Amministrazione federale. Le licenze non menzionate nel presente documento e il software soggetto a tali licenze non possono essere utilizzati senza un esame supplementare delle disposizioni contrattuali da parte del servizio giuridico competente. +* Un aiuto nella scelta della licenza per lo sviluppo o l'acquisto di un progetto ai sensi dell'art. 9 LMeCA. + +== Diritto d'autore e licenze: principi + +Il diritto d'autore fonda sia diritti morali sia diritti patrimoniali (diritti di utilizzazione). Tra i diritti morali rientrano per esempio il diritto al riconoscimento della paternità dell'opera o il diritto di decidere se e quando l'opera è divulgata. Tra i diritti di utilizzazione rientrano per esempio il diritto di allestire o di diffondere esemplari dell'opera. + +La legge federale del 9 ottobre 1992footnote:[RS 231.1] sul diritto d'autore e sui diritti di protezione affini (LDA) prevede una serie di ulteriori diritti morali e di utilizzazione (cfr. art. 8 segg. LDA). Tali diritti spettano direttamente all'autore nel momento stesso in cui l'opera è creata. + +L'art. 2 LDA stabilisce a quali condizioni è accordata la protezione del diritto d'autore. Un'opera protetta ai sensi della legge esiste soltanto se tali condizioni sono soddisfatte. + +Le condizioni sono: + +* L'opera deve essere stata creata; il semplice ritrovamento non basta. I dati di ricerca, per esempio, ossia i risultati di esperimenti, non possono essere qualificati come opere. +* La creazione deve essere «intellettuale», ossia provenire da un essere umano. +* L'opera deve essere stata realizzata in modo percepibile. La semplice idea alla base di un'opera non è protetta, bensì soltanto la sua forma esteriore, p. es. la stampa di un testo su carta o l'esecuzione di un brano musicale. +* Individualità: infine, l'opera deve presentare un certo grado minimo di individualità. Un'opera che tutti realizzerebbero allo stesso modo non è protetta. + +Possono essere protette le opere più diverse, quali testi letterari o scientifici, opere musicali, fotografiche, cinematografiche e altre opere visive o audiovisive. + +Secondo l'art. 2 cpv. 3 LDA anche i programmi per computer sono opere, se le condizioni menzionate sono soddisfatte. + +I diritti d'autore spettano, sin dalla loro nascita, unicamente all'autore. Soltanto egli può vietare ad altri di compiere gli atti corrispondenti. L'autore può tuttavia esercitare i propri diritti non soltanto personalmente: + +* Può trasferire i propri diritti a terzi (p. es. vendendoli). Il nuovo titolare dei diritti può quindi farli valere come se fosse l'autore. +* In alternativa l'autore può anche concedere i propri diritti in licenza a terzi. Semplificando, una licenza è un contratto con cui il titolare dei diritti consente a un terzo di utilizzare l'opera. L'autore conserva i diritti, ma rinuncia a farli valere nei confronti del licenziatario. + +Se un programma per computer è creato nell'ambito di un rapporto di lavoro, il datore di lavoro ottiene una licenza esclusiva per il suo utilizzo (art. 17 LDA). Ai lavoratori restano quindi essenzialmente soltanto i diritti morali sul software (ovvero, a seconda dell'opinione giuridica, soltanto il loro nucleo). Si tratta della medesima situazione giuridica prevista dalla legge sul personale federale. + +== Licenze OSS + +=== Principi + +L'OSS si caratterizza essenzialmente per i seguenti elementi (secondo una definizione dell'Open Source Initiative _[Pe1999]_footnote:[https://opensource.org/]): + +* è consentita la ridistribuzione illimitata e gratuita del software; +* il software è disponibile in forma di codice sorgente; +* le modifiche del software e la loro ridistribuzione sotto la medesima licenza sono in linea di principio consentite; +* nessuna persona o gruppo di persone può essere escluso dall'utilizzo del software e nessun ambito d'applicazione può essere escluso (in particolare non l'uso commerciale); e +* la diffusione del software insieme ad altro software (quale software closed source) non deve essere limitata. + +I motivi più frequenti per l'impiego dell'OSS sono anzitutto i risparmi conseguiti grazie all'utilizzo dell'ormai considerevole bacino di software liberamente utilizzabile. Le imprese che ricorrono frequentemente all'OSS riescono spesso a risparmiare parti considerevoli del proprio budget informatico. + +Il codice liberamente disponibile può inoltre essere facilmente adattato alle proprie esigenze. La scelta dell'OSS evita inoltre il vendor lock-in.footnote:[https://it.wikipedia.org/wiki/Lock-in_(economia)] + +=== Licenze open source + +Le licenze open source sono anzitutto normali contratti di licenza per programmi per computer. + +Diversamente dai normali contratti di licenza, i contratti di licenza OSS si perfezionano tuttavia senz'altro non appena viene esercitata anche solo una delle forme libere di utilizzo descritte nella licenza (per esempio copiando, ridistribuendo o modificando il software). + +=== Copyleft versus permissivo + +==== In generale + +Una licenza open source secondo l'OSI può contenere una clausola di «copyleft». Le modifiche apportate a software licenziato in tal modo devono essere offerte nuovamente alle stesse condizioni valide per il software originario. Chi apporta tali modifiche deve, nel diffondere il software open source in forma di codice oggetto leggibile dalla macchina, offrire ai destinatari anche il codice sorgente. + +Nella formulazione della Free Software Foundation, l'effetto copyleft protegge la libertà degli sviluppatori e garantisce così che un software una volta libero resti sempre libero. + +Con le licenze copyleft si realizza una sorta di scambio tra la community e le imprese utilizzatrici. Gli utenti, tenuti in cambio dei vantaggi derivanti dal bacino software esistente a ricollocare i propri sviluppi sotto la rispettiva licenza, contribuiscono così all'ulteriore sviluppo di tale bacino. Il risultato è che entrambe le parti ne traggono vantaggio. + +La clausola di copyleft ha un certo «effetto di contagio»: se software licenziato copyleft viene integrato in software precedentemente proprietario, il software originariamente proprietario deve essere divulgato sotto una licenza open source compatibile. + +Nell'utilizzo di codice sorgente licenziato copyleft occorre pertanto prestare attenzione a integrarlo soltanto laddove il software che ne risulta può e deve essere pubblicato sotto una licenza open source. + +Se una licenza open source non contiene una clausola di copyleft (licenza open source permissiva), la licenza per le versioni rielaborate del codice può essere scelta liberamente. In particolare è anche possibile ricollocare le modifiche sotto una licenza software proprietaria e integrare il corrispondente codice sorgente in software proprietario. + +Essenzialmente le licenze open source possono essere suddivise nelle *categorie seguenti*: + +. licenze open source con *copyleft forte*; +. licenze open source con *copyleft debole*; e +. licenze open source *permissive* o *senza copyleft*. + +==== Licenze open source con copyleft forte + +Utilizzando una licenza open source con copyleft forte, le nuove versioni derivate dal software originario devono, se trasmesse a terzi, essere poste sotto le condizioni della licenza originaria e messe a disposizione di tali terzi in forma di codice sorgente. + +Sul mercato le due licenze seguenti sono considerate le licenze open source determinanti con copyleft forte: + +* GNU General Public Licence (GPL); una gran parte dell'OSS è oggi licenziata sotto di essa +* GNU Affero General Public Licence (AGPL) + +La principale differenza tra GPL e AGPL riguarda il tipo di utilizzo che innesca il copyleft. Con software sotto GPL il codice sorgente modificato deve essere offerto soltanto se la nuova versione del software è offerta a terzi come programma eseguibile (p. es. come app mobile). Se il software è messo a disposizione soltanto via Internet (dal proprio cloud su propri server), per esempio in forma di «Software as a Service» (SaaS) o di interfaccia di programmazione (API), ciò non innesca il copyleft. + +Se il software è soggetto alla AGPL, il codice sorgente modificato deve essere fornito anche quando le funzionalità del software sono offerte tramite un sito web o un'interfaccia di programmazione. La AGPL è quindi ancora più rigorosa della GPL. + +Con le licenze a copyleft forte il copyleft riguarda non soltanto il rispettivo modulo software (libreria), bensì l'intero programma nel quale un modulo licenziato copyleft può essere incorporato. Il menzionato «effetto di contagio» si produce così. + +==== Licenze open source con copyleft debole + +Anche le licenze con copyleft debole esigono che le modifiche del loro codice sorgente siano pubblicate ai terzi destinatari sotto la licenza open source originaria. + +Diversamente dalle licenze a copyleft forte, esse non hanno tuttavia l'effetto di «infettare» con la propria licenza altri componenti software distinguibili (altre librerie o il programma principale stesso). Ciò consente l'integrazione di software open source a copyleft debole in software proprietario o in software soggetto ad altre licenze OSS, senza doverlo pubblicare sotto la licenza originaria. + +Queste sono le licenze open source a copyleft debole più utilizzate: + +* GNU Lesser General Public Licence (LGPL) +* Mozilla Public Licence 2.0 (MPL) +* Common Development and Distribution Licence (CDDL) +* Eclipse Public Licence (EPL)footnote:[Oltre alla Eclipse Public Licence (EPL-1.0) esiste anche la Eclipse Distribution Licence (EDL-1.0). + +Mentre la EDL corrisponde alla BSD 3-Clause, la EPL è una licenza a copyleft debole.] +* Microsoft Reciprocal Licence (Ms-RL) +* European Union Public Licence (EUPL)footnote:[La EUPL presenta essa stessa un copyleft forte, ma grazie alla clausola di apertura è possibile un passaggio a licenze a copyleft debole, per cui la protezione è limitata.] + +==== Licenze open source permissive + +Le licenze prive di effetto copyleft si caratterizzano per il fatto di non imporre al licenziatario alcun requisito riguardo alla licenza del suo software derivato, per cui né il suo nuovo codice sorgente né le modifiche del software open source devono essere divulgati ai terzi destinatari. Ciò consente lo sviluppo di prodotti software proprietari mediante l'integrazione di software sotto licenze open source permissive. + +Esempi di licenze permissive sono: + +* MIT Licence +* Apache Licence 2.0 +* Berkeley Software Distribution (BSD) Licence (BSD 2-Clause e BSD 3-Clause) +* Microsoft Public Licence (Ms-PL) + +=== Compatibilità delle licenze open source + +I programmi si compongono di regola di una molteplicità di componenti e moduli software che possono essere collegati tra loro in modi diversi. Nello sviluppo software componenti open source esistenti vengono spesso integrati in applicazioni e soluzioni interne proprietarie. Non appena queste diventano accessibili dall'esterno tramite un sito web, API, distribuzione software o in altro modo, occorre prestare attenzione alla compatibilità delle rispettive licenze open source, poiché allora il copyleft può produrre effetti. + +Se le opere derivate soggette a una determinata licenza possono essere diffuse soltanto alle medesime condizioni di licenza, ne consegue che non possono essere utilizzate altre licenze open source con obblighi diversi o contraddittori per le opere derivate. + +Alcune licenze open source contengono le cosiddette clausole di apertura, che consentono l'utilizzo del codice licenziato sotto di esse in progetti soggetti ad altre licenze. Così la LGPL versione 2.1 consente anche l'utilizzo del codice sotto la GPL. La GPLv3 contiene tra l'altro una clausola di compatibilità per la AGPL e la Apache License 2.0. La EUPL è concepita in modo molto aperto e contiene in allegato un lungo elenco di licenze compatibili, in particolare quelle a copyleft debole quali la LGPL. Ne consegue che la protezione copyleft forte effettivamente prevista dalla licenza risulta indirettamente attenuata. + +Il grafico seguente rappresenta le dipendenze delle principali licenze open source (Goldstein 2018). La rappresentazione si basa sulla visualizzazione di David A. Wheeler, che ha analizzato le compatibilità delle diverse licenze e dei loro numeri di versione (Wheeler 2007), ed è stata ulteriormente sviluppata con informazioni tratte da https://www.gnu.org/licenses/license-list.it.html[https://www.gnu.org/licenses/license-list.it.html].footnote:[Un'ulteriore rappresentazione, ampliata, è utilizzata da GEANT nel suo 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. Vi si trovano alcune licenze supplementari.] + +Il grafico va letto come segue: il codice soggetto a una licenza indicata prima nella catena può essere integrato in software pubblicato sotto una licenza indicata successivamente nella catena. Così il codice sotto la BSD modificata può essere posto sotto una variante di licenza LGPL o GPL, ma non viceversa. Public domain significa che l'opera non è soggetta ad alcuna restrizione di diritto d'autore. + +[mermaid,align="center",alt="Compatibilità delle licenze open source"] +.... +flowchart TB + subgraph P["Licenza permissiva"] + PD["Public domain"] + MIT["MIT/X11"] + BSD["BSD modificata"] + AP["Apache 2.0"] + end + subgraph W["Copyleft debole"] + EUPL["EUPL"] + LGPL21["LGPLv2.1"] + LGPL21P["LGPLv2.1+"] + LGPL3["LGPLv3 / LGPLv3.1"] + MPL["MPL 1.1"] + end + subgraph SC["Copyleft forte"] + GPL2["GPLv2"] + GPL2P["GPLv2+"] + GPL3["GPLv3 / GPLv3+"] + AGPL["Affero GPLv3"] + end + PD --> MIT + MIT --> BSD + BSD --> AP + BSD --> LGPL21 + BSD --> LGPL21P + BSD --> LGPL3 + BSD --> MPL + AP --> EUPL + AP --> LGPL3 + EUPL --> LGPL21 + EUPL --> LGPL21P + EUPL --> LGPL3 + EUPL --> MPL + LGPL21P --> LGPL21 + LGPL21P --> LGPL3 + LGPL21 --> GPL2 + LGPL21 --> GPL2P + LGPL21P --> GPL2P + LGPL3 --> GPL3 + GPL2P --> GPL2 + GPL2P --> GPL3 + GPL3 -->|"+ protezione della rete"| AGPL + classDef pd fill:#f5f5f5,stroke:#000000,color:#000000 + classDef perm fill:#dae8fc,stroke:#000000,color:#000000 + classDef weak fill:#d5e8d4,stroke:#000000,color:#000000 + classDef strong fill:#5ea226,stroke:#000000,color:#ffffff + class PD pd + class MIT,BSD,AP perm + class EUPL,LGPL21,LGPL21P,LGPL3,MPL weak + class GPL2,GPL2P,GPL3,AGPL strong +.... + +Figura 2: Compatibilità delle licenze open source (sulla base del grafico di David A. Wheeler, 2007 e di https://www.gnu.org/licenses/license-list.it.html) + +Importante: poiché le compatibilità delle licenze sono sempre rilevanti, i team di sviluppo e i fornitori di prestazioni dovrebbero verificare preventivamente gli stack di sviluppo con le relative librerie quanto a possibili problemi di compatibilità. Ciò significa che, prima di approvare l'utilizzo di una libreria, occorre verificare — oltre alla sicurezza e all'omogeneità dello stack di sviluppo — se la licenza della libreria è compatibile con le licenze determinanti privilegiate dall'Amministrazione federale. + +[[licences-for-pure-usage]] +== Licenze per il semplice utilizzo + +Il presente capitolo tratta la situazione in cui un software soggetto a una licenza OSS deve essere utilizzato, ma non deve essere modificato, oppure in cui le modifiche sono utilizzate soltanto internamente. + +Le licenze seguenti non pongono in linea di principio problemi quando il software è utilizzato dalle autorità federali. Le relative condizioni, segnatamente un eventuale copyleft, devono tuttavia essere rispettate. + +In determinate circostanze la licenza di un modulo software preesistente determina le licenze possibili per il prodotto complessivo (cfr. capitolo 4.4). + +Alcune licenze sono incompatibili tra loro (cfr. figura 2). + +[cols="1,1,3",options="header"] +|=== +|Licenza |Copyleft |Particolarità + +|*MIT* +|No +|Licenza privilegiata dell'Amministrazione federale quando si mira a un'ampia diffusione e terzi devono poter sviluppare nuovamente software proprietario a partire da essa. + +|*Apache 2.0* +|No +|Apache è una licenza molto diffusa, nota per i progetti riuniti sotto l'Apache Foundation. L'uso dei marchi dei licenzianti è escluso, salvo per descrivere l'opera. + +|*GPL v3* +|Sì +a|È LA licenza copyleft classica. + +Il copyleft si applica anche quando parti licenziate GPL sono incorporate in un programma complessivo. Divieto di digital rights management. Regole di compatibilità particolari. + +|*LGPLv3* +|Debole +a|Licenza copyleft ridotta, sviluppata appositamente per le librerie software. + +Diversamente dalla GPL, la LGPL consente a determinate condizioni di combinare codice chiuso (ossia proprietario) con codice LGPL. + +Ne sono esempi le librerie standard quali glibc. La LGPL consente di porre sotto GPL il programma di cui la libreria è diffusa quale parte. + +|*Affero GPLv3 (AGPL)* +|Sì +a|Anche l'uso in SaaS innesca il copyleft. Per il resto analoga alla GPLv3. + +Questa licenza colma la lacuna della GPL, per cui non era richiesta alcuna pubblicazione in caso di utilizzo per offerte SaaS. + +Con questa licenza l'Amministrazione federale può garantire che i miglioramenti del codice vadano a beneficio della collettività anche in caso di SaaS, e sostiene al meglio il principio *«public money – public code»*. + +|*BSD-3* +|No +a|Licenza generale e liberale. + +I nomi degli autori non possono essere utilizzati per promuovere opere derivate (clausola pubblicitaria) + +|*European Union Public Licence (EUPL)* +|Debole +a|Licenza particolare utilizzata per l'UE. + +Particolarmente utile come base per progetti europei. + +Licenza che tiene conto del diritto europeo. La pubblicazione sotto determinate licenze compatibili è espressamente consentita. +|=== + +Tabella 1: Licenze che non pongono problemi per le autorità federali (secondo _[Sc2024]_) + +Altre licenze possono essere utilizzate. In questi casi può essere necessario consultare il servizio giuridico dell'ufficio interessato. + +== Licenza per progetti propri o creation e per le contribution + +Il presente capitolo riguarda i casi seguenti: + +* Sviluppo ulteriore / contribution +** in cui le autorità federali sviluppano ulteriormente software esistente; oppure +** sviluppano nuovo software, basandosi però su librerie software OSS esistenti; e +** mettono il relativo software a disposizione di terzi. Tra i terzi rientrano anche le organizzazioni dell'Amministrazione federale decentralizzata, purché abbiano personalità giuridica propria. Se gli sviluppi ulteriori sono utilizzati soltanto internamente e non messi a disposizione di terzi, si applica unicamente <>. +* Progetti propri / creation / pubblicazione: il presente capitolo riguarda i casi in cui le autorità federali sviluppano nuovo software. Ciò dovrebbe essere raro, poiché la maggior parte degli sviluppi si basa su librerie software open source esistenti. ++ +Per gli sviluppi interamente nuovi andrebbe scelto un tipo di licenza che consenta una base ampia e duratura per gli sviluppi ulteriori. È importante a tal fine che la licenza in questione sia ampiamente accettata nella community di sviluppatori determinante. + +La verifica della compatibilità è svolta secondo link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS], capitolo 7.4. La compatibilità delle licenze è illustrata nella figura 2. + +Dovrebbero essere considerate le dimensioni seguenti: + +* Caso d'applicazione +* Verifica auspicata link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Lista di controllo Valutazione preliminare OSS] +* Facilità di costituzione di una community link:em002-4.pdf[Em002-4 Guida alle community OSS] +* Facilità d'applicazione +* Certezza del diritto +* Diffusione + +Sono da preferire le licenze secondo il capitolo <>. + +Le seguenti *licenze copyleft* dovrebbero essere utilizzate in via prioritaria dalle autorità federali, in particolare se si mira a uno sviluppo aperto e duraturo e se deve valere l'effetto copyleft ereditario. Ciò assicura che il software pagato dalla collettività e tutti i suoi derivati restino aperti. È così che il principio «*public money – public code*» è meglio soddisfatto e ciò costituisce *la raccomandazione privilegiata per l'Amministrazione federale.* + +Licenze raccomandate in ordine decrescente: + +* *AGPL v3* +* GPL v3 +* LGPL 3.0 +* European Union Public Licence (EUPL) + +Le licenze seguenti dovrebbero essere utilizzate dalle autorità federali quando *non è auspicato* o richiesto *alcun copyleft* (in ordine decrescente): + +* *MIT* +* Apache Licence 2.0 +* BSD v3 + +Nella collaborazione a progetti esistenti possono inoltre essere utilizzate senza problemi le licenze seguenti: + +* Mozilla Public Licence +* Microsoft Public Licence + +Se deve essere utilizzata un'altra licenza, si raccomanda di motivarlo brevemente nella link:em002-2-3-checklist-oss-release-and-publication.pdf[lista di controllo Em002-2.3 Rilascio e pubblicazione OSS]. + +*Secondo l'art. 9 cpv. 4 LMeCA dovrebbero essere in ogni caso utilizzate licenze affermate a livello internazionale.* + +Ulteriori strumenti per verificare le compatibilità delle licenze sono: + +* ORT Toolkit (https://oss-review-toolkit.org/) +* Black Duck (www.blackducksoftware.com), +* FOSSA (http://www.fossa.com[www.fossa.com]), +* l'Open Source Licence Comparison Grid (https://www.cmu.edu/cttec/forms/opensourcelicensegridv1.pdf) +* FOSSology (https://www.fossology.org). +* Processo OpenCode: https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen[https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses] + +== Casi d'applicazione e licenze adeguate + +La tabella e il grafico seguenti mostrano come, in funzione dei diversi casi d'applicazione, possano essere scelte licenze adeguate per il software open source. + +[cols="2,2,3",options="header"] +|=== +|*Caso d'applicazione* |*Licenza/e* |*Motivazione* + +|Utilizzare un progetto esistente e contribuirvi +|*Licenza secondo le prescrizioni del progetto* +|Necessario per motivi giuridici. + +|La licenza è imposta dall'utilizzo di parti esistenti (licenze con copyleft) +|*Utilizzare una licenza compatibile con tali parti.* +a|Necessario per motivi giuridici. + +Nota: diverse librerie sono disponibili sotto più licenze. + +Soltanto una delle licenze deve corrispondere. Uno degli scopi della licenza multipla è assicurare che le librerie possano essere utilizzate sia con sia senza copyleft. + +|Ecosistema esistente con licenza privilegiata (p. es. si tratta di un plug-in per software pubblicato sotto licenza MIT. L'uso di una licenza MIT sarebbe allora il più opportuno, poiché tutti gli altri utenti se lo attendono e il software si integra nell'ecosistema) +|*Utilizzare la licenza se figura nell'elenco, altrimenti utilizzare per quanto possibile la stessa licenza* +|L'accettazione nella community è centrale. + +|L'obiettivo è la diffusione più ampia possibile, p. es. per un'implementazione di riferimentofootnote:[Per esempio, al fine di rendere più agevole l'attuazione di una legge, un'implementazione di riferimento può essere commissionata dalle autorità federali. Cfr. p. es. https://ech.ch/de/ech/ech-0238/1.0] (p. es. per software destinato a essere utilizzato anche in soluzioni commerciali). +a|*MIT* + +BSD v3 + +Apache Licence 2.0 + +LGPL v3 +|In questo caso non andrebbe utilizzato alcun copyleft. + +|Le modifiche del codice devono ritornare alle autorità federali +a|*AGPL v.3* + +GNU GPL v.3 + +EUPL +|La AGPL impone la pubblicazione da parte di terzi anche in caso di utilizzo nel cloud, la GPL e la EUPL no. + +|Le soluzioni SaaS non devono essere esentate dal ritorno delle modifiche del codice +|*AGPL v.3* +|La AGPL impone la pubblicazione da parte di terzi anche in caso di utilizzo nel cloud. + +|Una collaborazione agevole con la community è importante. +a|*AGPL v.3* + +GNU GPL v3 + +Apache Licence 2.0 +a|La GPL è preferita per mantenere libero il software. + +Apache contiene regole per la governance della community, regole supplementari per i contributi (non si può indicare una licenza diversa da Apache; il contributo in quanto tale non è disciplinato più nel dettaglio, per cui se esiste un CLA questo prevale), una licenza di brevetto e regole per la licenza di brevetto. In particolare anche che chi fa valere brevetti contro un altro contributore perde la propria licenza di brevetto ai sensi della licenza Apache. + +Determinanti sono le regole che l'Apache Foundation stabilisce per i contributi. Apache è quindi opportuna se la governance del progetto deve essere costruita principalmente secondo Apache. + +|Piccolo componente (libreria) utilizzabile universalmente o piccolo software per il quale la sostenibilità o la manutenzione da parte di una community non sono importanti +a|*MIT* + +Apache Licence 2.0 + +BSD v3 + +LGPL v3 +a|La LGPL prevede un copyleft soltanto per il componente stesso, ma non per l'intero progetto nel quale il componente è inserito. + +Le altre licenze sono permissive. + +|Deve essere semplice e permissivo; il controllo non è importante +a|*MIT* + +Apache Licence 2.0 + +BSD v3 +|Massimamente permissivo + +|Per le autorità federali è importante che cosa avvenga del codice ed esse desiderano ricevere il maggior numero possibile di miglioramenti. +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Va impedito che il software diventi proprietario e sia posizionato sul mercato come prodotto concorrente +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|Va impedito che le autorità federali diventino dipendenti da singoli fornitori («vendor lock-in») +a|*AGPL v.3* + +GNU GPLv3 +|Il copyleft impedisce che un fornitore acquisisca con il tempo una posizione esclusiva utilizzando il software della Confederazione in un prodotto proprietario, il che potrebbe nuovamente creare per la Confederazione una dipendenza da tale fornitore. +|=== + +Tabella 2: Licenza da utilizzare a seconda del caso d'applicazione per la pubblicazione di nuovo software conformemente all'art. 9 LMeCA *(grassetto = raccomandato se nulla vi si oppone)* + +[mermaid,align="center",alt="Albero decisionale ampliato per la scelta della licenza nell'Amministrazione federale"] +.... +flowchart TD + S(["Inizio"]) + Q1{"La distinta base
impone la licenza?"} + R1["Scegliere la licenza
imposta / preferita"] + Q2{"In questo ambiente vi sono
licenze preferite?"} + Q3{"Figura nell'elenco delle licenze
idonee dell'Em002-3?"} + R2["Scegliere dall'elenco la licenza idonea
successiva secondo l'Em002-3, dopo aver
consultato il servizio giuridico"] + Q4{"Implementazione di riferimento
come proposta
per terzi?"} + R3["GPL o licenza permissiva:
MIT, BSD, Apache"] + Q5{"I miglioramenti
devono rifluire?"} + Q6{"Anche in caso
di utilizzo SaaS?"} + R4["GPL, EUPL"] + R5["AGPL"] + S --> Q1 + Q1 -->|"Sì"| R1 + Q1 -->|"No"| Q2 + Q2 -->|"Sì"| Q3 + Q2 -->|"No"| Q4 + Q3 -->|"Sì"| R1 + Q3 -->|"No"| R2 + Q4 -->|"Sì"| R3 + Q4 -->|"No"| Q5 + Q5 -->|"No"| R3 + Q5 -->|"Sì"| Q6 + Q6 -->|"No"| R4 + Q6 -->|"Sì"| R5 +.... + +Figura 3: Albero decisionale ampliato per la scelta della licenza nell'Amministrazione federale (se non AGPL o MIT) + +La distinta base della figura 3 è la software bill of materials (SBOM) di tutte le librerie software e i sottoprogrammi preesistenti confluiti nella soluzione complessiva. Ogni libreria ha la propria licenza. A seconda di come questa sia compatibile con le altre (cfr. capitolo 4.4), la scelta possibile di licenze per la pubblicazione risulta limitata. + +Un ultimo punto può parimenti influenzare la decisione: *il passaggio da una licenza più restrittiva a una meno restrittiva è più semplice a posteriori*. Nel caso opposto un forkfootnote:[Per la definizione cfr. link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale].] è pressoché inevitabile. + +== Temi giuridici particolari + +=== Aspetti internazionali + +Le questioni giuridiche essenziali dell'OSS nella pratica sono prevalentemente di natura contrattuale in materia di licenze. + +Per le questioni di diritto delle licenze si applica anzitutto il diritto scelto dalle parti (la Mozilla Public License MPL contiene per esempio al numero 8 una scelta del diritto a favore del diritto del convenuto). + +In assenza di scelta del diritto, il che è il caso di tutte le altre licenze qui presentate, si applica di regola il diritto dello Stato del licenziante. Pertanto, quando le autorità federali acquisiscono licenze software da licenzianti esteri, si applica il diritto del rispettivo Paese. Se sono coinvolti più contributori, ciò può dar luogo a situazioni complesse. Viceversa, in caso di eventuali controversie tra licenziatari esteri e le autorità federali quali licenzianti si applica il diritto svizzero. + +La questione di quali aspetti siano di natura contrattuale e quali di diritto d'autore non può ricevere una risposta generale e può risultare piuttosto complessa nei singoli casi. La trasferibilità del diritto d'autore o di parti di esso, oppure l'estensione dei diritti che possono essere concessi, appartengono per esempio al diritto d'autore. Qui va applicato il diritto del rispettivo Paese di protezione. Una scelta del diritto divergente non è possibile (sull'insieme cfr. Jaeger/Metzger, 449 segg.). + +=== Esclusione della responsabilità e della garanzia + +Le licenze open source escludono regolarmente ogni garanzia e responsabilità nella misura consentita dal diritto. Nella pratica si pongono raramente questioni di responsabilità o garanzia; i rischi connessi sono pertanto ridotti. + +Si può presumere che, con una licenza corretta, le clausole di esclusione della responsabilità presenti in tutte le licenze qui trattate producano i loro effetti, per cui residua soltanto la responsabilità per negligenza grave e dolo, eventualmente per danni alle persone. + +Restano salve le regole sulle condizioni generali, come per esempio in Germania; tuttavia, nella misura in cui le autorità federali sono soggetto di responsabilità quali licenzianti, si applica il diritto svizzero (cfr. 8.1 sopra), che ammette le suddette esclusioni di responsabilità e garanzia nei rapporti B2B. + +Per contro ciò significa però anche che, in caso di errori del programma, agire contro gli autori del codice OSS integrato è di regola difficile. + +La prassi usuale nell'impiego dell'OSS consiste quindi regolarmente nel tutelarsi dagli errori con le consuete misure di sicurezza informatica e nell'assicurare la correzione degli errori mediante contratti di manutenzione. Non sussiste alcun regresso nei confronti dei contributori OSS. + +=== Copyleft e licenze tra enti dell'Amministrazione federale + +Il copyleft si applica alla trasmissione tra diversi soggetti giuridici (per esempio all'interno di un gruppo o tra servizi dell'Amministrazione federale decentralizzata dotati di personalità giuridica propria). + +Il copyleft non si applica alla trasmissione tra servizi del medesimo soggetto giuridico (per esempio all'interno dell'Amministrazione federale centrale). + +=== Licenza di brevetti + +I brevetti software sono possibili soltanto entro limiti ristretti secondo la concezione giuridica europea. Determinante è che il software fornisca un contributo tecnico, ossia risolva un problema tecnico concreto al di fuori del computer su cui viene eseguito. Esempi sarebbero il controllo del motore nelle automobili o il comando di un robot. Il software in quanto tale, che viene eseguito soltanto su un computer ma non ha un simile effetto esterno, non è in linea di principio brevettabile in Europa. La maggior parte dei programmi software non rientra quindi nell'ambito del diritto dei brevetti. + +In altre parti del mondo, in particolare negli Stati Uniti, i brevetti software sono concessi in modo un po' più liberale. Tuttavia, anche negli Stati Uniti un'idea astratta o un modello di business non diventa invenzione brevettabile per il solo fatto di essere attuato in un software. + +Con alcune licenze gli eventuali brevetti del licenziante non sono concessi in licenza insieme al software. Si tratta della GPL2, delle licenze BSD e della licenza MIT. + +Per i progetti che potrebbero essere utilizzati anche al di fuori dell'Europa, o che presentano la forma di effetto esterno sopra menzionata, si raccomanda di chiarire caso per caso gli aspetti di diritto dei brevetti. + +=== Doppia licenza + +L'autore può licenziare il software contemporaneamente sotto licenze diverse. Ciò è detto doppia licenza. + +Una forma interessante di doppia licenza si ha quando il titolare dei diritti licenzia il software come OSS con copyleft forte (il che ne impedisce l'integrazione in software proprietario) e offre al contempo ai licenziatari interessati una licenza _a pagamento_ che consente loro di integrare il software nel proprio software proprietario. + +Poiché i licenziatari interessati possono così evitare di pubblicare il proprio software proprietario come OSS, sono disposti a pagare per la licenza. Cfr. anche l'allegato a link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale]. + +Per le autorità federali stesse la doppia licenza dovrebbe risultare poco interessante nella maggior parte dei casi. Fintanto che i diritti d'autore spettano alle autorità federali (il che è disciplinato per esempio dalle condizioni generali dell'Amministrazione federale), queste possono decidere da sole in merito a un'eventuale doppia licenza. + +Se la manutenzione e lo sviluppo (ulteriore) sono esternalizzati a terzi, la situazione può essere diversa. Se i diritti spettano eccezionalmente a questi ultimi e le autorità federali si sono riservate soltanto il diritto di concedere una licenza OSS con copyleft, il terzo potrebbe essere tentato di procedere a una doppia licenza. Se ciò deve essere impedito, dovrebbe essere escluso contrattualmente. + +=== Modifica successiva delle licenze + +Occorre anzitutto rilevare che le licenze OSS sono in linea di principio immutabili e irrevocabili. I licenziatari che hanno concluso il contratto di licenza _prima_ di una modifica possono continuare a utilizzare, modificare e trasmettere a terzi il codice sulla base della vecchia licenza. + +Nella pratica una modifica di licenza porta spesso a un fork di una nuova versione del software sotto la vecchia licenza, sviluppato autonomamente dai precedenti licenziatari. + +L'introduzione di una nuova licenza per un software è possibile soltanto se tutti i titolari dei diritti d'autore sul software vi acconsentono. Modifiche si sono verificate nella pratica, per esempio nel passaggio da una licenza permissiva a una licenza copyleft. + +=== Menzione dei contributori (collaboratori e terzi) + +Se un programma per computer è creato nell'ambito di un rapporto di lavoro, il datore di lavoro ottiene una licenza esclusiva per il suo utilizzo (art. 17 LDA). Ai lavoratori restano quindi essenzialmente soltanto i diritti morali sul software (ovvero, a seconda dell'opinione giuridica, soltanto il loro nucleo). Lo stesso vale per i terzi che sviluppano software per le autorità federali, purché si applichino le corrispondenti CGfootnote:[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] della Confederazione, che trasferiscono alle autorità federali i diritti che ne derivano. + +Si pone nondimeno la questione se i contributori (collaboratori, terzi) debbano avere il diritto o l'obbligo di farsi conoscere come autori dei contributi nei repository open source. + +Un argomento a favore dell'impiego dell'OSS da parte delle autorità federali è l'offerta di posti di lavoro attrattivi: l'OSS offre ai contributori la possibilità di mostrare pubblicamente le proprie conoscenze e di costruirsi così una reputazione. Le loro capacità diventano verificabili, sono attestate dai pari, e chi ha acquisito influenza in un progetto OSS può servirsene come leva nella ricerca di un impiego. + +Un ulteriore argomento potrebbero essere i diritti morali, il cui nucleo non può essere sottratto all'autore originario né per contratto né per legge. Tale nucleo è tuttavia ristretto per i programmi per computer; esigere che lo sviluppatore di un programma abbia anche un diritto alla menzione andrebbe probabilmente troppo oltre. + +Inoltre, uno scambio tra specialisti nella community presuppone che essi possano essere contattati individualmente da altri. + +A seconda del progetto può quindi essere opportuno dare ai contributori la possibilità di farsi conoscere come tali nella community. + +Sotto il profilo della protezione dei dati va evitata ogni costrizione in tal senso, fermo restando che lo scambio nella community non presuppone la divulgazione dei nomi — gli pseudonimi sono la regola più che l'eccezione. Se i contributori non desiderano divulgare il proprio nome, va quindi data loro la possibilità di apparire sotto pseudonimo. + +*Si raccomanda di menzionare i nomi degli sviluppatori nei commit, se il progetto non vi si oppone.* + +*In ogni caso le autorità federali dovrebbero agire in qualità di titolari dei diritti.* + +=== Diritto d'autore, licenze per l'IA generativa per la creazione di codice + +Ci riferiamo qui soltanto al codice creato mediante IA generativa. Ulteriori informazioni su questo tema figurano in link:em002-6.pdf[Em002-6 FAQ sull'OSS++*++, capitolo 2.2]. Il codice creato da un LLM non è esso stesso protetto dal diritto d'autore. I dati di addestramento utilizzati dall'LLM possono tuttavia essere protetti dal diritto d'autore. Se il codice corrisponde 1:1, andrebbe ripresa anche la licenza. Se il codice è stato creato a frammenti e poi modificato dagli sviluppatori, il rischio che sia considerato software derivato è ridotto. Va osservato che determinati LLM esigono che il codice sia contrassegnato di conseguenza; eventuali accordi contrattuali al riguardo devono essere rispettati. + +=== Contributor Licence Agreements (CLA) e Developer Certificate of Origin (DCO) + +Quando più autori lavorano al codice di un progetto open source, essi ottengono diritti comuni sul codice che ne risulta. + +La concessione in licenza del codice a terzi avviene mediante la licenza OSS, con la costituzione di un contratto di licenza distinto tra ciascun utente e ciascun autore (fascio di licenze). Questa costellazione può dar luogo a una situazione giuridica poco chiara, per esempio nei rapporti internazionali (cfr. 8.1 sopra). Quando le imprese decidono di porre il proprio software sotto licenza OSS e di accettare contributi di terzi, hanno talvolta l'esigenza di conservare un certo controllo sul codice. + +Così può essere interessante mantenere aperta la possibilità di porre il progetto sotto una nuova licenza, oppure si desidera sottoporre a doppia licenza codice licenziato copyleft e a tal fine occorrono più diritti di quanti se ne otterrebbero dai contributori mediante una semplice licenza OSS (cfr. 8.5 sopra). I Contributor Licence Agreements (talvolta anche Copyright Transfer Agreements) mirano a risolvere tali problemi. + +Un *Contributor Licence Agreement (CLA)* è un *accordo giuridicamente vincolante* che definisce le *condizioni applicabili ai contributi al progetto*. + +I contributori sono tenuti ad accettare tale accordo prima di poter apportare contenuti al progetto. In sostanza i contributori concedono al progetto e ai suoi utenti il diritto di *utilizzare, modificare e ridistribuire* i contributi apportati. Viene inoltre confermato che i contributi *sono stati redatti autonomamente o legittimati da terzi*. + +Il *Developer Certificate of Origin (DCO)* è un *sistema di verifica introdotto* dalla Linux Foundation nel 2004, simile nello scopo al Contributor Licence Agreement (CLA) e che costituisce uno strumento alternativo adeguato. I contributori confermano per ogni contributo al progetto che *(a) sono autorizzati ad apportare il contributo, (b) il contributo è coperto da una licenza compatibile con il progetto e (c) acconsentono alla diffusione e all'utilizzo del contributo come open source*. + +Lo strumento principale dei CLA è o la cessione dei diritti d'autore dai contributori allo sviluppatore principale o all'organizzazione promotrice (nel caso dei Copyright Transfer Agreements), oppure la concessione da parte dei contributori allo sviluppatore principale della licenza più ampia possibile, di regola irrevocabile (Apache ha p. es. definito un CLA). Anche i contributi a progetti chiusi sono spesso soggetti a un CLA. + +I CLA sono controversi nella community OSSfootnote:[Per esempio: https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/], tra l'altro perché possono aprire falle nel copyleft. Esistono quindi ormai anche CLA che limitano lo sviluppatore principale quanto alla concessione di una nuova licenza per il codice del progetto. + +[mermaid,align="center",alt="Trasferimento del codice sorgente e dei diritti in diverse costellazioni"] +.... +flowchart LR + subgraph TP["Terzi"] + TP1["nessun documento proprio"] + TP2["CLA
DCO
licenza OSS"] + TP3["CLA
DCO
licenza OSS
contratto"] + TP4["nessun documento proprio"] + end + subgraph FA["Amministrazione federale"] + FA1["CG della Confederazione
contratto"] + FA2["nessun documento proprio"] + FA3["licenza OSS
contratto
(DCO)
(CLA)"] + FA4["licenza OSS
(DCO)
(CLA)"] + end + TP1 -- "creazione" --> FA1 + TP2 -- "contributo dell'Amministrazione federale" --- FA2 + TP3 <-- "collaborazione" --> FA3 + TP4 -- "contributo di terzi" --> FA4 +.... + +Figura 4: Trasferimento del codice sorgente e dei diritti in diverse costellazioni + +Legenda: + +* I riquadri indicano *dove sono definiti i diritti* in ciascuna costellazione. +* *Creazione* e *contributo di terzi*: l'Amministrazione federale dispone del potere di configurazione. +* *Collaborazione*: i documenti sono concordati tra le parti. +* *Contributo dell'Amministrazione federale*: l'Amministrazione federale non dispone di alcun potere di configurazione, è necessario un esame. +* I documenti giuridici sono elencati in ordine di priorità, dall'alto verso il basso; i documenti tra parentesi sono piuttosto da evitare. + +Per gli *sviluppi propri* (creation) non vi sono problemi: secondo l'art. 17 LDA l'autorità federale è titolare dei diritti d'utilizzazione sul software creato dai propri collaboratori. Per gli *sviluppatori terzi* le autorità federali dovrebbero assicurarsi i diritti (per esempio utilizzando le corrispondenti CG della Confederazione). Nessun CLA o DCO è quindi qui necessario. + +Laddove le autorità federali sono sviluppatori principali e accettano contributi e collaborazioni, occorre rinunciare all'utilizzo di un CLA. Possono essere utilizzati in alternativa i Digital Certificates of Origin (illustrati con un esempio in link:em002-4.pdf[Em002-4 Guida alle community OSS], capitolo 3.3). In linea di principio i contributi ai progetti delle autorità federali dovrebbero basarsi sulla licenza OSS, per non innalzare ulteriormente la barriera al contributo. + +Se nel singolo caso, dopo adeguato esame, si constata comunque la necessità di un CLA, l'autorità federale dovrebbe utilizzare il CLA di Apache.footnote:[https://www.apache.org/licenses/contributor-agreements.html] In tal caso questa decisione e il CLA dovrebbero essere annotati nelle osservazioni conclusive tanto della link:em002-2-1-checklist-oss-preliminary-assessment.pdf[lista di controllo Em002-2.1 Valutazione preliminare] quanto della link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS]. + +Se le autorità federali contribuiscono a software di terzi che richiede un CLA, il servizio giuridico deve esaminare caso per caso se l'autorità federale possa accettare il CLA esistente.footnote:[Per un determinato destinatario l'Amministrazione federale dovrebbe esaminare la firma di un CLA una sola volta. In altre organizzazioni ciò è pertanto trattato come questione di alto livello, con i CLA firmati conservati nell'archivio dei contratti. I CLA non devono eludere gli obblighi dell'autorità federale ai sensi dell'art. 9 LMeCA.] Vanno determinati i punti seguenti: + +* Un'altra autorità federale ha già firmato il CLA? +* Chi esamina il CLA? +* Chi lo firma? (Il firmatario deve essere autorizzato a firmare per la Confederazione nei confronti di terzi) +* Dove viene archiviato? +* Come sono documentati il CLA o il DCO nel progetto? +* Come si garantisce che il codice pubblicato resti pubblicato? (Ciò resta di competenza dell'autorità federale ai sensi dell'art. 9 LMeCA, cfr. [KBB-MB].) + +Possibili criteri per l'esame sono: + +* Compatibilità con l'art. 9 LMeCA: il codice resta aperto? +* L'autorità federale ravvisa rischi per sé stessa? +* L'autorità federale ravvisa un beneficio per sé stessa (p. es. il codice non deve essere mantenuto o sviluppato da sola) o per altri (nel federalismo svizzero o a livello europeo si può ottenere un impatto più ampio senza oneri supplementari)? +* I diritti ceduti sono ragionevoli? +* All'autorità federale non sono imposti obblighi (superflui)? +* Il CLA è sostanzialmente equivalente al CLA di Apache? + +=== Problemi con la (L)GPL-3.0 e l'IoT + +_[BITKOM2023]_ segnala un problema legato all'uso delle licenze (L)GPL-3.0 in relazione al software installato su dispositivi: tali dispositivi dovrebbero consentire l'installazione di versioni software proprie o nuove. Ciò può essere indesiderato per motivi di sicurezza. + +=== Statuto giuridico della documentazione + +Secondo l'art. 5 LDA, «le decisioni, i verbali e i rapporti delle autorità e delle amministrazioni pubbliche» non sono protetti dal diritto d'autore. + +Ciò va oltre la CC-0, poiché il titolare dei diritti non deve destinare l'opera al pubblico dominio rinunciando a livello mondiale a tutti i diritti d'autore e di protezione affini. Essa è già di pubblico dominio per legge. Il messaggio concernente l'art. 5 LDA precisa: «La disposizione ammette tuttora la protezione del diritto d'autore per tutta una serie di opere nate dall'attività ufficiale o in relazione con essa. + +I documenti di commissioni di studio e gruppi di lavoro interni all'amministrazione, le perizie o le riviste degli uffici federali, per esempio, non rientrano nella norma. Alla loro libera diffusione non corrisponde un interesse preponderante, poiché esse non influenzano la posizione giuridica del cittadino.» + +Si può quindi sostenere che per molti dei documenti rilevanti e per la documentazione pubblicata dalle autorità federali in relazione al software open source non sussiste alcuna protezione del diritto d'autore. Il criterio è se il documento incida o meno sulla posizione giuridica del cittadino e sia quindi escluso dalla protezione del diritto d'autore. In caso contrario, per la documentazione andrebbe utilizzata una licenza adeguata (CC-0footnote:[https://www.creativecommons.ch/], CC-BY, CC-BY-SA o eventualmente LGPL). + +Ciononostante, in particolare in caso di utilizzo internazionale della documentazione, la situazione resterebbe poco chiara per molti utenti. + +Riteniamo pertanto opportuno che, come per il presente documento, sia indicata per sicurezza anche una corrispondente pubblicazione. + +== Ulteriori informazioni sulle questioni giuridiche + +Ulteriori informazioni sul software open source, sulle caratteristiche di licenze specifiche e su aspetti giuridici approfonditi figurano in numerose pubblicazioni, presentate qui di seguito (cfr. anche i riferimenti alla fine del documento). + +* Il testo _«Open Source Software im EMBAG, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben»_ di Rika Koch e Simon Schlauri, negli atti della Conferenza sugli acquisti informatici 2023 a Berna, offre orientamenti supplementari sull'attuazione dell'art. 9 LMeCA. +* Il _Leitfaden Open-Source-Software 2.0_ della BITKOM tedesca tratta in dettaglio le questioni giuridiche relative all'open source _[BITKOM2023]_. Esso si fonda tuttavia sulla situazione giuridica in Germania. +* Wolfgang Straub esamina, nel suo libro _Softwareschutz: Urheberrecht, Patentrecht, Open Source_, i dettagli giuridici del copyleft in relazione al diritto d'autore svizzero e approfondisce la compatibilità delle licenze open source [St2011]. Il capitolo sul software open source (nonché traduzioni tedesche di diverse licenze open source che tengono conto della terminologia giuridica svizzera) sono liberamente disponibili su _www.it-recht.ch._ +* Till Jaeger e Axel Metzger rispondono in modo approfondito a numerose questioni giuridiche relative al software open source nel loro ampio libro _Open Source Software - Rechtliche Rahmenbedingungen der Freien Software [JaAx2016]_. Essi fondano tuttavia la loro analisi sulla situazione giuridica in Germania. +* Kropp Jonathan/Bauer Alexander, Open Source Compliance und Litigation, CB 2019 pagg. 285 segg., 285. +* Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de «logiciels libres» (open source), SZW 2022 pag. 69 segg. + +Diversi portali online forniscono inoltre informazioni dettagliate sulle caratteristiche e sulle questioni relative a singole licenze open source. + +* Sulla piattaforma GitHub https://choosealicense.com è possibile selezionare gli obiettivi desiderati per un progetto open source e viene proposta la licenza open source adeguata. +* Su https://opensource.guide/legal/ GitHub mette a disposizione una guida online che affronta questioni giuridiche specifiche. +* Su https://www.gnu.org/licenses/license-list.it.html si trovano brevi commenti su diverse licenze con indicazioni sulla compatibilità, in particolare con la GPL. +* Su https://opensource.org/faq l'Open Source Initiative tratta numerose domande e risposte sugli aspetti giuridici delle licenze open source. +* Su https://copyleft.org/guide si trova una guida dettagliata che illustra i dettagli del copyleft. +* Su https://tldrlegal.com le principali licenze open source sono riassunte secondo ciò che la rispettiva licenza consente («can»), ciò che vieta («cannot») e ciò che prescrive («must»). +* Su https://opensource.com/tags/licensing sono pubblicati costantemente articoli su questioni attuali in materia di licenze. +* Su https://www.ifross.org/faq-haeufig-gestellte-fragen il privato «Institut für Rechtsfragen der Freien und Open Source Software» di Berlino (ifrOSS) ha pubblicato numerose risposte a domande giuridiche frequenti. + +Oggi il rispetto delle licenze open source è attuato in primo luogo mediante strumenti software (per ulteriori informazioni sulla conformità open source cfr. anche Fröhlich-Bleuler _[Fr2012]_ nonché Kuhn, Williamson e Sandler _[KuWiSa2008]_). Diversi strumenti open source della Linux Foundation sono così documentati e pubblicati sotto il termine «fossology» su https://www.fossology.org. Anche fornitori commerciali quali Black Duckfootnote:[https://www.blackducksoftware.com] o FOSSAfootnote:[https://fossa.com] offrono diverse soluzioni proprietarie con cui è possibile verificare la compatibilità delle licenze open source utilizzate. + +== Allegato + +=== Modifiche rispetto alla versione precedente + +* Aggiunto il riassunto per la direzione. +* Le licenze AGPL e MIT sono ora raccomandate come preferibili. +* Nuovo nel capitolo 8.8: diritto d'autore per il codice generato con l'IA. +* Capitolo 8.9 CLA e CDO fortemente ampliato. +* Diversi miglioramenti redazionali e precisazioni. +* Aggiunti più esempi. + +=== Riferimenti + +Cfr. link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale]. + +=== Abbreviazioni + +Cfr. link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] ed link:em002-6.pdf[Em002-6 FAQ sull'OSS]. + +=== Esempi di pubblicazioni e relative licenze + +In futuro questo elenco sarà sostituito da una raccolta di metadati mediante publiccode.yml. + +=== D.1 Loom + +URL:: +https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom +Autorità federale:: +Cyber Command +Descrizione:: +Loom è un motore di ricerca documentale potente e di facile utilizzo. Automatizza l'indicizzazione delle fonti di dati configurate, esegue l'OCR, estrae contenuti e metadati, consente il tagging e offre potenti funzioni di ricerca e di utilizzo. +Anno:: +2025 +Licenza:: +MIT +Motivazione:: +- + +=== D.2 trustbroker.swiss + +URL:: +https://github.com/trustbroker-swiss/trustbroker.swiss +Autorità federale:: +CaF, UFIT +Descrizione:: +Trust Broker Swiss fornisce servizi di federazione tra relying party (applicazioni, fornitori di servizi, altri sistemi IAM o policy enforcement point) e fornitori di identità (IdP, detti anche claims provider), ricorrendo ad archivi di attributi affidabili per arricchire gli utenti autenticati. + +Consente a fornitori di identità/claims e a relying party di scambiare informazioni tramite un terzo che nasconde le specificità dell'IdP e fornisce un'identità unificata o quantomeno ulteriormente verificata. +Anno:: +2024 +Licenza:: +AGPL +Motivazione:: +Le modifiche del codice devono sempre restare aperte e ritornare al progetto. ++ +Per il Trust Broker è stato svolto un esame molto dettagliato della questione della licenza. Per progetti molto grandi esso può essere condotto a questo livello di dettaglio. Tutte le licenze compatibili con la software bill of materials sono state elencate in un pool di licenze. + +=== D.3 Geocat.ch + +URL:: +https://github.com/geonetwork/core-geonetwork +Autorità federale:: +Swisstopo +Descrizione:: +GeoNetwork è un'applicazione di catalogo per la gestione di risorse georeferenziate. Offre potenti funzioni di editing e ricerca di metadati nonché un visualizzatore di mappe web interattivo. È attualmente impiegata in numerose iniziative di infrastrutture di dati territoriali in tutto il mondo. +Anno:: +2012 +Licenza:: +GPL 2.0 +Motivazione:: +- + +=== D.4 GWEN / ampycloud / c4dl-multi / dvas /… + +URL:: +https://meteoswiss.github.io/ampycloud/ +Autorità federale:: +MeteoSvizzera +Descrizione:: +Pacchetto Python per determinare la percentuale di copertura del cielo e l'altezza di base degli strati nuvolosi a partire da dati di ceilometro. +Anno:: +2023 +Licenza:: +Diverse licenze, FSS +Motivazione:: +- + +=== D.5 Applicazione EMSG (gestione del patrimonio nelle aree insediative) + +URL:: +https://github.com/astra-emsg/ASTRA.EMSG +Autorità federale:: +MeteoSvizzera +Descrizione:: +EMSG è un'applicazione web GIS in C# sviluppata dall'Amministrazione federale svizzera per gestire la gestione del patrimonio dei sistemi stradali urbani. +Anno:: +2017 +Licenza:: +BSD +Motivazione:: +- + +=== D.6 Applicazione certificato Covid + +URL:: +https://github.com/admin-ch/CovidCertificate-Documents +Autorità federale:: +UFIT +Descrizione:: +Applicazione svizzera per i certificati COVID +Anno:: +2020 +Licenza:: +MIT +Motivazione:: +Il più permissiva possibile, affinché chiunque possa utilizzare il codice. + +=== D.7 Sito web GovCert + +URL:: +https://github.com/govcert-ch/website +Autorità federale:: +NCSC +Descrizione:: +Codice sorgente del sito web del Computer Emergency Response Team (GovCERT) dell'Amministrazione federale svizzera +Anno:: +2023 +Licenza:: +MIT +Motivazione:: +- + +=== D.8 Diverse librerie sugli open data (p. es. linked data) + +URL:: +https://github.com/SwissFederalArchives +Autorità federale:: +AFS +Descrizione:: +Il repository dell'Archivio federale svizzero su GitHub offre accesso ai codici sorgente delle nostre applicazioni. Consente di creare fork propri e di segnalare errori o proporre funzionalità ampliate tramite l'interfaccia «Issues». +Anno:: +2023 +Licenza:: +AGPL, Apache, MIT +Motivazione:: +Open data e software open source vanno nella stessa direzione. La AGPL consente la massima apertura. + +=== D.9 Apache FOP adattato per PDF archiviabili + +URL:: +https://xmlgraphics.apache.org/fop/ +Autorità federale:: +IPI +Descrizione:: +L'IPI desiderava una versione di Apache FOP in grado di generare PDF archiviabili. A tal fine è stata commissionata un'estensione a uno degli sviluppatori principali (Jeremias Märki). Gli adattamenti sono confluiti direttamente nel progetto. +Anno:: +2007 +Licenza:: +Apache +Motivazione:: +Sono state apportate estensioni a un progetto open source esistente. + +=== D.10 Deposito elettronico conforme al diritto con eKomm + +URL:: +https://launchpad.net/ekomm +Autorità federale:: +IPI +Descrizione:: +L'IPI desiderava un software per il deposito elettronico. +Anno:: +2009 +Licenza:: +Apache +Motivazione:: +L'IPI desiderava che il fornitore (Glue) effettuasse la pubblicazione e l'ha autorizzata in modo permissivo (integrazione nelle proprie applicazioni). +endif::[] + +ifeval::["{lang}" == "rm"] +*Exclusiun da responsabladad:* 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 {url-repo}/tree/main[README]. + +''''' + +== Resumaziun per la direcziun + +I vegn recumandà da fixar strategicamain en l'administraziun federala tar il cumenzament d'in project ina da las duas suandantas licenzas: + +* *Licenza AGPL*: Effect copyleft giavischà. Code midà duai en mintga cas returnar a la generalitad e po lura vegnir surpiglià danovamain er da l'administraziun federala. I vegn recumandà d'utilisar la versiun la pli nova da la licenza. Uschia sa lascha ademplir il meglier il princip «public money – public code». Dretgs da terzas persunas, en spezial tar svilups vinavant, pon debilitar quai fin a la LGPL. +* *Licenza MIT*: A terzas persunas duai esser pussaivel da sviluppar applicaziuns proprietaras sin la basa dal code da l'administraziun federala. Sch'ina clausula da non-endorsement vegn pretendida expressivamain, è la BSD-3-Clause da preferir. + +Per la tscherna da la licenza po vegnir duvrà il suandant agid da decisiun: + +[mermaid,align="center",alt="Agid da decisiun simplifitgà per la tscherna da la licenza"] +.... +flowchart TD + S(["Entschatta"]) + Q1{"L'«ambient»
preschriva la licenza"} + A["Tscherner la licenza
preschritta"] + Q2{"Biblioteca, implementaziun da referenza
u pretensiuns liberalas"} + B["MIT"] + C["AGPL"] + S --> Q1 + Q1 -->|"Gea"| A + Q1 -->|"Na"| Q2 + Q2 -->|"Gea"| B + Q2 -->|"Na"| C +.... + +Illustraziun 1: Agid da decisiun simplifitgà per la tscherna da la licenza + +En tscherta dimensiun furman questas duas licenzas ils dus extrems en il spectrum da las licenzas OSS. I po tut tenor esser sensa da tscherner ina licenza pli adattada per in project concret. Questa guida duai porscher in agid concret per quai. + +Sche l'analisa da las bibliotecas da software mussa ch'ina autra licenza sto vegnir duvrada, fan ils sviluppaders attenta la direcziun dal project sin quai. L'analisa è exponida en link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source]. + +Tar la collavuraziun a projects existents èn fundamentalmain acceptablas tuttas licenzas cumpatiblas cun l'OSI. + +== Introducziun + +L'artitgel 9 da la lescha federala dals 17 da mars 2023footnote:[CS 172.019] davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG) prevesa che las autoritads federalas ston publitgar e licenziar sco software open source il software ch'ellas sviluppan u fan sviluppar. + +Quest document persequitescha las suandantas finamiras: + +* Introducziun en ils temas dal dretg d'autur sin software e da las licenzas OSS. +* Ina preschentaziun da las licenzas OSS ch'èn senza problems per il diever en l'administraziun federala. Licenzas betg numnadas en quest document e software sut talas licenzas na dastgan betg vegnir duvrads senza ina examinaziun supplementara da las disposiziuns contractualas tras il servetsch giuridic cumpetent. +* Sustegn tar la tscherna da la licenza per il svilup u l'acquist d'in project tenor l'art. 9 EMBAG. + +== Dretg d'autur e licenzas: basas + +Il dretg d'autur fundescha tant dretgs da la persunalitad sco er dretgs da facultad (dretgs d'exploataziun). Tar ils dretgs da la persunalitad appartegna per exempel il dretg a la renconuschientscha da l'autorstgadi u il dretg da determinar, sche e cura che l'ovra vegn publitgada. Tar ils dretgs d'exploataziun appartegna per exempel il dretg da produir u da derasar exemplars da l'ovra. + +La lescha federala dals 9 d'october 1992footnote:[CS 231.1] davart il dretg d'autur ed ils dretgs da protecziun parents (LDAu) prevesa ina retscha d'ulteriurs dretgs da la persunalitad e d'exploataziun (vesair art. 8 ss. LDAu). Quests dretgs appartegnan a l'autura u a l'autur directamain cun la creaziun da l'ovra. + +L'art. 2 LDAu fixescha, sut tge cundiziuns ch'ina protecziun dal dretg d'autur vegn concedida. In'ovra protegida en il senn da la lescha exista mo, sche questas cundiziuns èn ademplidas. + +Las cundiziuns èn: + +* L'ovra sto esser vegnida creada; il pur chattar na basta betg. Datas da perscrutaziun per exempel, pia resultats d'experiments, na sa laschan betg classifitgar sco ovras. +* La creaziun sto esser «spiertala», pia derivar d'in uman. +* L'ovra sto esser vegnida realisada en moda perceptibla. La pura idea davos in'ovra n'è betg protegida, mabain mo sia furma externa, p.ex. ina stampa d'in text sin palpiri u l'execuziun d'in toc da musica. +* Individualitad: Finalmain sto l'ovra avair in tschert minimum d'individualitad. In'ovra che mintgin concepiss il medem nun è betg protegida. + +I pon vegnir protegidas las ovras las pli differentas, sco texts litterars u scientifics, ovras musicalas, fotograficas, filmicas ed autras ovras visualas u audiovisualas. + +Tenor l'art. 2 al. 3 LDAu èn era programs da computer ovras, sche las cundiziuns menziunadas èn ademplidas. + +Ils dretgs d'autur appartegnan cun lur creaziun be a l'autura u a l'autur. Mo ella u el po scumandar ad ina autra persuna da far las acziuns correspundentas. L'autura u l'autur po dentant exercitar ses dretgs betg mo sezza u sez: + +* Ella u el po transferir ses dretgs a terzas persunas (p.ex. cun vender els). Il nov possessur dals dretgs po lura far valair quests dretgs il medem sco sche el fiss l'autur. +* Alternativamain po l'autura u l'autur era licenziar ses dretgs a terzas persunas. Simplifitgà è ina licenza in contract cun il qual il possessur dals dretgs permetta ad ina terza persuna d'utilisar l'ovra. L'autura u l'autur resta cun ils dretgs, ma renunzia a lur imposiziun vers il prenditur da licenza. + +Sch'in program da computer vegn creà en il rapport da lavur, survegn il patrun ina licenza exclusiva per ses diever (art. 17 LDAu). Als emploiads restan uschia en il fund mo ils dretgs da la persunalitad sin il software (resp. tut tenor l'opiniun giuridica mo lur zona centrala). Quai correspunda a la situaziun giuridica tenor la lescha davart il persunal federal. + +== Licenzas OSS + +=== Basas + +L'OSS sa caracterisescha en il fund tras las suandantas caracteristicas (tenor ina definiziun da l'Open Source Initiative _[Pe1999]_footnote:[https://opensource.org/]): + +* La derasaziun vinavant illimitada e gratuita dal software è permessa; +* Il software è avant maun en il code da funtauna; +* Midadas al software e lur derasaziun vinavant sut la medema licenza èn fundamentalmain permessas; +* Naginas persunas u gruppas da persunas na dastgan vegnir excludidas da l'utilisaziun dal software, e nagins secturs d'applicaziun na dastgan vegnir exclus (en spezial betg l'utilisaziun commerziala); e +* La derasaziun dal software ensemen cun auter software (sco software closed source) na dastga betg vegnir restrenschida. + +Ils motivs ils pli frequents per il diever da l'OSS èn en emprima lingia las spargnas da custs tras l'utilisaziun dal pool gia considerabel da software liberamain utilisabel. Interpresas che duvran savens OSS pon savens spargnar parts considerablas da lur budget informatic tras il diever da l'OSS. + +Code disponibel libramain sa lascha ultra da quai adattar facilmain als agens basegns. Plinavant evitescha la tscherna da l'OSS in vendor lock-in.footnote:[https://de.wikipedia.org/wiki/Lock-in-Effekt] + +=== Licenzas open source + +Licenzas open source èn en emprima lingia contracts da licenza normals per programs da computer. + +Cuntrari als contracts da licenza normals vegnan ils contracts da licenza OSS dentant a maun senza ulteriur, uschespert che mo ina da las furmas libras d'utilisaziun descrittas en la licenza vegn exercitada (per exempel cun copiar, derasar vinavant u midar software). + +=== Copyleft versus permissiv + +==== En general + +Ina licenza open source tenor l'OSI po cuntegnair ina disposiziun da «copyleft». Midadas a software licenzià correspundentamain ston vegnir purschidas puspè sut las medemas cundiziuns che valevan per il software original. Tgi che fa talas midadas sto, tar la derasaziun dal software open source en furma da code d'object legibel per maschinas, era purscher als recepients il code da funtauna. + +En la formulaziun da la Free Software Foundation protegia l'effect copyleft la libertad dals sviluppaders e garantescha uschia ch'in software ina giada liber resta adina liber. + +Tar licenzas copyleft ha lieu ina sort barat tranter la communitad e las interpresas che utiliseschan. Ils utilisaders, ch'èn obligads en cuntrachamb per ils avantatgs dal pool da software existent da metter lur agens svilups puspè sut la respectiva licenza, contribueschan uschia al svilup vinavant dal pool da software. En il resultat profitan omaduas varts. + +La disposiziun da copyleft ha in tschert «effect da contagiun»: Sche software licenzià copyleft vegn integrà en software ch'era fin qua proprietar, sto il software originalmain proprietar vegnir publitgà sut ina licenza open source cumpatibla. + +Tar il diever da code da funtauna licenzià copyleft sto perquai vegnir fatg adatg da l'integrar mo là, nua che il software resultant po e duai vegnir publitgà sut ina licenza open source. + +Sch'ina licenza open source na cuntegna nagina disposiziun da copyleft (licenza open source permissiva), po la licenza per versiuns reelavuradas dal code vegnir tschernida libramain. En spezial è era pussaivel da metter midadas puspè sut ina licenza da software proprietara e d'integrar il code da funtauna correspundent en software proprietar. + +En il fund sa laschan las licenzas open source repartir en *las suandantas categorias*: + +. licenzas open source cun *copyleft ferm*; +. licenzas open source cun *copyleft flaivel*; e +. licenzas open source *permissivas* resp. *senza copyleft*. + +==== Licenzas open source cun copyleft ferm + +Tar l'utilisaziun d'ina licenza open source cun copyleft ferm ston novas versiuns derivadas dal software original, sch'ellas vegnan dadas vinavant a terzas persunas, vegnir mess sut las cundiziuns da la licenza originala e vegnir messas a disposiziun a questas terzas persunas sco code da funtauna. + +Sco licenzas open source relevantas cun copyleft ferm valan sin il martgà las duas suandantas: + +* GNU General Public Licence (GPL); ina gronda part da l'OSS è oz licenziada sut ella +* GNU Affero General Public Licence (AGPL) + +La differenza principala tranter GPL ed AGPL pertutga il gener d'utilisaziun che chaschuna il copyleft. Tar software sut GPL sto il code da funtauna midà mo vegnir purschì, sche la nova versiun dal software vegn purschida a terzas persunas sco program exequibel (p.ex. sco app mobila). Sche il software vegn mo mess a disposiziun via l'internet (dal agen cloud da agens servers), per exempel en furma da «Software as a Service» (SaaS) u d'ina interfatscha da programmaziun (API), na chaschuna quai nagin copyleft. + +Sche il software stat sut l'AGPL, sto il code da funtauna midà era vegnir furnì, sche la funcziunalitad dal software vegn purschida via ina pagina d'internet u ina interfatscha da programmaziun. L'AGPL è uschia anc pli stretga che la GPL. + +Tar licenzas cun copyleft ferm pertutga il copyleft betg mo il respectiv modul da software (biblioteca), mabain l'entir program da software, en il qual in modul da software licenzià copyleft po esser integrà. L'«effect da contagiun» menziunà grippa uschia. + +==== Licenzas open source cun copyleft flaivel + +Era licenzas cun copyleft flaivel pretendan che midadas a lur code da funtauna vegnian relaschadas als recepients terzs sut la licenza open source originala. + +Cuntrari a las licenzas cun copyleft ferm n'effectueschan ellas dentant betg che autras cumponentas da software delimitablas (autras bibliotecas u il program principal sez) vegnian «infectadas» cun lur licenza. Quai permetta l'integraziun da software open source cun copyleft flaivel en software proprietar u en software cun autras licenzas OSS, senza stuair il relaschar sut la licenza originala. + +Quai èn las licenzas open source cun copyleft flaivel las pli duvradas: + +* GNU Lesser General Public Licence (LGPL) +* Mozilla Public Licence 2.0 (MPL) +* Common Development and Distribution Licence (CDDL) +* Eclipse Public Licence (EPL)footnote:[Ultra da la Eclipse Public Licence (EPL-1.0) datti era la Eclipse Distribution Licence (EDL-1.0). + +Entant che l'EDL correspunda a la BSD-3-Clause, è l'EPL ina licenza cun copyleft flaivel.] +* Microsoft Reciprocal Licence (Ms-RL) +* European Union Public Licence (EUPL)footnote:[L'EUPL sezza ha in copyleft ferm, ma pervia da la clausula d'avertura è in transiziun a licenzas cun copyleft flaivel pussaivel, uschia che la protecziun è limitada.] + +==== Licenzas open source permissivas + +Licenzas senza effect copyleft sa caracteriseschan tras il fatg ch'ellas na fan naginas prescripziuns als prenditurs da licenza concernent la licenziaziun da lur software derivà e che perquai ni lur nov code da funtauna ni midadas al software open source ston vegnir publitgads als recepients terzs. Quai pussibilitescha il svilup da products da software proprietars tras l'integraziun da software sut licenzas open source permissivas. + +Exempels da licenzas permissivas èn: + +* MIT Licence +* Apache Licence 2.0 +* Berkeley Software Distribution (BSD) Licence (BSD 2-Clause e BSD 3-Clause) +* Microsoft Public Licence (Ms-PL) + +=== Cumpatibilitad da licenzas open source + +Programs consistan da regla d'ina multiplitad da cumponentas e moduls da software che pon esser colliads in cun l'auter en modas differentas. En il svilup da software vegnan cumponentas open source existentas savens integradas en applicaziuns e soluziuns internas proprietaras. Uschespert che quellas daventan accessiblas da ordaifer via ina pagina d'internet, APIs, distribuziun da software u en autra moda, sto vegnir fatg adatg sin la cumpatibilitad da las respectivas licenzas open source, perquai che lura po il copyleft grippar. + +Sche ovras derivadas che stattan sut ina tscherta licenza dastgan mo vegnir derasadas sut las medemas cundiziuns da licenza, ha quai per consequenza ch'autras licenzas open source cun autras u cuntradictorias obligaziuns da licenza per ovras derivadas na pon betg vegnir duvradas. + +Tschertas licenzas open source cuntegnan uschenumnadas clausulas d'avertura che permettan l'utilisaziun dal code licenzià sut ellas en projects che stattan sut autras licenzas. Uschia permetta per exempel la LGPL, versiun 2.1, era l'utilisaziun dal code sut la GPL. La GPLv3 cuntegna tranter auter ina clausula da cumpatibilitad per l'AGPL e la Apache License 2.0. L'EUPL è concepida fitg avertamain e cuntegna en l'agiunta ina lunga glista da licenzas cumpatiblas, en spezial talas cun copyleft flaivel sco la LGPL. Quai ha per consequenza che la protecziun copyleft ferma previsa en la licenza vegn indirectamain debilitada. + +La grafica suandanta represchenta las dependenzas da las licenzas open source las pli impurtantas (Goldstein 2018). La represchentaziun sa basa sin la visualisaziun da David A. Wheeler ch'ha analisà las cumpatibilitads da las differentas licenzas e da lur numers da versiun (Wheeler 2007), ed è vegnida sviluppada vinavant ensemen cun indicaziuns da https://www.gnu.org/licenses/license-list.de.html[https://www.gnu.org/licenses/license-list.de.html].footnote:[Ina ulteriura represchentaziun, ampliada, vegn duvrada da GEANT en ses 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. Là sa chattan intginas licenzas supplementaras.] + +La grafica sto vegnir legida uschia: Code tenor ina licenza inditgada pli baud en la chadaina po vegnir surpiglià en software che vegn publitgà sut ina licenza inditgada pli tard en la chadaina. Uschia po per exempel code sut la BSD modifitgada vegnir mess sut ina varianta da licenza LGPL u GPL, ma betg il cuntrari. Public domain munta che l'ovra na suttastat a naginas restricziuns dal dretg d'autur. + +[mermaid,align="center",alt="Cumpatibilitad da licenzas open source"] +.... +flowchart TB + subgraph P["Licenza permissiva"] + PD["Public domain"] + MIT["MIT/X11"] + BSD["BSD modifitgada"] + AP["Apache 2.0"] + end + subgraph W["Copyleft flaivel"] + EUPL["EUPL"] + LGPL21["LGPLv2.1"] + LGPL21P["LGPLv2.1+"] + LGPL3["LGPLv3 / LGPLv3.1"] + MPL["MPL 1.1"] + end + subgraph SC["Copyleft ferm"] + GPL2["GPLv2"] + GPL2P["GPLv2+"] + GPL3["GPLv3 / GPLv3+"] + AGPL["Affero GPLv3"] + end + PD --> MIT + MIT --> BSD + BSD --> AP + BSD --> LGPL21 + BSD --> LGPL21P + BSD --> LGPL3 + BSD --> MPL + AP --> EUPL + AP --> LGPL3 + EUPL --> LGPL21 + EUPL --> LGPL21P + EUPL --> LGPL3 + EUPL --> MPL + LGPL21P --> LGPL21 + LGPL21P --> LGPL3 + LGPL21 --> GPL2 + LGPL21 --> GPL2P + LGPL21P --> GPL2P + LGPL3 --> GPL3 + GPL2P --> GPL2 + GPL2P --> GPL3 + GPL3 -->|"+ protecziun da la rait"| AGPL + classDef pd fill:#f5f5f5,stroke:#000000,color:#000000 + classDef perm fill:#dae8fc,stroke:#000000,color:#000000 + classDef weak fill:#d5e8d4,stroke:#000000,color:#000000 + classDef strong fill:#5ea226,stroke:#000000,color:#ffffff + class PD pd + class MIT,BSD,AP perm + class EUPL,LGPL21,LGPL21P,LGPL3,MPL weak + class GPL2,GPL2P,GPL3,AGPL strong +.... + +Illustraziun 2: Cumpatibilitad da licenzas open source (en adherenza a la grafica da David A. Wheeler, 2007 ed a https://www.gnu.org/licenses/license-list.de.html) + +Impurtant: Perquai che cumpatibilitads da licenzas èn adina relevantas, duessan ils teams da svilup resp. ils purschiders da prestaziuns examinar anticipadamain ils stacks da svilup cun bibliotecas concernent eventuals problems da cumpatibilitad. Quai munta: Avant che laschar passar il diever d'ina biblioteca, duess vegnir examinà – ultra da la segirezza e da l'omogeneitad en il stack da svilup – sche la licenza da la biblioteca è cumpatibla cun las licenzas relevantas preferidas da l'administraziun federala. + +[[licences-for-pure-usage]] +== Licenzas per la pura utilisaziun + +Quest chapitel tracta la situaziun, en la quala software sut ina licenza OSS duai vegnir duvrà, ma quest software na duai betg vegnir midà u en la quala midadas vegnan duvradas mo internamain. + +Las suandantas licenzas èn fundamentalmain senza problems tar l'utilisaziun da software tras autoritads federalas. Las cundiziuns correspundentas, numnadamain in eventual copyleft, ston dentant vegnir observadas. + +Sut tschertas circumstanzas determinescha la licenza d'in modul da software gia existent las licenzas pussaivlas per il product entir (vesair chapitel 4.4). + +Tschertas licenzas èn incumpatiblas en cumbinaziun (vesair illustraziun 2). + +[cols="1,1,3",options="header"] +|=== +|Licenza |Copyleft |Particularitads + +|*MIT* +|Na +|Licenza preferida da l'administraziun federala, sch'ina derasaziun vinavant vegn aspirada e sch'i duai vegnir permess a terzas persunas da sviluppar puspè software proprietar da quai. + +|*Apache 2.0* +|Na +|Apache è ina licenza fitg derasada, enconuschenta tras ils projects sut l'Apache Foundation. L'utilisaziun da las marcas dals dadis da licenza è excludida, ordaifer per descriver l'ovra. + +|*GPL v3* +|Gea +a|Quai è LA licenza copyleft classica. + +Il copyleft vala era, sche parts licenziadas GPL vegnan integradas en in program entir. Scumond dal digital rights management. Reglas da cumpatibilitad spezialas. + +|*LGPLv3* +|Flaivel +a|Licenza copyleft reducida, sviluppada spezialmain per bibliotecas da software. + +Cuntrari a la GPL permetta la LGPL da cumbinar sut tschertas cundiziuns code serrà (pia proprietar) cun code LGPL. + +Exempels èn bibliotecas standard sco glibc. La LGPL permetta da metter sut la GPL il program sco part dal qual la biblioteca vegn derasada. + +|*Affero GPLv3 (AGPL)* +|Gea +a|Era l'utilisaziun SaaS chaschuna copyleft. Dal reminent analog a la GPLv3. + +Questa licenza serra la largia da la GPL che manava a quai che nagina relaschada n'era necessaria tar l'utilisaziun per purschidas SaaS. + +Cun questa licenza po l'administraziun federala garantir che extensiuns dal code vegnian era a bun a la generalitad en cas da SaaS, e sustegna il meglier il princip *«public money – public code»*. + +|*BSD-3* +|Na +a|Licenza generala e liberala. + +Ils nums da las auturas e dals auturs na dastgan betg vegnir duvrads per far reclama per ovras derivadas (clausula da reclama) + +|*European Union Public Licence (EUPL)* +|Flaivel +a|Licenza speziala che vegn duvrada per l'UE. + +Spezialmain adattada sco basa per projects europeics. + +Licenza resguardond il dretg europeic. La relaschada sut tschertas licenzas cumpatiblas è expressivamain permessa. +|=== + +Tabella 1: Licenzas senza problems per las autoritads federalas (tenor _[Sc2024]_) + +Autras licenzas dastgan vegnir duvradas. En quests cas po esser necessari da consultar il servetsch giuridic da l'uffizi respectiv. + +== Licenza per agens projects resp. creation e per contributions + +Quest chapitel pertutga ils suandants cas: + +* Svilup vinavant / contribution +** tar il qual autoritads federalas sviluppan vinavant software existent; u +** sviluppan nov software, sa basond dentant sin bibliotecas da software OSS existentas; e +** mettan il software correspundent a disposiziun a terzas persunas. Tar las terzas persunas appartegnan era organisaziuns da l'administraziun federala decentralisada, uschenavant ch'ellas han ina atgna persunalitad giuridica. Sche ils svilups vinavant vegnan duvrads mo internamain e betg mess a disposiziun a terzas persunas, vala mo <>. +* Agens projects / creation / publicaziun: Quest chapitel pertutga cas, en ils quals las autoritads federalas sviluppan nov software. Quai duess esser rar, perquai che la gronda part dals svilups sa basa sin bibliotecas da software open source existentas. ++ +Per svilups cumplettamain novs duess vegnir tschernì in tip da licenza che pussibilitescha ina basa vasta e persistenta per svilups vinavant. Impurtant è che la licenza pertutgada saja acceptada amplamain en la communitad da sviluppaders relevanta. + +L'examinaziun da la cumpatibilitad ha lieu tenor link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS], chapitel 7.4. La cumpatibilitad da las licenzas mussa l'illustraziun 2. + +Las suandantas dimensiuns duessan vegnir resguardadas: + +* Cas d'applicaziun +* Examinaziun giavischada link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Glista da controlla Evaluaziun preliminara OSS] +* Simplitad da la construcziun d'ina communitad link:em002-4.pdf[Em002-4 Guida da communitads OSS] +* Simplitad da l'applicaziun +* Segirezza giuridica +* Derasaziun + +Licenzas tenor il chapitel <> èn da preferir. + +Las suandantas *licenzas copyleft* duessan vegnir duvradas prioritarmain da las autoritads federalas, en spezial sch'in svilup avert e persistent vegn aspirà e sche l'effect copyleft ch'erediescha duai valair. Uschia vegn garantì che software pajà da la publicitad e tut ses derivats restian averts. Quai adempla il meglier il princip «*public money – public code*» ed è *la recumandaziun preferida per l'administraziun federala.* + +Licenzas recumandadas en successiun decreschenta: + +* *AGPL v3* +* GPL v3 +* LGPL 3.0 +* European Union Public Licence (EUPL) + +Las suandantas licenzas duessan vegnir duvradas da las autoritads federalas, sche *nagin copyleft n'è giavischà* u necessari (en successiun decreschenta): + +* *MIT* +* Apache Licence 2.0 +* BSD v3 + +Tar la collavuraziun a projects existents pon ultra da quai vegnir duvradas senza problems las suandantas licenzas: + +* Mozilla Public Licence +* Microsoft Public Licence + +Sch'ina autra licenza duai vegnir duvrada, vegn recumandà da motivar quai curtamain en la link:em002-2-3-checklist-oss-release-and-publication.pdf[glista da controlla Em002-2.3 Relaschada e publicaziun OSS]. + +*Tenor l'art. 9 al. 4 EMBAG duessan en mintga cas vegnir duvradas licenzas stabilidas internaziunalmain.* + +Ulteriurs utensilis per examinar las cumpatibilitads da licenzas èn: + +* ORT Toolkit (https://oss-review-toolkit.org/) +* Black Duck (www.blackducksoftware.com), +* FOSSA (http://www.fossa.com[www.fossa.com]), +* l'Open Source Licence Comparison Grid (https://www.cmu.edu/cttec/forms/opensourcelicensegridv1.pdf) +* FOSSology (https://www.fossology.org). +* Process OpenCode: https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses#4.-Lizenzierungsleitfragen[https://opencode.de/en/knowledge/general-conditions/standardised-open-source-licenses] + +== Cas d'applicaziun e licenzas adattadas + +La tabella e la grafica suandantas mussan, co che sin la basa da differents cas d'applicaziun pon vegnir tschernidas licenzas adattadas per software open source. + +[cols="2,2,3",options="header"] +|=== +|*Cas d'applicaziun* |*Licenza/as* |*Motivaziun* + +|Utilisar in project existent e contribuir ad el +|*Licenza tenor la prescripziun dal project* +|Necessari per motivs giuridics. + +|La licenza è predefinida tras l'utilisaziun da parts existentas (licenzas cun copyleft) +|*Utilisar ina licenza cumpatibla cun questas parts.* +a|Necessari per motivs giuridics. + +Indicaziun: Ina retscha da bibliotecas è disponibla sut pliras licenzas. + +Mo ina da las licenzas sto correspunder. In dals intents da la licenziaziun multipla è da garantir che bibliotecas possian vegnir duvradas tant cun sco era senza copyleft. + +|Ecosistem existent cun licenza preferida (p.ex. i sa tracta d'in plug-in per software publitgà sut licenza MIT. Lura fiss l'utilisaziun d'ina licenza MIT il pli sensa, perquai che tut ils auters utilisaders spetgan quai e perquai che il software s'integrescha en l'ecosistem) +|*Utilisar la licenza, sch'ella stat sin la glista, uschiglio utilisar sche pussaivel la medema licenza* +|L'acceptanza en la communitad è centrala. + +|La finamira è ina derasaziun uschè vasta sco pussaivel, p.ex. tar ina implementaziun da referenzafootnote:[Per render per exempel ina lescha pli facil da realisar, po ina implementaziun da referenza vegnir dada en incumbensa da las autoritads federalas. Vesair p.ex. https://ech.ch/de/ech/ech-0238/1.0] (p.ex. tar software che duai era vegnir duvrà en soluziuns commerzialas). +a|*MIT* + +BSD v3 + +Apache Licence 2.0 + +LGPL v3 +|En quest cas na duess vegnir duvrà nagin copyleft. + +|Midadas al code duain returnar a las autoritads federalas +a|*AGPL v.3* + +GNU GPL v.3 + +EUPL +|L'AGPL sforza la relaschada tras terzas persunas era tar l'utilisaziun en il cloud, la GPL e l'EUPL betg. + +|Soluziuns SaaS na duain betg esser exceptadas dal returnar da midadas dal code +|*AGPL v.3* +|L'AGPL sforza la relaschada tras terzas persunas era tar l'utilisaziun en il cloud. + +|Ina collavuraziun simpla cun la communitad è impurtanta. +a|*AGPL v.3* + +GNU GPL v3 + +Apache Licence 2.0 +a|La GPL vegn preferida per mantegnair liber il software. + +Apache cuntegna reglas per la governanza da la communitad, reglas supplementaras per contribuziuns (ins na dastga inditgar nagina autra licenza che Apache; la contribuziun sco tala n'è betg reglada pli detagliadamain, sch'i exista in CLA, va quel avant), ina licenza da patent sco er reglas per la licenziaziun da patents. En spezial era che tgi che fa valair patents cunter in'autra persuna contribuenta perda sia licenza da patent sut la licenza Apache. + +Determinantas èn las reglas che l'Apache Foundation fixescha per contribuziuns. Apache è perquai sensa, sche la governanza dal project duai vegnir construida en emprima lingia tenor Apache. + +|Pitschna cumponenta (biblioteca) utilisabla universalmain u pitschen toc da software, tar il qual la persistenza u la tgira tras ina communitad n'è betg impurtanta +a|*MIT* + +Apache Licence 2.0 + +BSD v3 + +LGPL v3 +a|La LGPL prevesa in copyleft mo per la cumponenta sezza, ma betg per l'entir project, en il qual la cumponenta vegn inserida. + +Las autras licenzas èn permissivas. + +|I sto esser simpel e permissiv; la controlla n'è betg impurtanta +a|*MIT* + +Apache Licence 2.0 + +BSD v3 +|Maximalmain permissiv + +|Igl è impurtant per las autoritads federalas, tge ch'arriva cun il code, ed ellas vulan survegnir uschè bleras meglieraziuns sco pussaivel. +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|I duai vegnir impedì che il software daventia proprietar e vegnia posiziunà sin il martgà sco product da concurrenza +a|*AGPL v.3* + +GNU GPLv3 +|Copyleft + +|I duai vegnir impedì che las autoritads federalas daventian dependentas da singuls furniturs («vendor lock-in») +a|*AGPL v.3* + +GNU GPLv3 +|Il copyleft impedescha ch'in furnitur obtegnia cun il temp ina posiziun exclusiva cun utilisar il software da la Confederaziun en in product proprietar, quai che pudess puspè manar per la Confederaziun ad ina dependenza da quest furnitur. +|=== + +Tabella 2: Licenza da duvrar tut tenor il cas d'applicaziun per la relaschada da nov software tenor l'art. 9 EMBAG *(grass = recumandà, sche nagins motivs na s'opponan)* + +[mermaid,align="center",alt="Planta da decisiun ampliada per la tscherna da la licenza en l'administraziun federala"] +.... +flowchart TD + S(["Entschatta"]) + Q1{"Preschriva la glista da parts
la licenza?"} + R1["Tscherner la licenza
preschritta / preferida"] + Q2{"Dat i licenzas preferidas
en quest ambient?"} + Q3{"En la glista da licenzas
adattadas en l'Em002-3?"} + R2["Tscherner da la glista la proxima licenza
adattada tenor l'Em002-3, suenter
consultaziun dal servetsch giuridic"] + Q4{"Implementaziun da referenza
sco proposta
per terzas persunas?"} + R3["GPL u licenza permissiva:
MIT, BSD, Apache"] + Q5{"Ston meglieraziuns
turnar enavos?"} + Q6{"Era tar l'utilisaziun SaaS?"} + R4["GPL, EUPL"] + R5["AGPL"] + S --> Q1 + Q1 -->|"Gea"| R1 + Q1 -->|"Na"| Q2 + Q2 -->|"Gea"| Q3 + Q2 -->|"Na"| Q4 + Q3 -->|"Gea"| R1 + Q3 -->|"Na"| R2 + Q4 -->|"Gea"| R3 + Q4 -->|"Na"| Q5 + Q5 -->|"Na"| R3 + Q5 -->|"Gea"| Q6 + Q6 -->|"Na"| R4 + Q6 -->|"Gea"| R5 +.... + +Illustraziun 3: Planta da decisiun ampliada per la tscherna da la licenza en l'administraziun federala (sche betg AGPL u MIT) + +La glista da parts en l'illustraziun 3 è la software bill of materials (SBOM) da tuttas bibliotecas da software e da tut ils suttaprograms gia existents ch'èn fluids en la soluziun entira. Mintga biblioteca ha sia atgna licenza. Tut tenor co che quella è cumpatibla cun autras (vesair chapitel 4.4), è la tscherna pussaivla da licenzas per la publicaziun restrenschida. + +In ultim punct po era influenzar la decisiun: *La midada d'ina licenza pli restrictiva ad ina main restrictiva è pli simpla posteriuramain*. En il cas cuntrari è in forkfootnote:[Per la definiziun vesair link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala].] bunamain nunevitabel. + +== Temas giuridics particulars + +=== Aspects internaziunals + +Las dumondas giuridicas essenzialas da l'OSS en la pratica èn surtut da natira contractuala en il sectur da las licenzas. + +Tar dumondas dal dretg da licenzas vala l'emprim il dretg tschernì da las partidas (la Mozilla Public License MPL cuntegna per exempel en la cifra 8 ina tscherna dal dretg a favur dal dretg da la partida accusada). + +Sch'ina tscherna dal dretg manca, quai ch'è il cas tar tuttas autras licenzas preschentadas qua, vala da regla il dretg dal stadi da la partida che dat la licenza. Sche las autoritads federalas licenzieschan pia software da dadis da licenza a l'exteriur, vala il dretg dal pajais respectiv. Sche plirs contribuents èn participads, po quai manar a situaziuns cumplexas. Il cuntrari vala per eventualas dispitas tranter prenditurs da licenza a l'exteriur e las autoritads federalas sco dadi da licenza: lura vala il dretg svizzer. + +La dumonda, tge aspects ch'èn da natira contractuala e tge da natira dal dretg d'autur, na sa lascha betg respunder en general e po esser fitg cumplexa en il cas singul. La transferibladad dal dretg d'autur u da parts da quel u l'extensiun da las concessiuns da dretgs permessas appartegnan per exempel al dretg d'autur. Qua sto vegnir applitgà il dretg dal pajais da protecziun respectiv. Ina tscherna dal dretg divergenta n'è betg pussaivla (per il tut vesair Jaeger/Metzger, 449 ss.). + +=== Exclusiun da responsabladad e da garanzia + +Licenzas open source excludan regularmain mintga garanzia e responsabladad uschè lunsch sco quai è giuridicamain permess. En la pratica cumparan darar dumondas da responsabladad u da garanzia; ils ristgs colliads cun quai èn perquai pitschens. + +I è da supponer che cun ina licenziaziun correcta grippian las clausulas d'exclusiun da responsabladad avant maun en tuttas licenzas tractadas qua, uschia che mo la responsabladad per negligientscha grava ed intenziun, eventualmain per donns a persunas, resta. + +Reglas davart cundiziuns generalas da contract restan resalvadas, per exempel sco en Germania; uschenavant che las autoritads federalas èn dentant subject da responsabladad sco dadi da licenza, vala il dretg svizzer (vesair 8.1 survart) che permetta las exclusiuns da responsabladad e da garanzia menziunadas en il traffic B2B. + +Il cuntrari munta dentant era che tar sbagls dal program è in proceder cunter las auturas ed ils auturs dal code OSS cuntegnì da regla difficil. + +Il proceder usità tar il diever da l'OSS consista perquai regularmain da s'assicurar cunter sbagls cun las mesiras da segirezza informatica usitadas e da garantir la reparaziun dals sbagls via contracts da mantenziun. In regress vers ils contribuents OSS n'exista betg. + +=== Copyleft e licenziaziun tranter posts da l'administraziun federala + +Il copyleft vala tar la transmissiun tranter differents purtaders giuridics (per exempel entaifer in concern u tranter posts da l'administraziun federala decentralisada cun atgna persunalitad giuridica). + +Il copyleft na vala betg tar la transmissiun tranter posts dal medem purtader giuridic (per exempel entaifer l'administraziun federala centrala). + +=== Licenziaziun da patents + +Patents da software èn tenor l'opiniun giuridica europeica mo pussaivels en limitas stretgas. Decisiv è che il software furnescha ina contribuziun tecnica, pia ch'el schligia in problem tecnic concret ordaifer il computer, sin il qual el va. Exempels fissan il cumond dal motor en autos u il cumond d'in robot. Software sco tal che va mo sin in computer, ma n'ha nagin tal effect extern, n'è fundamentalmain betg patentabel en Europa. Uschia na crodan la gronda part dals programs da software betg en il champ d'applicaziun dal dretg da patents. + +En autras parts dal mund, en spezial en ils Stadis Unids, vegnan patents da software concedids in pau pli generusamain. Ma era en ils Stadis Unids na daventa ina idea abstracta u in model da fatschenta betg ina invenziun patentabla mo cun vegnir realisada en software da computer. + +Tar tschertas licenzas na vegnan eventuals patents dal dadi da licenza betg co-licenziads. Quai èn la GPL2, las licenzas BSD e la licenza MIT. + +Per projects che pudessan era vegnir duvrads ordaifer l'Europa u che mussan la furma menziunada d'effect extern, è recumandabel da sclerir ils aspects dal dretg da patents en il cas singul. + +=== Licenziaziun duala + +L'autura u l'autur po licenziar software a medem temp sut differentas licenzas. Quai vegn numnà licenziaziun duala. + +Ina furma interessanta da la licenziaziun duala exista, sche il possessur dals dretgs licenziescha il software sco OSS cun in copyleft ferm (quai ch'impedescha sia integraziun en software proprietar) e porscha al medem temp a prenditurs da licenza interessads ina licenza _cun custs_ che lur permetta d'integrar il software en lur software proprietar. + +Perquai che prenditurs da licenza interessads pon uschia evitar da relaschar lur software proprietar sco OSS, èn els pronts da pajar per la licenza. Vesair era l'agiunta a link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala]. + +Per las autoritads federalas sezzas duess la licenziaziun duala esser nuninteressanta en la gronda part dals cas. Uschè ditg che ils dretgs d'autur sa chattan tar las autoritads federalas (quai ch'è reglà per exempel tenor las cundiziuns generalas da contract da la Confederaziun), pon las autoritads federalas decider sulettas davart ina eventuala licenziaziun duala. + +Sche la mantenziun ed il svilup (vinavant) vegnan externalisads a terzas persunas, po quai esser auter. Sche ils dretgs sa chattan excepziunalmain tar quellas e sche las autoritads federalas s'han mo resalvà il dretg da conceder ina licenza OSS cun copyleft, pudess la terza persuna esser tentada da far ina licenziaziun duala. Sche quai duai vegnir impedì, duess quai vegnir exclus contractualmain. + +=== Midada posteriura da licenzas + +Emprim è da tegnair en scrit che licenzas OSS èn fundamentalmain nunmidablas e nunrevocablas. Prenditurs da licenza ch'han concludì il contract da licenza _avant_ ina midada pon utilisar, midar e dar vinavant a terzas persunas il code vinavant sin la basa da la veglia licenza. + +En la pratica maina ina midada da licenza savens ad in fork d'ina nova versiun dal software sut la veglia licenza, che vegn sviluppà vinavant independentamain dals prenditurs da licenza fin qua. + +L'introducziun d'ina nova licenza per software è mo pussaivla, sche tut ils possessurs dals dretgs d'autur dal software èn perencletgs. Midadas èn capitadas en la pratica, per exempel tar la midada d'ina licenza permissiva ad ina licenza copyleft. + +=== Numnar ils contribuents (collaboraturs e terzas persunas) + +Sch'in program da computer vegn creà en il rapport da lavur, survegn il patrun ina licenza exclusiva per ses diever (art. 17 LDAu). Als emploiads restan uschia en il fund mo ils dretgs da la persunalitad sin il software (resp. tut tenor l'opiniun giuridica mo lur zona centrala). Il medem vala per terzas persunas che sviluppan software per las autoritads federalas, uschenavant che valan las CGCfootnote:[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] correspundentas da la Confederaziun che transfereschan ils dretgs resultants a las autoritads federalas. + +Tuttina sa pona la dumonda, sche contribuents (collaboraturs, terzas persunas) duain avair il dretg u l'obligaziun da sa dar da enconuscher sco auturas ed auturs da contribuziuns en repositoris open source. + +In argument per las autoritads federalas d'utilisar OSS è la purschida da plazzas da lavur attractivas: L'OSS porscha als contribuents la pussaivladad da mussar publicamain lur savida e da sa construir uschia ina reputaziun. Lur abilitads daventan verifitgablas, vegnan confermadas da pers, e tgi ch'ha obtegnì influenza en in project OSS po duvrar quai sco lev tar la tschertga d'ina plazza. + +In ulteriur argument pudessan esser ils dretgs da la persunalitad, dals quals la zona centrala na po vegnir prendida a l'autura u a l'autur original ni tras contract ni tras lescha. Questa zona centrala è dentant pitschna tar programs da computer; da pretender che la sviluppadra u il sviluppader d'in program da computer duess era avair in dretg da vegnir numnà giss probablamain memia lunsch. + +Ultra da quai premetta in barat tranter persunas spezialisadas en la communitad ch'ellas possian vegnir contactadas individualmain dad auters. + +Tut tenor il project po perquai esser sensa da dar als contribuents la pussaivladad da sa dar da enconuscher en la communitad sco contribuents. + +Dal puntg da vista da la protecziun da datas è da evitar in sforz a quai, cun quai che il barat en la communitad na premetta betg la publicaziun dals nums – pseudonims èn pli tgunsch la regla che l'excepziun. Sche contribuents na vulan betg publitgar lur nums, duess lur perquai vegnir dada la pussaivladad da cumparair sut in pseudonim. + +*I vegn recumandà da numnar ils nums dals sviluppaders en ils commits, uschenavant che il project na s'oppona betg.* + +*En mintga cas duessan las autoritads federalas cumparair sco possessuras dals dretgs.* + +=== Dretg d'autur, licenzas per l'IA generativa per crear code + +Qua ans referin nus mo a code ch'è vegnì creà cun agid d'IA generativa. Ulteriuras infurmaziuns davart quest tema sa chattan en link:em002-6.pdf[Em002-6 FAQ davart OSS++*++ en il chapitel 2.2]. Code creà d'in LLM n'è sez betg protegì dal dretg d'autur. Las datas d'instrucziun duvradas dal LLM pon dentant esser protegidas dal dretg d'autur. Sche il code correspunda 1:1, duess era la licenza vegnir surpigliada. Sche il code è vegnì creà a tocs e suenter midà dals sviluppaders, è il ristg pitschen ch'el vala sco software derivà. Da resguardar è che tscherts LLM pretendan ina caracterisaziun correspundenta dal code; eventualas cunvegnas contractualas davart quai ston vegnir observadas. + +=== Contributor Licence Agreements (CLA) e Developer Certificate of Origin (DCO) + +Sche pliras auturas ed auturs lavuran al code d'in project open source, survegnan els dretgs cuminaivels sin il code resultant. + +La licenziaziun dal code a terzas persunas ha lieu via la licenza OSS, cun quai ch'i nascha in agen contract da licenza tranter mintga persuna che utilisescha e mintga autura resp. autur (fastg da licenzas). Questa constellaziun po manar ad ina situaziun giuridica malclera, per exempel en relaziuns internaziunalas (vesair 8.1 survart). Sche interpresas decidan da metter lur software sut ina licenza OSS e d'acceptar contribuziuns da terzas persunas, han ellas a moments il basegn da mantegnair ina tscherta controlla davart il code. + +Uschia po esser interessant da mantegnair averta la pussaivladad da metter il project sut ina nova licenza, u ins vul suttametter code licenzià copyleft ad ina licenziaziun duala e dovra per quai dapli dretgs che quels ch'ins survegniss dals contribuents via ina simpla licenza OSS (vesair 8.5 survart). Contributor Licence Agreements (a moments era Copyright Transfer Agreements) duain schliar tals problems. + +In *Contributor Licence Agreement (CLA)* è ina *cunvegna lianta giuridicamain* che fixescha las *cundiziuns per contribuziuns al project*. + +Contribuents èn obligads da consentir a questa cunvegna, avant che cuntegns pon vegnir contribuids al project. En il fund concedan ils contribuents al project ed a ses utilisaders il dretg da *utilisar, da midar e da derasar vinavant* las contribuziuns fatgas. Ultra da quai vegn confermà che las contribuziuns *èn vegnidas scrittas independentamain u legitimadas da terzas persunas*. + +Il *Developer Certificate of Origin (DCO)* è in *sistem da controlla introducì* il 2004 da la Linux Foundation, ch'è sumegliant en l'intent al Contributor Licence Agreement (CLA) e che represchenta in instrument alternativ adattà. Ils contribuents conferman per mintga contribuziun al project che *(a) els èn autorisads da far la contribuziun, (b) la contribuziun è cuverta d'ina licenza cumpatibla cun il project e (c) els consentan a la derasaziun ed a l'utilisaziun da la contribuziun sco open source*. + +L'instrument principal dals CLA è u la cessiun dals dretgs d'autur dals contribuents a la sviluppadra principala resp. al sviluppader principal u a l'organisaziun purtanta (tar Copyright Transfer Agreements) u la concessiun d'ina licenza uschè vasta sco pussaivel, per ordinari nunrevocabla, dals contribuents a la sviluppadra principala (p.ex. ha Apache definì in CLA). Era contribuziuns a projects serrads suttastattan savens ad in CLA. + +CLA èn contestads en la communitad OSSfootnote:[Per exempel: https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/], tranter auter perquai ch'els pon avrir largias en il copyleft. Perquai datti danedadad era CLA che restrenschan la sviluppadra principala tar la concessiun d'ina nova licenza per il code dal project. + +[mermaid,align="center",alt="Transferiment da code da funtauna e da dretgs en differentas constellaziuns"] +.... +flowchart LR + subgraph TP["Terzas persunas"] + TP1["nagins documents agens"] + TP2["CLA
DCO
licenza OSS"] + TP3["CLA
DCO
licenza OSS
contract"] + TP4["nagins documents agens"] + end + subgraph FA["Administraziun federala"] + FA1["CGC da la Confederaziun
contract"] + FA2["nagins documents agens"] + FA3["licenza OSS
contract
(DCO)
(CLA)"] + FA4["licenza OSS
(DCO)
(CLA)"] + end + TP1 -- "creaziun" --> FA1 + TP2 -- "contribuziun da l'administraziun federala" --- FA2 + TP3 <-- "collavuraziun" --> FA3 + TP4 -- "contribuziun da terzas persunas" --> FA4 +.... + +Illustraziun 4: Transferiment da code da funtauna e da dretgs en differentas constellaziuns + +Legenda: + +* Ils quaders mussan *nua ch'ils dretgs èn definids* en mintga constellaziun. +* *Creaziun* e *contribuziun da terzas persunas*: L'administraziun federala ha la pussanza da concepir. +* *Collavuraziun*: Ils documents vegnan concordads tranter las partidas. +* *Contribuziun da l'administraziun federala*: L'administraziun federala n'ha nagina pussanza da concepir, ina examinaziun è necessaria. +* Ils documents giuridics èn ordinads tenor prioritad da survart engiu; documents en parentesas èn pli gugent da evitar. + +Per *svilups agens* (creation) n'existan nagins problems: Tenor l'art. 17 LDAu è l'autoritad federala possessura dals dretgs d'utilisaziun sin software creà da ses agens collaboraturs. Tar *sviluppaders terzs* duessan las autoritads federalas s'assicurar ils dretgs (per exempel cun utilisar las CGC correspundentas da la Confederaziun). Uschia n'è qua nagin CLA u DCO necessari. + +Nua che autoritads federalas èn sviluppaders principals ed acceptan contribuziuns e collavuraziuns, duess vegnir renunzià a l'utilisaziun d'in CLA. Empè da quai pon vegnir duvrads Digital Certificates of Origin (explitgads cun in exempel en link:em002-4.pdf[Em002-4 Guida da communitads OSS], chapitel 3.3). Fundamentalmain duessan contribuziuns a projects d'autoritads federalas sa basar sin la licenza OSS, per betg augmentar vinavant la sava per contribuziuns. + +Sch'i vegn tuttina constatà en il cas singul, suenter ina examinaziun adequata, in basegn per in CLA, duess l'autoritad federala utilisar il CLA dad Apache.footnote:[https://www.apache.org/licenses/contributor-agreements.html] En quest cas duessan questa decisiun ed il CLA vegnir notads en las remartgas finalas tant da la link:em002-2-1-checklist-oss-preliminary-assessment.pdf[glista da controlla Em002-2.1 Evaluaziun preliminara] sco era da la link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS]. + +Sche autoritads federalas contribueschan a software da terzas persunas che pretenda in CLA, sto il servetsch giuridic examinar en il cas singul, sche l'autoritad federala po acceptar il CLA existent.footnote:[Per in tschert recepient stuess l'administraziun federala examinar la suttascripziun d'in CLA mo ina giada. En autras organisaziuns vegn quai perquai tractà sco affar sin in aut nivel, cun quai che CLA suttascrits vegnan tegnids en l'archiv dals contracts. CLA na dastgan betg sminuir las obligaziuns da l'autoritad federala tenor l'art. 9 EMBAG.] Ils suandants puncts ston vegnir determinads: + +* Ha ina autra autoritad federala gia suttascrit il CLA? +* Tgi examinescha il CLA? +* Tgi il suttascriva? (La persuna che suttascriva sto esser autorisada da suttascriver per la Confederaziun vers terzas persunas) +* Nua vegn el archivà? +* Co vegnan il CLA u il DCO documentads en il project? +* Co vegn garantì che il code relaschà restia publitgà? (Quai resta tenor l'art. 9 EMBAG en la responsabladad da l'autoritad federala, vesair [KBB-MB].) + +Criteris pussaivels per l'examinaziun èn: + +* Cumpatibilitad cun l'art. 9 EMBAG: Resta il code avert? +* Vesa l'autoritad federala ristgs per sasezza? +* Vesa l'autoritad federala in profit per sasezza (p.ex. il code na sto betg vegnir tgirà u sviluppà vinavant suletta) u per auters (entaifer il federalissem da la Svizra u en tut l'Europa sa lascha cuntanscher senza lavur supplementara in effect pli vast)? +* Èn ils dretgs concedids adequats? +* Na vegnan a l'autoritad federala imponidas naginas obligaziuns (nunnecessarias)? +* Correspunda il CLA en il fund al CLA dad Apache? + +=== Problems cun la (L)GPL-3.0 e l'IoT + +_[BITKOM2023]_ renda attent sin in problem tar l'utilisaziun da licenzas (L)GPL-3.0 en connex cun software installà sin apparats: Tals apparats stuessan permetter l'installaziun d'agnas resp. novas versiuns da software. Quai po esser nungiavischà per motivs da segirezza. + +=== Posiziun giuridica da la documentaziun + +Tenor l'art. 5 LDAu n'èn «decisiuns, protocols e rapports d'autoritads e d'administraziuns publicas» betg protegids dal dretg d'autur. + +Quai va pli lunsch che CC-0, perquai che il possessur dals dretgs na sto betg laschar ir l'ovra en il domeni public cun renunziar mundialmain a tut ils dretgs d'autur ed als dretgs da protecziun parents. Ella è gia libra per lescha. Il messadi davart l'art. 5 LDAu tegna en scrit: «La disposiziun permetta anc adina la protecziun dal dretg d'autur per ina entira retscha d'ovras ch'èn naschidas da l'activitad uffiziala u en connex cun quella. + +Documents da cumissiuns da studi e da gruppas da lavur internas da l'administraziun, expertisas u revistas d'uffizis federals per exempel na crodan betg sut la norma. Vi da lur derasaziun libra n'exista nagin interess predominant, perquai ch'ellas n'influenzeschan betg la posiziun giuridica da la burgaisa e dal burgais.» + +Uschia sa lascha argumentar che per blers dals documents relevants e per la documentaziun publitgada d'autoritads federalas en connex cun software open source n'exista nagina protecziun dal dretg d'autur. Il criteri è, sche il document tutga la posiziun giuridica da la burgaisa e dal burgais e sch'el è uschia exceptà da la protecziun dal dretg d'autur. Sche quai n'è betg il cas, duess vegnir duvrada per la documentaziun ina licenza adattada (CC-0footnote:[https://www.creativecommons.ch/], CC-BY, CC-BY-SA u eventualmain LGPL). + +Tuttina fiss la situaziun, en spezial tar l'utilisaziun internaziunala da la documentaziun, malclera per blers utilisaders. + +Nus considerain perquai sco raschunaivel che – sco tar quest document – vegnia era inditgada per segirezza ina relaschada correspundenta. + +== Ulteriuras infurmaziuns davart dumondas giuridicas + +Ulteriuras infurmaziuns davart software open source, davart caracteristicas specificas da licenzas e davart aspects giuridics profunds sa chattan en numerusas publicaziuns che vegnan preschentadas sutvart (vesair era las referenzas a la fin dal document). + +* Il text _«Open Source Software im EMBAG, Analyse des neuen Art. 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben»_ da Rika Koch e Simon Schlauri, en il volum da la Conferenza davart l'acquist informatic 2023 a Berna, porscha ina orientaziun supplementara davart la realisaziun da l'art. 9 EMBAG. +* Il _Leitfaden Open-Source-Software 2.0_ dal BITKOM tudestg tracta detagliadamain dumondas giuridicas enturn l'open source _[BITKOM2023]_. El sa basa dentant sin la situaziun giuridica en Germania. +* Wolfgang Straub examinescha en ses cudesch _Softwareschutz: Urheberrecht, Patentrecht, Open Source_ ils detagls giuridics dal copyleft cun relaziun al dretg d'autur svizzer e va suenter la cumpatibilitad da licenzas open source [St2011]. Il chapitel davart il software open source (sco era translaziuns tudestgas da differentas licenzas open source resguardond la terminologia giuridica svizra) èn disponibels libramain sut _www.it-recht.ch._ +* Till Jaeger ed Axel Metzger respundan en lur cudesch cumplessiv _Open Source Software – Rechtliche Rahmenbedingungen der Freien Software [JaAx2016]_ profundamain a numerusas dumondas giuridicas enturn il software open source. Els sa basan dentant sin la situaziun giuridica en Germania. +* Kropp Jonathan/Bauer Alexander, Open Source Compliance und Litigation, CB 2019 p. 285 ss., 285. +* Reymond Michel José, Questions de responsabilité civile et contractuelle soulevées par la distribution de «logiciels libres» (open source), SZW 2022 p. 69 ss. + +Ultra da quai infurmeschan differents portals online detagliadamain davart las caracteristicas e las dumondas da singulas licenzas open source. + +* Sin la plattafurma GitHub https://choosealicense.com sa laschan tscherner las finamiras giavischadas per in project open source, sin quai che la licenza open source adattada vegn proponida. +* Sut https://opensource.guide/legal/ metta GitHub a disposiziun ina guida online che tracta dumondas giuridicas specificas. +* Sut https://www.gnu.org/licenses/license-list.de.html sa chattan curts commentaris davart differentas licenzas cun indicaziuns davart la cumpatibilitad, en spezial davart la GPL. +* Sut https://opensource.org/faq tracta l'Open Source Initiative numerusas dumondas e respostas davart ils aspects giuridics da licenzas open source. +* Sut https://copyleft.org/guide sa chatta ina guida detagliada che explitgescha ils detagls dal copyleft. +* Sut https://tldrlegal.com vegnan resumadas las licenzas open source las pli impurtantas tenor quai che la respectiva licenza permetta («can»), quai ch'ella scumonda («cannot») e quai ch'ella prescriva («must»). +* Sut https://opensource.com/tags/licensing vegnan publitgads cuntinuadamain artitgels davart dumondas actualas da licenzas. +* Sut https://www.ifross.org/faq-haeufig-gestellte-fragen ha l'«Institut für Rechtsfragen der Freien und Open Source Software» privat a Berlin (ifrOSS) publitgà numerusas respostas a dumondas giuridicas frequentas. + +L'observaziun da licenzas open source vegn oz realisada en emprima lingia cun utensilis da software (per ulteriuras infurmaziuns davart la conformitad open source vesair era Fröhlich-Bleuler _[Fr2012]_ sco er Kuhn, Williamson e Sandler _[KuWiSa2008]_). Uschia èn per exempel differents utensilis open source da la Linux Foundation documentads e publitgads sut il term «fossology» sut https://www.fossology.org. Era purschiders commerzials sco Black Duckfootnote:[https://www.blackducksoftware.com] u FOSSAfootnote:[https://fossa.com] porschan differentas soluziuns proprietaras cun las qualas la cumpatibilitad da las licenzas open source utilisadas po vegnir examinada. + +== Agiunta + +=== Midadas envers la versiun precedenta + +* Resumaziun per la direcziun agiuntada. +* Las licenzas AGPL e MIT vegnan nov recumandadas sco preferiblas. +* Nov en il chapitel 8.8: Dretg d'autur per code generà cun IA. +* Chapitel 8.9 CLA e CDO amplià fitg. +* Differentas meglieraziuns redacziunalas e precisaziuns. +* Dapli exempels inditgads. + +=== Referenzas + +Vesair link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala]. + +=== Abreviaziuns + +Vesair link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] ed link:em002-6.pdf[Em002-6 FAQ davart OSS]. + +=== Exempels da relaschadas e da lur licenza + +En l'avegnir vegn questa glista remplazzada tras ina collecziun da metadatas via publiccode.yml. + +=== D.1 Loom + +URL:: +https://gitlab.com/swiss-armed-forces/cyber-command/cea/loom +Autoritad federala:: +Cyber Command +Descripziun:: +Loom è ina maschina da tschertgar documents efficienta e simpla da manar. Ella automatisescha l'indexaziun da funtaunas da datas configuradas, fa OCR, extrahescha cuntegns e metadatas, pussibilitescha il tagging e porscha pussaivladads da tschertgar e da manar efficientas. +Onn:: +2025 +Licenza:: +MIT +Motivaziun:: +- + +=== D.2 trustbroker.swiss + +URL:: +https://github.com/trustbroker-swiss/trustbroker.swiss +Autoritad federala:: +ChF, UFIT +Descripziun:: +Trust Broker Swiss metta a disposiziun servetschs da federaziun tranter relying parties (applicaziuns, purschiders da servetschs, auters sistems IAM u policy enforcement points) e purschiders d'identitad (IdP, numnads era claims providers) ed utilisescha memorisaders d'attributs fidads per arricchir utilisaders autentifitgads. + +El pussibilitescha a purschiders d'identitad/claims ed a relying parties da barattar infurmaziuns via ina terza partida che zuppenta las specificitads dal IdP e metta a disposiziun ina identitad unifitgada u almain verifitgada supplementarmain. +Onn:: +2024 +Licenza:: +AGPL +Motivaziun:: +Midadas dal code duain adina restar avertas e returnar. ++ +Per il Trust Broker è vegnida fatga ina examinaziun fitg detagliada da la dumonda da la licenza. Tar projects fitg gronds po ella vegnir fatga en questa profunditad da detagl. Tuttas licenzas cumpatiblas cun la software bill of materials èn vegnidas inditgadas en in pool da licenzas. + +=== D.3 Geocat.ch + +URL:: +https://github.com/geonetwork/core-geonetwork +Autoritad federala:: +Swisstopo +Descripziun:: +GeoNetwork è ina applicaziun da catalog per administrar resursas cun referenza spaziala. Ella porscha funcziuns efficientas per elavurar e tschertgar metadatas sco er in visualisatur da chartas web interactiv. Ella vegn actualmain duvrada en numerusas iniziativas per infrastructuras da geodatas en tut il mund. +Onn:: +2012 +Licenza:: +GPL 2.0 +Motivaziun:: +- + +=== D.4 GWEN / ampycloud / c4dl-multi / dvas /… + +URL:: +https://meteoswiss.github.io/ampycloud/ +Autoritad federala:: +MeteoSvizra +Descripziun:: +Pachet Python per determinar la proporziun da cuvrida dal tschiel e l'autezza da basa da stresas da nivels sin la basa da datas da ceilometer. +Onn:: +2023 +Licenza:: +Differentas licenzas, FSS +Motivaziun:: +- + +=== D.5 Applicaziun EMSG (management da mantegniment en zonas d'abitadi) + +URL:: +https://github.com/astra-emsg/ASTRA.EMSG +Autoritad federala:: +MeteoSvizra +Descripziun:: +EMSG è ina applicaziun web GIS en C# sviluppada da l'administraziun federala svizra per administrar il management da mantegniment da sistems da vias urbans. +Onn:: +2017 +Licenza:: +BSD +Motivaziun:: +- + +=== D.6 Applicaziun certificat Covid + +URL:: +https://github.com/admin-ch/CovidCertificate-Documents +Autoritad federala:: +UFIT +Descripziun:: +Applicaziun svizra per certificats COVID +Onn:: +2020 +Licenza:: +MIT +Motivaziun:: +Uschè permissiv sco pussaivel, per che mintgin possia utilisar il code. + +=== D.7 Pagina d'internet GovCert + +URL:: +https://github.com/govcert-ch/website +Autoritad federala:: +NCSC +Descripziun:: +Code da funtauna da la pagina d'internet per il Computer Emergency Response Team (GovCERT) da l'administraziun federala svizra +Onn:: +2023 +Licenza:: +MIT +Motivaziun:: +- + +=== D.8 Differentas bibliotecas davart open data (p.ex. linked data) + +URL:: +https://github.com/SwissFederalArchives +Autoritad federala:: +AFS +Descripziun:: +Il repositori da l'Archiv federal svizzer sin GitHub porscha access als codes da funtauna da nossas applicaziuns. El As permetta da crear agens forks e d'annunziar sbagls u da proponer funcziunalitads ampliadas via l'interfatscha «Issues». +Onn:: +2023 +Licenza:: +AGPL, Apache, MIT +Motivaziun:: +Opendata e software open source van en la medema direcziun. L'AGPL permetta ina avertadad maximala. + +=== D.9 Apache FOP adattà per PDF archivabels + +URL:: +https://xmlgraphics.apache.org/fop/ +Autoritad federala:: +IPI +Descripziun:: +L'IPI vuleva ina versiun dad Apache FOP che po generar PDF archivabels. Per quai è vegnida dada en incumbensa ad in dals sviluppaders centrals (Jeremias Märki) ina extensiun. Ils adattaments èn fluids directamain en il project. +Onn:: +2007 +Licenza:: +Apache +Motivaziun:: +Extensiuns èn vegnidas fatgas ad in project open source existent. + +=== D.10 Endataziun electronica conforma al dretg cun eKomm + +URL:: +https://launchpad.net/ekomm +Autoritad federala:: +IPI +Descripziun:: +L'IPI vuleva software per l'endataziun electronica. +Onn:: +2009 +Licenza:: +Apache +Motivaziun:: +L'IPI vuleva che il purschider (Glue) fetschia la relaschada ed ha permess quella sco permissiva (integraziun en agnas applicaziuns). +endif::[] diff --git a/docs/em002-4-1-checklist-oss-community.adoc b/docs/em002-4-1-checklist-oss-community.adoc new file mode 100644 index 0000000..7737c79 --- /dev/null +++ b/docs/em002-4-1-checklist-oss-community.adoc @@ -0,0 +1,751 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-4.1 OSS Community Checklist +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-4.1 Checkliste OSS-Community +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-4.1 Liste de contrôle Communauté OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-4.1 Lista di controllo Community OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-4.1 Glista da controlla Communitad OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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. + +field::[rows=1] + +=== Contact person and authorisation + +Name the contact person of the specialist department and the persons responsible who have authorised publication of the software. + +field::[rows=3] + +== Checklist + +Type of community + +The community may already exist, which greatly simplifies the task. + +[%interactive] +* [ ] Exists (third party may have the lead) +* [ ] The Confederation has the lead +* [ ] Equal partners (Confederation and partners/suppliers) +* [ ] Other + +Library or entire software? + +There is usually no community concept for libraries. An add-on can only be used together with a commercial product. + +[%interactive] +* [ ] Entire software +* [ ] Library +* [ ] Add-on +* [ ] Other + +What type of community is planned? + +The choice of community type should be justified in two to three sentences. + +[%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 + +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). + +[%interactive] +* [ ] None conceivable +* [ ] Potential users (are conceivable) +* [ ] Known users (have already contacted us) + +[%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. + +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. + +[%interactive] +* [ ] Federal office +* [ ] Service provider +* [ ] Supplier(s) / third parties +* [ ] Joint organisation +* [ ] Open + +Integration of suppliers + +How are the suppliers involved? + +[%interactive] +* [ ] Contractor +* [ ] Partner +* [ ] Responsible body +* [ ] Other + +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. + +[%interactive] +* [ ] Public sector only +* [ ] Simple partnership +* [ ] New or existing association +* [ ] Other (e.g. a foundation, existing or not) + +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. + +[%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) + +[%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. + +[%interactive] +* [ ] Has the community concept been created? + +The community concept has been created or an existing one is being adopted? + +(please insert link) + +[%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. + +== Concluding remarks + +Comments and references to other relevant documents + +field::[rows=4] + +*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. +endif::[] + +ifeval::["{lang}" == "de"] +Diese Checkliste gehört zu _Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software_ und _Em002-4 Leitfaden OSS-Community_. + +Sie ist zu Beginn eines Projekts oder zu Beginn der Abklärungen für die Freigabe auszufüllen und anschliessend zu vervollständigen. + +Zu den OSS-Supportmodellen siehe Kapitel 8 von _Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung_. + +== Gegenstand + +=== Name und Kurzbeschreibung der Software + +Tragen Sie den Namen der Software ein. + +field::[rows=1] + +=== Ansprechperson und Bewilligung + +Nennen Sie die Ansprechperson der Fachabteilung sowie die verantwortlichen Personen, welche die Veröffentlichung der Software bewilligt haben. + +field::[rows=3] + +== Checkliste + +Art der Community + +Die Community kann bereits bestehen, was die Aufgabe stark vereinfacht. + +[%interactive] +* [ ] Besteht (Dritte können die Führung haben) +* [ ] Der Bund hat die Führung +* [ ] Gleichberechtigte Partner (Bund und Partner/Lieferanten) +* [ ] Andere + +Bibliothek oder gesamte Software? + +Für Bibliotheken besteht in der Regel kein Community-Konzept. Ein Add-on kann nur zusammen mit einem kommerziellen Produkt genutzt werden. + +[%interactive] +* [ ] Gesamte Software +* [ ] Bibliothek +* [ ] Add-on +* [ ] Andere + +Welche Art von Community ist geplant? + +Die Wahl der Community-Art sollte in zwei bis drei Sätzen begründet werden. + +[%interactive] +* [ ] Keine, nur Veröffentlichung (as-is) (minimale Freigabe) + +Hinweis: E-Mail muss verfügbar sein, publicode.yaml muss ausgefüllt sein +* [ ] Releases/Issue-Tracker (minimaler Support, nötigenfalls Support durch Dritte zulassen) +* [ ] Community + +Gibt es potenzielle oder tatsächliche Mitnutzende der Software? + +Gibt es potenzielle Abnehmer für die Software? Mögliche und bekannte Nutzende können im Textfeld aufgeführt werden (siehe _Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software,_ Kapitel 3.1.1). + +[%interactive] +* [ ] Keine denkbar +* [ ] Potenzielle Nutzende (sind denkbar) +* [ ] Bekannte Nutzende (haben sich bereits gemeldet) + +[%interactive] +* [ ] Anspruchsgruppen (bereits definierte/bekannte Mitglieder der Community) + +Liste der relevanten Stellen/Unternehmen. + +Dies gibt einen Hinweis darauf, wie relevant die Software für Dritte ist. + +Wer übernimmt das Produktmanagement? + +Das Produktmanagement ist in erster Linie für die Weiterentwicklung des Produkts verantwortlich. Insbesondere wenn diese Rolle von Dritten übernommen wird, sollten die Unternehmen/Organisationen wenn möglich genannt werden. + +[%interactive] +* [ ] Bundesamt +* [ ] Leistungserbringer +* [ ] Lieferant(en) / Dritte +* [ ] Gemeinsame Organisation +* [ ] Offen + +Einbindung der Lieferanten + +Wie sind die Lieferanten eingebunden? + +[%interactive] +* [ ] Auftragnehmer +* [ ] Partner +* [ ] Trägerschaft +* [ ] Andere + +Art der Organisation + +Welche Organisationsform hat die Community? Dies sollte insbesondere bei der Wahl von «Andere» ausführlich erläutert werden. Wegen des damit verbundenen Aufwands sollte ein neuer Verein nur bei sehr guter Begründung gegründet werden. + +[%interactive] +* [ ] Nur öffentliche Hand +* [ ] Einfache Gesellschaft +* [ ] Neuer oder bestehender Verein +* [ ] Andere (z. B. eine bestehende oder neue Stiftung) + +Kostenverteilung + +Diese sollte im Community-Konzept festgehalten werden. Kapitel 5.5 von _Em002-4 Leitfaden OSS-Community_ gibt darüber Auskunft. + +Welche Mittel und Ressourcen sind erforderlich? Die Überlegungen zur Kostenverteilung sollten kurz dargelegt werden. + +[%interactive] +* [ ] Der Bund zahlt +* [ ] Jede Partei trägt ihre eigenen Kosten +* [ ] Verursacherprinzip +* [ ] Der Bund übernimmt keine Kosten der Community +* [ ] Kostenteilung (z. B. über einen Verein) +* [ ] Freigabe, teilweise von Dritten übernommen (z. B. weil die Software vor dem 1. Januar 2024 entstanden ist und sie die Software unbedingt nutzen möchten) + +[%interactive] +* [ ] Werden zusätzliche Leistungen nach Art. 9 Abs. 5 und 6 EMBAG angeboten, ist dies im Community-Konzept festgehalten? + +Das Community-Konzept enthält die entsprechenden Angaben. + +[%interactive] +* [ ] Wurde das Community-Konzept erstellt? + +Das Community-Konzept wurde erstellt oder ein bestehendes wird übernommen? + +(bitte Link einfügen) + +[%interactive] +* [ ] Liegen die erforderlichen Verträge vor? +* [ ] Contributor Licence Agreement (CLA)footnote:[Siehe auch _Em002-3 Leitfaden OSS-Lizenzierung_. Alternativ können auch Developer Certificates of Origin (DCO) verwendet werden.] erstellt oder übernommen +* [ ] Verein gegründet, sofern erforderlich. + +== Schlussbemerkungen + +Bemerkungen und Verweise auf weitere relevante Dokumente + +field::[rows=4] + +*Ablage des Formulars* + +Legen Sie dieses Formular bei der Projektdokumentation ab und reichen Sie es der zuständigen Stelle in Ihrer Organisationseinheit ein. + +*Lizenz der Checklisten-Vorlage: CC0 1.0 Universal* + +Dieses Dokument wird unter der CC0-Lizenz veröffentlicht. Es darf frei genutzt, verändert und verbreitet werden, auch zu kommerziellen Zwecken und in jedem Format. +endif::[] + +ifeval::["{lang}" == "fr"] +Cette liste de contrôle accompagne les documents _Em002-2 Instructions pour la publication de logiciels open source_ et _Em002-4 Guide des communautés OSS_. + +Elle doit être remplie au début d'un projet ou au début des clarifications en vue de la publication, puis complétée par la suite. + +Concernant les modèles de support OSS, voir le chapitre 8 du _Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale_. + +== Objet + +=== Nom et brève description du logiciel + +Indiquez le nom du logiciel. + +field::[rows=1] + +=== Personne de contact et autorisation + +Indiquez la personne de contact du service spécialisé ainsi que les personnes responsables qui ont autorisé la publication du logiciel. + +field::[rows=3] + +== Liste de contrôle + +Type de communauté + +La communauté peut déjà exister, ce qui simplifie considérablement la tâche. + +[%interactive] +* [ ] Existe (des tiers peuvent en assurer la direction) +* [ ] La Confédération en assure la direction +* [ ] Partenaires sur un pied d'égalité (Confédération et partenaires/fournisseurs) +* [ ] Autre + +Bibliothèque ou logiciel complet ? + +Il n'existe en règle générale pas de concept de communauté pour les bibliothèques. Un add-on ne peut être utilisé qu'avec un produit commercial. + +[%interactive] +* [ ] Logiciel complet +* [ ] Bibliothèque +* [ ] Add-on +* [ ] Autre + +Quel type de communauté est prévu ? + +Le choix du type de communauté devrait être justifié en deux ou trois phrases. + +[%interactive] +* [ ] Aucune, publication uniquement (as-is) (publication minimale) + +Remarque : une adresse électronique doit être disponible, le fichier publicode.yaml doit être rempli +* [ ] Releases / suivi des problèmes (support minimal, autoriser au besoin le support par des tiers) +* [ ] Communauté + +Existe-t-il des coutilisateurs potentiels ou effectifs du logiciel ? + +Existe-t-il des clients potentiels pour le logiciel ? Les utilisateurs possibles et connus peuvent être indiqués dans le champ de texte (voir _Em002-2 Instructions pour la publication de logiciels open source,_ chapitre 3.1.1). + +[%interactive] +* [ ] Aucun envisageable +* [ ] Utilisateurs potentiels (sont envisageables) +* [ ] Utilisateurs connus (se sont déjà manifestés) + +[%interactive] +* [ ] Parties prenantes (membres de la communauté déjà définis ou connus) + +Liste des services / entreprises concernés. + +Cela donne une indication de la pertinence du logiciel pour des tiers. + +Qui assume la gestion du produit ? + +La gestion du produit est en premier lieu responsable du développement ultérieur de celui-ci. En particulier lorsque ce rôle est assumé par des tiers, les entreprises ou organisations devraient si possible être nommées. + +[%interactive] +* [ ] Office fédéral +* [ ] Prestataire +* [ ] Fournisseur(s) / tiers +* [ ] Organisation commune +* [ ] Ouvert + +Intégration des fournisseurs + +Comment les fournisseurs sont-ils intégrés ? + +[%interactive] +* [ ] Mandataire +* [ ] Partenaire +* [ ] Organe responsable +* [ ] Autre + +Type d'organisation + +Quelle forme d'organisation la communauté revêt-elle ? Cela devrait être expliqué en détail, en particulier si « Autre » est choisi. Compte tenu de la charge que cela représente, une nouvelle association ne devrait être créée que pour de très bonnes raisons. + +[%interactive] +* [ ] Secteur public uniquement +* [ ] Société simple +* [ ] Association nouvelle ou existante +* [ ] Autre (p. ex. une fondation, existante ou non) + +Répartition des coûts + +Elle devrait être fixée dans le concept de communauté. Le chapitre 5.5 du _Em002-4 Guide des communautés OSS_ fournit des informations à ce sujet. + +Quels moyens et quelles ressources sont nécessaires ? Les réflexions relatives à la répartition des coûts devraient être brièvement exposées. + +[%interactive] +* [ ] La Confédération paie +* [ ] Chaque partie supporte ses propres coûts +* [ ] Principe de causalité +* [ ] La Confédération ne prend en charge aucun coût de la communauté +* [ ] Partage des coûts (p. ex. par le biais d'une association) +* [ ] Publication, partiellement prise en charge par des tiers (p. ex. parce que le logiciel a été créé avant le 1er janvier 2024 et qu'ils souhaitent absolument l'utiliser) + +[%interactive] +* [ ] Si des prestations supplémentaires sont proposées conformément à l'art. 9, al. 5 et 6, LMETA, cela est-il fixé dans le concept de communauté ? + +Le concept de communauté contient les indications correspondantes. + +[%interactive] +* [ ] Le concept de communauté a-t-il été établi ? + +Le concept de communauté a été établi ou un concept existant est repris ? + +(veuillez insérer le lien) + +[%interactive] +* [ ] Les contrats nécessaires sont-ils disponibles ? +* [ ] Contributor Licence Agreement (CLA)footnote:[Voir également le _Em002-3 Guide de licences OSS_. À défaut, des Developer Certificates of Origin (DCO) peuvent aussi être utilisés.] établi ou repris +* [ ] Association fondée, si nécessaire. + +== Remarques finales + +Remarques et renvois à d'autres documents pertinents + +field::[rows=4] + +*Classement du formulaire* + +Veuillez classer ce formulaire avec la documentation de projet et le remettre au service compétent de votre unité d'organisation. + +*Licence du modèle de liste de contrôle : CC0 1.0 Universal* + +Ce document est publié sous licence CC0. Il peut être librement utilisé, modifié et diffusé, y compris à des fins commerciales et dans tout format. +endif::[] + +ifeval::["{lang}" == "it"] +La presente lista di controllo accompagna i documenti _Em002-2 Istruzioni per la pubblicazione di software open source_ ed _Em002-4 Guida alle community OSS_. + +Va compilata all'inizio di un progetto o all'inizio degli accertamenti in vista della pubblicazione e completata in seguito. + +Per i modelli di supporto OSS si veda il capitolo 8 della _Em002-1 Guida pratica per il software open source nell'Amministrazione federale_. + +== Oggetto + +=== Nome e breve descrizione del software + +Indicate il nome del software. + +field::[rows=1] + +=== Persona di contatto e autorizzazione + +Indicate la persona di contatto del servizio specializzato nonché le persone responsabili che hanno autorizzato la pubblicazione del software. + +field::[rows=3] + +== Lista di controllo + +Tipo di community + +La community può già esistere, il che semplifica notevolmente il compito. + +[%interactive] +* [ ] Esiste (terzi possono avere la direzione) +* [ ] La Confederazione ha la direzione +* [ ] Partner con pari diritti (Confederazione e partner/fornitori) +* [ ] Altro + +Libreria o software completo? + +Per le librerie di regola non esiste un concetto di community. Un add-on può essere utilizzato soltanto insieme a un prodotto commerciale. + +[%interactive] +* [ ] Software completo +* [ ] Libreria +* [ ] Add-on +* [ ] Altro + +Quale tipo di community è previsto? + +La scelta del tipo di community andrebbe motivata in due o tre frasi. + +[%interactive] +* [ ] Nessuna, solo pubblicazione (as-is) (pubblicazione minima) + +Nota: deve essere disponibile un indirizzo e-mail, il file publicode.yaml deve essere compilato +* [ ] Release / issue tracker (supporto minimo, se necessario ammettere il supporto da parte di terzi) +* [ ] Community + +Vi sono coutenti potenziali o effettivi del software? + +Vi sono potenziali acquirenti del software? Gli utenti possibili e noti possono essere indicati nel campo di testo (cfr. _Em002-2 Istruzioni per la pubblicazione di software open source,_ capitolo 3.1.1). + +[%interactive] +* [ ] Nessuno ipotizzabile +* [ ] Utenti potenziali (sono ipotizzabili) +* [ ] Utenti noti (si sono già annunciati) + +[%interactive] +* [ ] Parti interessate (membri della community già definiti o noti) + +Elenco dei servizi / delle imprese rilevanti. + +Ciò fornisce un'indicazione sulla rilevanza del software per i terzi. + +Chi assume la gestione del prodotto? + +La gestione del prodotto è responsabile in primo luogo dell'ulteriore sviluppo dello stesso. In particolare se tale ruolo è assunto da terzi, le imprese o organizzazioni andrebbero possibilmente indicate. + +[%interactive] +* [ ] Ufficio federale +* [ ] Fornitore di prestazioni +* [ ] Fornitore/i / terzi +* [ ] Organizzazione comune +* [ ] Aperto + +Coinvolgimento dei fornitori + +In che modo i fornitori sono coinvolti? + +[%interactive] +* [ ] Mandatario +* [ ] Partner +* [ ] Ente responsabile +* [ ] Altro + +Tipo di organizzazione + +Quale forma organizzativa assume la community? Ciò andrebbe illustrato in dettaglio, in particolare se si sceglie «Altro». Dato l'onere che comporta, una nuova associazione dovrebbe essere costituita soltanto in presenza di ottime ragioni. + +[%interactive] +* [ ] Solo ente pubblico +* [ ] Società semplice +* [ ] Associazione nuova o esistente +* [ ] Altro (p. es. una fondazione, esistente o nuova) + +Ripartizione dei costi + +Andrebbe stabilita nel concetto di community. Il capitolo 5.5 della _Em002-4 Guida alle community OSS_ fornisce informazioni al riguardo. + +Quali mezzi e risorse sono necessari? Le considerazioni sulla ripartizione dei costi andrebbero esposte brevemente. + +[%interactive] +* [ ] Paga la Confederazione +* [ ] Ogni parte sostiene i propri costi +* [ ] Principio di causalità +* [ ] La Confederazione non assume alcun costo della community +* [ ] Ripartizione dei costi (p. es. tramite un'associazione) +* [ ] Pubblicazione, in parte assunta da terzi (p. es. perché il software è stato creato prima del 1° gennaio 2024 e intendono assolutamente utilizzarlo) + +[%interactive] +* [ ] Se sono offerte prestazioni supplementari secondo l'art. 9 cpv. 5 e 6 LMeCA, ciò è stabilito nel concetto di community? + +Il concetto di community contiene le indicazioni corrispondenti. + +[%interactive] +* [ ] Il concetto di community è stato allestito? + +Il concetto di community è stato allestito oppure ne viene ripreso uno esistente? + +(inserire il collegamento) + +[%interactive] +* [ ] I contratti necessari sono disponibili? +* [ ] Contributor Licence Agreement (CLA)footnote:[Cfr. anche la _Em002-3 Guida alle licenze OSS_. In alternativa possono essere utilizzati anche i Developer Certificates of Origin (DCO).] allestito o ripreso +* [ ] Associazione costituita, se necessario. + +== Osservazioni conclusive + +Osservazioni e rinvii ad altri documenti rilevanti + +field::[rows=4] + +*Archiviazione del modulo* + +Archiviate questo modulo insieme alla documentazione di progetto e inoltratelo al servizio competente della vostra unità organizzativa. + +*Licenza del modello di lista di controllo: CC0 1.0 Universal* + +Il presente documento è pubblicato sotto licenza CC0. Può essere liberamente utilizzato, modificato e diffuso, anche a scopi commerciali e in qualsiasi formato. +endif::[] + +ifeval::["{lang}" == "rm"] +Questa glista da controlla appartegna a _Em002-2 Instrucziuns per publitgar software open source_ ed a _Em002-4 Guida da communitads OSS_. + +Ella sto vegnir emplenida al cumenzament d'in project u al cumenzament da las scleridas per la relaschada e vegnir cumplettada pli tard. + +Concernent ils models da support OSS vesair il chapitel 8 da _Em002-1 Guida pratica per software open source en l'administraziun federala_. + +== Object + +=== Num e curta descripziun dal software + +Endatai il num dal software. + +field::[rows=1] + +=== Persuna da contact ed autorisaziun + +Numnai la persuna da contact da la partiziun spezialisada sco er las persunas responsablas che han autorisà la publicaziun dal software. + +field::[rows=3] + +== Glista da controlla + +Gener da la communitad + +La communitad po gia exister, quai che simplifitgescha fitg l'incumbensa. + +[%interactive] +* [ ] Exista (terzas persunas pon avair la direcziun) +* [ ] La Confederaziun ha la direcziun +* [ ] Partenaris cun ils medems dretgs (Confederaziun e partenaris/furniturs) +* [ ] Auter + +Biblioteca u software entir? + +Per bibliotecas n'exista da regla nagin concept da communitad. In add-on po vegnir utilisà mo ensemen cun in product commerzial. + +[%interactive] +* [ ] Software entir +* [ ] Biblioteca +* [ ] Add-on +* [ ] Auter + +Tge gener da communitad è planisà? + +La tscherna dal gener da communitad duess vegnir motivada en duas fin trais frasas. + +[%interactive] +* [ ] Nagina, mo publicaziun (as-is) (relaschada minimala) + +Indicaziun: l'e-mail sto esser disponibel, la publicode.yaml sto esser emplenida +* [ ] Releases/issue-tracker (support minimal, permetter sche necessari il support tras terzas persunas) +* [ ] Communitad + +Dattia co-utilisaders potenzials u effectivs dal software? + +Dattia potenzials cumpraders per il software? Utilisaders pussaivels ed enconuschents pon vegnir inditgads en il champ da text (vesair _Em002-2 Instrucziuns per publitgar software open source,_ chapitel 3.1.1). + +[%interactive] +* [ ] Nagins imaginabels +* [ ] Utilisaders potenzials (èn imaginabels) +* [ ] Utilisaders enconuschents (s'han gia annunziads) + +[%interactive] +* [ ] Gruppas d'interess (commembers da la communitad gia definids/enconuschents) + +Glista dals posts/da las interpresas relevantas. + +Quai dat in indizi, quant relevant che il software è per terzas persunas. + +Tgi surpiglia il management dal product? + +Il management dal product è en emprima lingia responsabel per il svilup vinavant dal product. En spezial sche quest rol vegn surpiglià da terzas persunas, duessan las interpresas/organisaziuns vegnir numnadas sche pussaivel. + +[%interactive] +* [ ] Uffizi federal +* [ ] Purschider da prestaziuns +* [ ] Furnitur(s) / terzas persunas +* [ ] Organisaziun cuminaivla +* [ ] Avert + +Integraziun dals furniturs + +Co èn ils furniturs integrads? + +[%interactive] +* [ ] Incumbensà +* [ ] Partenari +* [ ] Purtader +* [ ] Auter + +Gener da l'organisaziun + +Tge furma d'organisaziun ha la communitad? Quai duess vegnir explitgà detagliadamain, en spezial tar la tscherna da «Auter». Pervia da la lavur ch'igl è collià cun quai, duess ina nova associaziun vegnir fundada mo cun ina fitg buna motivaziun. + +[%interactive] +* [ ] Mo il maun public +* [ ] Societad simpla +* [ ] Associaziun nova u existenta +* [ ] Auter (p.ex. ina fundaziun, existenta u nova) + +Repartiziun dals custs + +Quella duess vegnir fixada en il concept da communitad. Il chapitel 5.5 da _Em002-4 Guida da communitads OSS_ dat infurmaziuns davart quai. + +Tge meds e resursas èn necessaris? Las reflexiuns davart la repartiziun dals custs duessan vegnir exponidas curtamain. + +[%interactive] +* [ ] La Confederaziun paja +* [ ] Mintga partida porta ses agens custs +* [ ] Princip dal chaschunader +* [ ] La Confederaziun na surpiglia nagins custs da la communitad +* [ ] Partiziun dals custs (p.ex. via in'associaziun) +* [ ] Relaschada, en part surpigliada da terzas persunas (p.ex. perquai che il software è vegnì creà avant ils 1. da schaner 2024 ed ellas vulan absolutamain utilisar il software) + +[%interactive] +* [ ] Sche prestaziuns supplementaras tenor l'art. 9 al. 5 e 6 EMBAG vegnan purschidas, è quai fixà en il concept da communitad? + +Il concept da communitad cuntegna las indicaziuns correspundentas. + +[%interactive] +* [ ] È il concept da communitad vegnì elavurà? + +Il concept da communitad è vegnì elavurà u in existent vegn surpiglià? + +(inserir p.pl. il link) + +[%interactive] +* [ ] Èn ils contracts necessaris avant maun? +* [ ] Contributor Licence Agreement (CLA)footnote:[Vesair era _Em002-3 Guida da licenzas OSS_. Alternativamain pon era vegnir utilisads Developer Certificates of Origin (DCO).] elavurà u surpiglià +* [ ] Associaziun fundada, sche necessari. + +== Remartgas finalas + +Remartgas e renviaments ad ulteriurs documents relevants + +field::[rows=4] + +*Archivaziun dal formular* + +Archivai quest formular tar la documentaziun dal project ed inoltrai el al post cumpetent en Vossa unitad d'organisaziun. + +*Licenza dal model da la glista da controlla: CC0 1.0 Universal* + +Quest document vegn publitgà sut la licenza CC0. El dastga vegnir utilisà, midà e derasà liberamain, era per intents commerzials ed en mintga format. +endif::[] diff --git a/docs/em002-4.adoc b/docs/em002-4.adoc new file mode 100644 index 0000000..5bc3755 --- /dev/null +++ b/docs/em002-4.adoc @@ -0,0 +1,4400 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-4 OSS Community Guidelines +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-4 Leitfaden OSS-Community +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-4 Guide des communautés OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-4 Guida alle community OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-4 Guida da communitads OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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 {url-repo}/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.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. +* 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 authorised 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.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 + +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.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.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. + +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.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. + +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.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. + +== 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.pdf[Em002-4.1]. The relevant fundamental questions are set out in the morphological box below; each dimension is discussed in the sections that follow. + +[.landscape] +[cols="3,2,2,2,2,2",options="header"] +|=== +|Dimension |(a) |(b) |(c) |(d) |(e) + +|A -- Product management +|Confederation +|Joint organisation +|Open organisation +|Third parties +| + +|B -- Integration of suppliers +|Contractor +|Partner +|Independent +|Lead +| + +|C -- Cost distribution +|Confederation +|Each their own +|Originator pays +|Distribution key +|Contribution + +|D -- Support +|Minimum release +|Support by the Confederation +|Support by third parties +| +| + +|E -- Development +|Internal +|Third parties +|Open +| +| +|=== + +_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 the section 'Cost allocation'. +. *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). + +_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:: +{empty} + +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.pdf[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). + +_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, _[IZqCab2023]_ 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 + +_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 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.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. + +=== 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.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. +* 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.pdf[Em002-7] +* Further editorial changes and improvements + +=== References + +See _Em002 Strategic Guidelines for Open Source Software in the Federal Administration_. + +=== Abbreviations + +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 + +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: ZenDiS in Germany + +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. + +[mermaid,align="center",alt="Goals and approaches to strengthening digital sovereignty (ZenDiS)"] +.... +block-beta + columns 12 + H1["Goals"]:12 + G1["I. Ability to switch supplier"]:4 G2["II. Ability to shape solutions"]:4 G3["III. Influence on suppliers"]:4 + H2["Solution approaches"]:12 + B1["1. Forward-looking analysis
and management of
dependencies"]:3 B3["3. Vendor-independent
modularity, (open) standards
and interfaces in IT"]:3 B5["5. Collaborative co-design
of IT solutions"]:3 B7["7. Legal requirements"]:3 + B2["2. Procurement or development
of alternative IT solutions
(e.g. OSS)"]:3 B4["4. Building digital skills
and expert knowledge"]:3 B6["6. Shared understanding
and approach"]:3 B8["8. Political governance"]:3 + classDef highlight fill:#dae8fc,stroke:#000000,color:#000000 + class B2 highlight +.... + +Figure 1: 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 Broker + +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 + +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 fed back 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/en] +* 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. +endif::[] + +ifeval::["{lang}" == "de"] +NOTE: 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 {url-repo}/tree/main[README]. + +== Das Wichtigste auf einen Blick + +Nachfolgend sind die wichtigsten Punkte des Dokuments aufgeführt. + +* Der Aufbau oder Betrieb einer OSS-Community ist nach Art. 9 EMBAG *nicht erforderlich*. +* Eine Community ist relevant, wenn eine Anwendergruppe sinnvoll ist und *Synergien* mit anderen Nutzenden der Software geschaffen werden sollen. +* Eine Community beschränkt sich nicht auf die Software selbst, sondern kann auch die Prozesse im Umfeld und die Standardisierung von Daten umfassen. +* Für den Aufbau einer Community ist stets ein *Initialaufwand* zu leisten. Dieser setzt sich in der Regel fort. Vielfach ist es sinnvoll, dass das federführende Amt auch die Koordinationskosten trägt. +* Communities sollen einen *Zweck* erfüllen. Es braucht Interessierte und Beteiligte. +* Eine Community kann entstehen und anschliessend formalisiert werden. +* Ziel der Community ist es, den *Nutzen für alle* zu erhöhen. Grundsatz: «Man erhält mindestens so viel zurück, wie man einbringt». +* Die Community sollte *so einfach wie möglich strukturiert* sein. +* In einem ersten Schritt sollte die Community anhand der Checkliste link:em002-4-1-checklist-oss-community.pdf[Em002-4.1] kurz geprüft werden. Nur wenn sie sinnvoll ist, sollte sie weiterentwickelt werden. +* Die Formalisierung erfolgt über ein *Community-Konzept*. Möglichst viel sollte aus bestehenden Quellen übernommen werden. Grundsatz: «Das Rad nicht neu erfinden». +* Wird eine Zusammenarbeit angestrebt, so ist dies bereits zu Beginn des Projekts zu berücksichtigen, da potenzielle Partner schon bei der Anforderungsanalyse abgeholt werden sollten. Auch rechtlich und beschaffungsrechtlich muss dies von Anfang an gut geplant sein. +* Die Möglichkeiten für den Beitritt zu einer bestehenden Zusammenarbeit sind rechtlich und beschaffungsrechtlich zu prüfen. +* Für Beiträge muss keine Community aufgebaut werden. Verlangt es das Projekt jedoch, so ist das entsprechende *Contributor Licence Agreement (CLA)* zu unterzeichnen oder müssen die Entwickelnden vom Projekt befugt sein, die Software unter einem Developer Certificate of Origin (DCO) einzureichen. + +== Einleitung + +Dieser Leitfaden richtet sich an IKT-Fachpersonen, die für eine Anwendung verantwortlich sind und diese als Open Source anbieten oder zu einer solchen Anwendung beitragen wollen. + +Dies ist entweder formell oder informell zu organisieren. + +Dieses Dokument liefert wichtige Informationen für die Organisation und den Aufbau einer Communityfootnote:[Die Community eines Open-Source-Projekts stellt typischerweise eine Pyramide dar. + +Das Fundament dieser Pyramide bilden die Nutzenden der Software, insbesondere die engagierten, die sich aktiv in der Community beteiligen, etwa in Form von Fehlermeldungen und Feature-Wünschen oder durch Beiträge zu Mailinglisten. + +Direkt darüber stehen in der Pyramide die Contributors. Dies sind Teile der Community, die eigene Codebeiträge vorschlagen. Sie haben typischerweise keinen Schreibzugriff auf das Repository. Ihre Beiträge werden von Maintainern des Projekts geprüft und nach Erreichen der projekttypischen Qualität ins Repository übernommen. + +An der Spitze der Pyramide stehen die Maintainer bzw. Committer eines Projekts. In dieser Rolle trägt eine Entwicklerin oder ein Entwickler eine höhere Verantwortung. Dies zeigt sich beispielsweise in der Möglichkeit, Beiträge anzunehmen. Dieses Recht manifestiert sich häufig über den Schreibzugriff auf das Repository. Auf dieser Ebene findet die Kontrolle über die Software, ihre Qualität und ihren Funktionsumfang statt. Bei komplexeren Projekten kann diese Ebene weiter unterteilt sein. So hat beispielsweise der Linux-Kernel bekanntlich Subsystem-Maintainer auf mehreren Ebenen, und schliesslich übernimmt nur eine einzige Entwicklerpersönlichkeit, Linus Torvalds, die Patches ins Projekt-Repository. Ein weiteres Beispiel sind Projekte der Eclipse Foundation, die typischerweise über einen Project Lead mit zusätzlichen Rechten im Rahmen des Entwicklungsprozesses der Eclipse Foundation verfügen, etwa das Auslösen des Release-Prozesses oder die formelle Wahl von Committern oder Project Leads _[BITKOM2023]_.] sowie für die offene Entwicklung direkt als Open-Source-Projekt. + +Als zweites Element wird zur Förderung der Standardisierung im Rahmen dieses Dokuments ein Verzeichnis bestehender Community-Konzepte geführt. Die Idee ist, dass neue Communities mit minimalem Aufwand auf der Grundlage erfolgreicher Lösungen aufgebaut werden können. + +Dieses Dokument enthält keine direkten Empfehlungen für die Organisation von Communities für Softwarebibliotheken (Teile von Software, die Teilfunktionen erfüllen, z. B. PDF-Erzeugung). Normalerweise wird für diese kein eigenes Konzept erarbeitet; stattdessen verwenden sie die einfache Vorlage, die in der Ablagevorlage des Repositorys festgelegt ist. + +Das Dokument link:em002-1.pdf[Em002-01 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung] enthält in Kapitel 4 grundlegende Formen der Zusammenarbeit, in Kapitel 8 die verschiedenen Supportmodelle und im Anhang Informationen zum Marktverhalten von Open Source. + +== Art, Ziel und Zweck einer Community + +Eine Community kann die folgenden Zwecke verfolgen: + +* Erhebung zusätzlicher Anforderungen +* Verbreitung von Wissen über die Anwendung +* Bessere Rückmeldungen von Nutzenden +* Förderung von Übersetzungen, Dokumentation und Schulungen +* Verbreitung der Standardisierung +* Allgemein verbesserte Interaktion mit den Nutzenden +* Ausweitung der Zusammenarbeit auf weitere Beteiligte +* Förderung weiterer Software auf Basis der Software + +Welche Art von Community für eine Anwendung am besten geeignet ist, hängt stark vom fachlichen Umfeld, den potenziellen Nutzenden und der Strategie der veröffentlichenden Institution ab. Es gibt viele unterschiedliche Wege, Communities aufzubauen. Idealerweise kann sich ein geeignetes Projekt einer bestehenden Community anschliessen. Alternativ kann eine Community mit einem oder mehreren gleichberechtigten Partnern aufgebaut werden. + +Wichtig ist, dass eine *Governance-Struktur* festgelegt und die massgebenden Punkte in einem *Community-Konzept* dokumentiert werden (siehe auch _[BITKOM2023]_ Kapitel 4.1 und _[IZqCab2023]_). + +Zu beachten ist, dass Communities für Software auch mit solchen für Daten, Standardisierung und fachliche Themen kombiniert werden können. Die Community kann dann Prozesse, Standardisierung, Software und Daten umfassen. Bestehende Gefässe wie eOperations, DVS und eCH können ebenfalls genutzt werden, wo dies sinnvoll ist. + +Ein wichtiger Aspekt einer funktionierenden Community ist, dass die Beteiligten mehr erhalten, als sie investieren. + +Es bestehen die folgenden Konstellationen: + +* *Community rund um eine OSS des Bundes*: Governance und Community-Konzept sind zu erstellen. In diesem Zusammenhang ist auch zu regeln, wie Dritte Beiträge leisten können. +* *Neue Zusammenarbeit zur Lösung eines Problems*: Neben Governance und Community-Konzept ist die gesamte rechtliche Struktur der Zusammenarbeit aufzubauen. +* *Beitritt zu einer Zusammenarbeit*: Die Bundesverwaltung muss prüfen, ob und wie sie dies tun kann. +* *Beitrag zu einem Drittprojekt*: Zu prüfen ist die Politik des Projekts für Beiträge (Contributor Licence Agreement, Developer Certificate of Origin usw.). + +Beschaffungsrechtliche Fragen werden in link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software] behandelt. + +=== Sonderfall: Neue Zusammenarbeit für Entwicklung, Wartung und Support von Open-Source-Software + +Die Gesamtkosten von Open-Source-Software sinken, wenn sie gemeinsam entwickelt und weiter gepflegt wird. Dies kann ohne förmliche Kooperationsvereinbarungen erfolgen oder mit nicht mehr als einer gemeinsamen Planung. + +Wird eine förmlichere Zusammenarbeit angestrebt, so sollte eine Marktabklärung durchgeführt werden, um sicherzustellen, dass die Zusammenarbeit die geeignetste Form der Kooperation ist. Zusammenarbeiten sind kostengünstiger als eine Einzelentwicklung durch jede Partei (siehe link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]). + +Zu beachten ist, dass es bei Zusammenarbeiten sinnvoll ist, die Zusammenarbeit sehr früh in der Projektmethodik HERMESfootnote:[https://www.hermes.admin.ch/de/projektmanagement/methodenuebersicht.html] anzustossen – konkret während der Phasen Situationsanalyse und Anforderungen. + +Zusammenarbeit ist in der Schweiz nach Artikel 4 EMBAG grundsätzlich zulässig. + +Neben allen weiteren Überlegungen haben Zusammenarbeiten sowohl eine rechtliche als auch eine beschaffungsrechtliche Dimension. Derzeit wird jeder Fall einzeln beurteilt. Mit der Zeit werden sich standardisierte Vorlagen etablieren. + +==== Rechtliche Dimension + +Vereinsmitgliedschaften sind machbar, werden aber in der Regel im Einzelfall beurteilt: Wer steht hinter dem Verein, und welche Verpflichtungen werden eingegangen? Eine Delegation von Mitgliedschaften an eOperations oder ähnliche Organisationen wäre möglich. + +Solange kein Geld fliesst und keine förmlichen Verpflichtungen eingegangen werden müssen, ist ein Memorandum of Understanding auf Ebene des Bundesamts oder der Bundeskanzlei möglich. + +Eine Situation, die den Abschluss eines völkerrechtlichen Vertrags erfordert, sollte vermieden werden. + +Es gibt zudem zwei Sonderfälle,footnote:[https://www.eda.admin.ch/deza/de/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] in denen eine Zusammenarbeit bereits abgedeckt wäre: + +* Aufträge, die im Rahmen einer internationalen Vereinbarung über die gemeinsame Durchführung eines Projekts durch Signatarstaaten vergeben werden. +* Aufträge, die nach den besonderen Verfahren oder Bedingungen einer internationalen Organisation vergeben werden. + +==== Beschaffungsrechtliche Dimension + +In vielen Fällen findet die Zusammenarbeit zwischen Organisationen des öffentlichen Sektors statt. In solchen Fällen ist die Beschaffung unproblematisch, sofern die Konstellation «staatsintern» ist (siehe link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software]). + +Verträge mit ausländischen Unternehmen ohne Sitz in der Schweiz sind möglich, sofern die Anforderungen des Beschaffungsrechts erfüllt sind. + +Die Beschaffung eigener Ressourcen einer Organisation erfolgt im Rahmen eines üblichen Beschaffungsprozesses oder ist bereits abgeschlossen. + +=== Sonderfall: Beitritt zu einer bestehenden Zusammenarbeit + +Dies erfordert sowohl eine rechtliche Grundlage als auch die Einhaltung des Beschaffungsrechts. + +Am einfachsten ist die Beteiligung nach dem Grundsatz «jede Partei trägt ihre eigenen Kosten». Damit lassen sich auch Gemeinkosten abdecken, sofern entweder interne Ressourcen oder korrekt ausgeschriebene externe Ressourcen eingesetzt werden. + +Eine direkte Beteiligung an ausländischen Zusammenarbeiten ist schwieriger. Ein einfacher Zusammenschluss über ein Memorandum of Understanding ist am einfachsten zu erreichen. + +=== Sonderfall: Codebeiträge an Drittprojekte + +Nimmt die Bundesverwaltung Änderungen am Code eines bestehenden OSS-Projekts vor, so ist es sinnvoll, diese Änderungen direkt upstream in das ursprüngliche Projekt einzubringen. Damit muss die laufende Pflege nicht mehr von der Bundesverwaltung geleistet werden. + +Nach Artikel 9 EMBAG sind solche Beiträge sogar erwünscht. Beschaffungsrechtlich ist dies unproblematisch. + +Wichtig ist, dass die Rechtsinhaberin den Beitrag leistet. Das heisst, dass die Bundesverwaltung dies stellvertretend für ihre Mitarbeitenden und Auftragnehmer verantwortet. Konkret ist ein allfälliges Contributor Licence Agreement des Projekts zu unterzeichnen oder ist dem Pull Request ein Developer Certificate of Origin beizulegen. + +Ein **Developer Certificate of Origin**footnote:[https://developercertificate.org/] *(DCO)* für die Bundesverwaltung könnte lauten: + +[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. +____ + +Der Aufbau eines Contributor Licence Agreement wird in link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung], Kapitel 8.9, beschrieben. + +Die effektive Übergabe des Codes erfolgt nach den Richtlinien des jeweiligen Projekts. + +== Community-Konzept + +Der Kern einer Community sind letztlich ihre Struktur und ihre Governance. Diese werden in einem Community-Konzept festgehalten. + +Das von der Projekt- oder Applikationsverantwortung zu erstellende (oder bei Dritten in Auftrag gegebene) Community-Konzept sollte dieser Kapitelstruktur folgen. Je nach Art der konkreten Community sind nicht alle Unterkapitel nötig. Idealerweise verweisen viele Kapitel auf bereits standardisierte Dokumente oder nutzen Standardprozesse der entsprechenden Repositories. Das Community-Konzept lässt sich auch auf bestehende, von anderen geführte Projekte anwenden, insbesondere wenn die tatsächliche Governance noch nicht schriftlich dokumentiert ist. + +Mit der Formalisierung der Community werden alle Beteiligten zusammengeführt und das Onboarding neuer Beteiligter wird vereinfacht. + +Strukturentwurf eines Community-Konzepts: + +[arabic] +. Übersichtstabelle (Name, Repository, Kontaktadresse, Lizenz, Tiefe des Supports, bestehend/neu) +. Ziele +[loweralpha] +.. der Anwendung +.. der Community +. Organisation +[loweralpha] +.. Eigentümerin des Codes +.. Organisationsform / Gremien +.. Stimmrechte +.. Projektleitung +.. Beschaffungsfragen (sofern zutreffend) +.. Weitere Governance-Aspekte +. Roadmap und Änderungsprozess +. Entwicklungsprozess +[loweralpha] +.. Offene Entwicklung +.. Committer-Rechte +.. Review-Prozess +.. Aufgabenverteilung und Namensnennungen +.. Backups +. Finanzierung der Community +. Marketing +. Umgang mit externen Beiträgen +[loweralpha] +.. Umgang mit gemeldeten Fehlern +.. Umgang mit Anfragen +.. Umgang mit Pull Requests +.. Umgang mit Forks +.. CLA, DCO und Zuweisung von Rechten/geistigem Eigentum +. Betrieb der Anwendung + +Grundsätzlich ist jede Bundesbehörde für die Erstellung der Community-Konzepte verantwortlich. DTI kann bestehende Muster/Beispiele veröffentlichen und nimmt entsprechende Beispiele zur Veröffentlichung entgegen. Sinnvoll ist zudem, dass sich die Community-Managerinnen und -Manager untereinander austauschen. + +Eine mögliche Quelle für Teile ist auch die Dokumentation der Eclipse Foundation,footnote:[Siehe https://www.eclipse.org/projects/handbook/#starting] wobei hier im Sinne von «nur das Nötige tun» ein angemessenes Tailoring vorzunehmen ist. + +== Grundsatzentscheide beim Aufbau einer Community + +Die Grundsätze der Community – oder deren Verzicht – werden anhand von link:em002-4-1-checklist-oss-community.pdf[Em002-4.1] festgelegt. Die massgebenden Grundsatzfragen finden sich im nachstehenden morphologischen Kasten; jede Dimension wird in den folgenden Kapiteln erläutert. + +[.landscape] +[cols="3,2,2,2,2,2",options="header"] +|=== +|Dimension |(a) |(b) |(c) |(d) |(e) + +|A -- Produktmanagement +|Bund +|Gemeinsame Organisation +|Offene Organisation +|Dritte +| + +|B -- Einbindung der Lieferanten +|Auftragnehmer +|Partner +|Unabhängig +|Führung +| + +|C -- Kostenverteilung +|Bund +|Jede und jeder für sich +|Verursacherprinzip +|Verteilschlüssel +|Beitrag + +|D -- Support +|Minimale Freigabe +|Support durch den Bund +|Support durch Dritte +| +| + +|E -- Entwicklung +|Intern +|Dritte +|Offen +| +| +|=== + +_Morphologischer Kasten OSS-Community._ + +Es empfiehlt sich, bei der Gestaltung der Community *primär auf die nahe Zukunft zu fokussieren*; gibt es beispielsweise noch keine konkreten Interessierten für die Anwendung, so ist es meist wenig sinnvoll, eine Community mit einer einfachen Gesellschaft, einem eigenen Verein und komplexen Prozessen für die Entwicklung der Roadmap zu definieren.footnote:[Mit einem Verein (oder einer Stiftung) wird eine eigene juristische Person geschaffen, die sich um die Software und das Produkt kümmert. Dies lohnt sich erst ab einer gewissen Bedeutung, Komplexität und dem Bestehen mehrerer (gleichberechtigter) Partner. Eine Roadmap dient dazu, der breiteren Öffentlichkeit und potenziellen weiteren Nutzenden der Software aufzuzeigen, was geplant ist.]footnote:[Insbesondere bei Projekten, an denen von Anfang an mehrere staatliche Akteure beteiligt sind, kann es auch möglich sein, auf bestehende Stiftungen zuzugehen und zu prüfen, ob die Projekte und die Governance unter deren Dach geführt werden können, analog zu https://finos.org oder https://osr.finos.org oder https://www.eclipse.org/collaborations/ oder https://iot.eclipse.org oder https://outreach.eclipse.foundation/open-regulatory-compliance.] + +=== Produktmanagement + +Je nach Art der Anwendung, ihrer strategischen Bedeutung und ihrem Stand im Lebenszyklus bestehen verschiedene Varianten zur Abbildung des Produktmanagements. Bei Organisationen innerhalb von Bundesbehörden betrifft dies stets die Applikationsverantwortlichen. Für das Community-Konzept besonders relevant sind die Definition der fachlichen und technologischen Roadmap sowie die Release-Prozesse. + +Möglichkeiten: + +[loweralpha] +. *Organisationen innerhalb des Bundes*: Der Bund will die Kontrolle behalten; er definiert die Roadmap allein. +. *Gemeinsame Organisation*: Zusammen mit anderen Nutzenden oder Lieferanten. +. *Offene Organisation*: Lose Verbindungen, keine aktive Roadmap. +. *Dritte*: Entweder besteht das Produkt bereits oder die Arbeit soll ausgelagert werden. + +==== Organisationen innerhalb des Bundes: + +Ist die Anwendung von hoher strategischer Bedeutung oder ist der Bund darauf angewiesen, seine Änderungen rasch umsetzen zu können, so kann es sinnvoll sein, die Kontrolle zu behalten. + +Die Bundesbehörde entscheidet über die Anforderungsverantwortung allein, was wann in die Software einfliesst. + +Für potenzielle andere Nutzende der Anwendung bedeutet dies, dass sie praktisch gezwungen sind, eine eigene Version (Fork) der Anwendung zu verwenden. + +Andernfalls haben sie kaum Möglichkeiten, für sie allenfalls wichtige Anpassungen und Erweiterungen umzusetzen. Dies spricht nicht gegen eine Veröffentlichung als Open Source: Die Werkzeuge zur Codeverwaltungfootnote:[z. B. GitHub] bieten umfangreiche Unterstützung für solche Szenarien, und Anpassungen sowie Fehlerkorrekturen können in beide Richtungen selektiv übernommen werden. + +Eine Kostenteilung ist bei diesem Modell typischerweise schwierig. + +==== Gemeinsam (Bund hat die Führung oder gleichberechtigte Partner) + +Entscheide zu Roadmap und Prioritäten sollten mit den übrigen Mitgliedern der Community abgestimmt und gemeinsam gefällt werden. Der Bund beteiligt sich als Mitglied der Community, ist aber nicht die federführende Organisation. + +Damit die gemeinsame Entscheidfindung funktioniert, müssen Strukturen und Regeln vorgängig festgelegt werden. Damit wird auch definiert, wie die Kosten für die Umsetzung der gemeinsam beschlossenen Anpassungen untereinander aufgeteilt werden. + +Bei diesem Modell entsteht eine einzige Version der Anwendung, die dann von allen Mitgliedern genutzt wird. Dadurch sind die Gesamtkosten im Vergleich zu den anderen Varianten deutlich tiefer. Die Flexibilität der einzelnen Nutzenden ist jedoch geringer, und sie müssen ihre Anpassungswünsche vorgängig mit allen anderen abstimmen. Die Entscheidfindung ist langsamer und aufwendiger. + +Dieses Modell eignet sich am besten für Anwendungen, die gemeinsam mit klar definierten anderen Organisationen (z. B. Kantonen) weiterentwickelt werden sollen. + +==== Offene Organisation + +Bei diesem Modell sind die Prozesse und Strukturen nur lose definiert. Der Bund behält formell die Kontrolle, ist aber offen für Beiträge und Anpassungen. + +Es wird keine oder nur eine sehr grobe Roadmap definiert; der Konsens wird informell und in Diskussionen direkt auf der Veröffentlichungsplattform erreicht. Die Community selbst ist eher dynamisch; Mitglieder können eine Zeit lang sehr aktiv sein und sich dann wieder zurückziehen. + +Dieses Modell eignet sich auch für kleinere Anwendungen, die bereits produktiv im Einsatz und «fertig» sind. Es ist zudem meist die beste Form für technisch orientierte Anwendungen oder Komponenten, die potenziell eine breitere, vorgängig nicht genau bestimmbare Zielgruppe ansprechen. + +==== Dritte + +Bei diesem Modell werden die Prozesse und Strukturen von Dritten definiert und die Bundesbehörde ist Mitglied der Community, hat aber nicht die Führung. Dies kann daher rühren, dass das Projekt beispielsweise von einem anderen Staat oder Kanton definiert wurde. Oder es kann sein, dass der Bund nicht daran interessiert ist, das Programm selbst weiterzuführen, und diese Aufgabe überträgt. + +=== Einbindung der Lieferanten + +Für die Einbindung von Lieferanten bestehen grundsätzlich die folgenden Möglichkeiten: + +[loweralpha] +. *Lieferant als Auftragnehmer*: Er gilt mittelfristig grundsätzlich als ersetzbar. Der Lieferant soll die Anwendung auf Basis von Aufträgen des Produktmanagements (oder der Community) kostengünstig und in hoher Qualität entwickeln, hat aber höchstens beratenden Einfluss auf Roadmap und Priorisierung. +. *Langfristige Partner mit Mitbestimmung*: Sie sollen die Entwicklung aktiv mitbestimmen können. Dies stärkt ihre Rolle und sie sind potenziell bereit, selbst in die Anwendung zu investieren. Typischerweise vertreiben die Lieferanten in diesem Modell die Software und suchen aktiv neue Kundinnen und Kunden. +. *Unabhängig:* Die Lieferanten legen selbst fest, ob und wie sie am Projekt arbeiten wollen. Dies kann etwa vorkommen, wenn mehrere Lieferanten auf Basis der Software eigenes Geschäft generieren wollen. Liberale Lizenzen können dies potenziell fördern. Es kann auch vorkommen, wenn die Strategie des Bundes von jener des Lieferanten abweicht. In diesem Szenario ist wahrscheinlich, dass der Lieferant einen Fork erstellt. +. *Führung*: Übernimmt der Lieferant das Produktmanagement, so hat er die Führung. Die Entwicklung wird dann von ihm bestimmt. Andererseits kann dies auch bedeuten, dass die Bundesverwaltung nur sehr wenig Verantwortung übernehmen muss. Bei einer minimalen Freigabe ist es möglich, dass der Lieferant diese Rolle eigenständig übernimmt. + +Übernimmt der Lieferant eine starke Rolle, so bringt dies Vorteile für die Bundesverwaltung: Durch die aktive Vermarktung der Anwendung besteht die Chance, dass die Community schneller und stärker wächst und so die Kosten pro Mitglied rascher sinken. + +Wird ein Modell mit starker Mitbestimmung der Lieferanten gewählt, so ist darauf zu achten, dass daraus keine Abweichung von beschaffungsrechtlichen Vorgaben resultiert. In der Regel empfiehlt es sich, mindestens zwei Lieferanten einzubeziehen, um keine zu starke Abhängigkeit von einem einzigen Lieferanten zu schaffen. Zudem sollte die Möglichkeit bestehen, dass weitere Lieferanten der Community beitreten. + +=== Kostenverteilung + +Für die Aufteilung der Kosten für Wartung, Weiterentwicklung und neue Funktionen stehen die folgenden Optionen zur Verfügung: + +[loweralpha] +. *Organisationen innerhalb des Bundes*: Insbesondere beim Aufbau von Ökosystemen oder wenn die Bundesbehörde die volle Kontrolle behalten will, muss die Bundesbehörde auch die Kosten tragen. +. *Jede und jeder für sich*: Alle bezahlen die von ihnen gewünschten Änderungen selbst. Nötigenfalls wird im Einzelfall entschieden, bestimmte Erweiterungen gemeinsam zu bezahlen. Wiederkehrende Kosten werden nach einem Verteilschlüssel oder nach Bedarf verrechnet. +. *Verursacherprinzip*: Wer die Leistungen oder Funktionen tatsächlich benötigt, bezahlt dafür. Es können standardisierte Stundensätze angewendet werden. +. *Verteilschlüssel*: Die Kosten werden innerhalb der Community nach einem definierten Schlüssel aufgeteilt. Davon weichen nur spezifische Erweiterungen ab. Diese sollten direkt von den betroffenen Nutzenden bezahlt werden. Der Kostenteiler kann beispielsweise die Grösse des betroffenen Kantons oder die Zahl der Nutzenden sein. Zum Verteilschlüssel siehe auch das Kapitel «Kostenaufteilung». +. *Beitrag*: Wenn die Bundesbehörde lediglich Personal in ein bestehendes Projekt einbringt. + +Grundsätzlich ist Variante b (Kostenteilung) in der Regel nur dann sinnvoll, wenn auch ein gemeinsames Produktmanagement wie in Variante b (gemeinsam) besteht. Nur wer mitreden kann, wird bereit sein, die Folgekosten der Entscheide zu tragen. + +=== Support + +Im Rahmen von Kostenverteilung und Aufwand ist zu klären, wer welchen Support leistet. Nach Art. 9 EMBAG ist eine reine minimale Freigabe möglich. Diese Variante erzielt unter Umständen nicht die gewünschte Wirkung und baut für sich genommen keine Community auf, in der die Bundesbehörde Einfluss hat. + +[loweralpha] +. *Minimale Freigabe*: Kein Support (d. h. die Freigabe erfolgt in der Regel ohne organisierten Support und ohne Beteiligung der Bundesbehörde). +. *Support durch den Bund*: Die Bundesbehörde (oder ihr Leistungserbringer) leistet definierten Support. +. *Support durch Dritte*: Die Bundesbehörde oder die Community definiert eine Supportorganisation. + +Die zu erzielende Wirkung, etwa auf das Schweizer Ökosystem oder eine Anschubfinanzierung einer Community, kann dazu führen, dass der Bund Support leistet. Der Umfang des Supports ist selbstverständlich zu definieren. Grundsätzlich kann auch eine Gebühr erhoben werden. Aufgrund der Mechanismen des Bundes dürften Leistungserbringer oder Lieferanten eher in der Lage sein, kommerziellen Support anzubieten. + +Ämter dürfen nach EMBAG kostenpflichtigen Support anbieten (allenfalls auch über Leistungserbringer und Dritte). Dazu müssen sie die entsprechenden Gebühren auf ihrer Website veröffentlichen, da die nötige gesetzliche Grundlage besteht. Die Anbindung an das Zahlsystem kann mit dem EFD besprochen werden. + +Beispiele für Support und Gebühren finden sich in Anhang G. + +=== Entwicklung + +Auch die grundsätzliche Methodik der Entwicklung kann Einfluss auf die Art der Community haben. + +[loweralpha] +. *Intern*: Die Nutzung interner Repositories bedeutet, dass Dritte nicht direkt mitarbeiten können. Je strikter die Trennung, desto mehr Integrationsaufwand hat der Bund zu leisten, wenn er Erweiterungen Dritter übernehmen will. Auch der Freigabeprozess ist aufwendiger. +. *Dritte*: Entweder arbeitet ein Lieferant eigenständig, oder das bereits von Dritten gestartete bzw. geführte Produkt wird nach definierten Regeln entwickelt. +. *Offen*: Die Softwareentwicklung erfolgt direkt in einem öffentlichen Repository. Die Freigabe nach EMBAG ist damit weitgehend gewährleistet. Die Aufwände fallen während der Entwicklung an. In diesem Szenario kann die Zusammenarbeit mit Dritten auch früher (und einfacher) erfolgen. + +== Detaillierte Inhalte für das Community-Konzept + +Dieses Kapitel gibt Hinweise zum Verfassen des Community-Konzepts auf Basis der getroffenen Grundsatzentscheide (gemäss Kapitel 5). + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +offen / Partner / Bund:: +Inhalte oder Vorschläge, wenn die Grundsatzentscheide lauten: + +Produktmanagement c) Offene Organisation + +Einbindung der Lieferanten: b) Lieferant als Partner + +Kostenverteilung: b) Jede und jeder für sich + +_Der obige Text kann in die Vorlage kopiert und angepasst werden._ + +Gemeinsam / - / Jede und jeder für sich:: +Inhalte oder Vorschläge, wenn die Grundsatzentscheide lauten: + +Produktmanagement b) Gemeinsame Entwicklung + +Einbindung der Lieferanten: a) oder b) (nicht relevant) + +Kostenverteilung: c) Verursacherprinzip oder d) Kostenteilung + +Gemeinsam / - / Verursacher:: +{empty} + +Das Community-Konzept sollte ein dynamisches Dokument sein, das in Absprache mit der Community angepasst werden kann. Das Konzept sollte die aktuelle Situation abbilden und künftige Entwicklungsoptionen vorschlagen. Treten später weitere Mitglieder der Community bei, so können Organisation und Prozesse weiter ausgearbeitet und komplexere Mechanismen eingeführt werden. Die folgenden Unterkapitel folgen direkt der vorgeschlagenen Struktur des Community-Konzepts (siehe Kapitel 4). + +Liegt das Produktmanagement bei Dritten, so definieren diese die Konzepte für die Community. + +=== Eckdaten + +Die folgenden Eckdaten sollten für jede Community erarbeitet und veröffentlicht werden, damit sich potenziell Interessierte für die Software und die Community anmelden können: + +* Name der Software +* Repository +* Eigentümerin +* Verantwortliche Organisationseinheit/Amt +* Kontaktadresse +* Verwendete Lizenz +* Supportstufe +* Bestehendes Projekt + +Diese Angaben lassen sich alle mit publiccode.yml abbilden.footnote:[https://yml.publiccode.tools/] + +=== Ziele + +Das Ziel sollte den eigentlichen Zweck oder die «Vision» der Anwendung enthalten. Diese Vision sollte auch in der Datei *README.md* im Repository aufgeführt werden (siehe link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung]). + +Gleichzeitig sollte auch beschrieben werden, was die Community anstrebt: + +* Wer soll beitreten? +* Wer sind die potenziell Interessierten? +* Sollen neue Mitglieder aktiv gesucht werden? +* Welches sind die Hauptziele, die mit der Veröffentlichung als Open Source verfolgt werden? + +=== Organisation und Governance + +Grundsätzlich wird bei Neuentwicklungen angestrebt, dass der Bund Inhaber der Hauptrechte am Quellcode ist. + +Die Art der Projektführung hängt davon ab, welche Organisation beim Bund die Führung hatte (SAFe, HERMES). Bei der Organisationsform ist stets ein minimaler Overhead anzustreben (bestehendes statt neues Gefäss; einfache Gesellschaft statt Verein). + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / - / Intern:: +Da der Bund die direkte Kontrolle behält, sind keine zusätzlichen Organisationsstrukturen nötig. + +Die veröffentlichende Stelle (z. B. ein Bundesamt) bleibt Eigentümerin und übernimmt sämtliche Koordinationsaufgaben. In diesem Fall kann das Kapitel «Organisation» sehr kurz gehalten werden. + +Gemeinsam / - / Intern:: +Für dieses Szenario wird in der Regel die Organisation als *einfache Gesellschaft* empfohlen. + +Damit die gemeinsame Entwicklung und die Abstimmung von Roadmap und Anforderungen möglich sind, empfiehlt es sich, zwei Gremien mit je einer teilnehmenden Person pro Community-Mitglied zu bilden: ++ +-- +* Steuerungsgremium: definiert Strategie und Priorisierung. +* Fachgruppe: erarbeitet Anforderungen und konkrete Inhalte auf Fachebene. Je nach Umfang kann auch je Thema eine eigene Fachgruppe eingesetzt werden. +-- ++ +Eigentümerin des Codes ist das Amt, das ihn veröffentlicht hat. ++ +Werden die Strukturen komplexer oder sind mehr als fünf Nutzende bzw. zusätzliche Mitglieder beteiligt, so kann es sich lohnen zu prüfen, ob die Community besser als Verein organisiert werden sollte. Vergleiche die Erläuterungen in der Variante direkt darunter. + +Gemeinsam / - / Dritte:: +Empfohlen wird die Organisation als *Verein*. + +Entweder wird eigens für die Anwendung ein Verein gegründet, oder die Anwendung wird an einen bestehenden Verein übertragen. Ein Verein wird empfohlen, weil sonst die Kostenverteilung komplex wird und innerhalb der Koordinationsaufgaben voraussichtlich genügend Arbeit anfällt, um eine Geschäftsführung in Teilzeit für den Verein anzustellen. ++ +Die Rechte am Code werden dann an den Verein übertragen, der das Community-Management und die Bestellungen bei Lieferanten übernimmt. + +Gemeinsam / Auftragnehmer / Intern:: +Empfohlen wird die Organisation als *Verein*. Entweder wird eigens für die Anwendung ein Verein gegründet, oder die Anwendung wird an einen bestehenden Verein übertragen. Ein Verein wird empfohlen, weil sonst die Kostenverteilung komplex wird und innerhalb der Koordinationsaufgaben voraussichtlich genügend Arbeit anfällt, um eine Geschäftsführung in Teilzeit für den Verein anzustellen. ++ +Die Rechte am Code werden dann an den Verein übertragen, der das Community-Management und die Bestellungen bei Lieferanten übernimmt. + +Hier sind die Lieferanten nicht Mitglieder des Vereins, sondern lediglich Auftragnehmer. Die Geschäftsführung sollte nicht von einem Lieferanten gestellt werden. + +Gemeinsam / Auftragnehmer / Dritte:: +Empfohlen wird die Organisation als *Verein*. Entweder wird eigens für die Anwendung ein Verein gegründet, oder die Anwendung wird an einen bestehenden Verein übertragen. Ein Verein wird empfohlen, weil sonst die Kostenverteilung komplex wird und innerhalb der Koordinationsaufgaben voraussichtlich genügend Arbeit anfällt, um eine Geschäftsführung in Teilzeit für den Verein anzustellen. + +Die Rechte am Code werden dann an den Verein übertragen, der das Community-Management und die Bestellungen bei Lieferanten übernimmt. + +Die Lieferanten sind Mitglieder des Vereins; die Geschäftsführung kann auch von einem Lieferanten gestellt werden. + +offen / - / Intern:: +Es besteht *kein Bedarf für eine detaillierte Beschreibung einer Organisation*, da sie bewusst offen gestaltet ist. Wichtig ist jedoch festzulegen, wer externe Anfragen entgegennimmt und bearbeitet (Verantwortung). Zudem ist zu bestimmen, ob und in welchem Umfang externe Personen einbezogen werden können: ++ +-- +* Keine direkte Einbindung: Externe können nur Vorschläge und Beiträge einreichen (als Pull Requests). +* Einbindung als Contributors: Externe, die häufig und gute Beiträge leisten, werden direkt eingebunden. +* Übergabe an Externe möglich: Tragen nach der Veröffentlichung Externe mehr zur Weiterentwicklung bei als die veröffentlichende Organisation, so kann die Anwendung auch an sie übertragen werden. +-- ++ +Die veröffentlichende Organisation bleibt Eigentümerin. Diese Variante entspricht der Organisation «klassischer» Open-Source-Projekte; siehe für weitere Informationen beispielsweise https://opensource.guide/leadership-and-governance/. + +offen / Auftragnehmer / Intern:: +Es besteht *kein Bedarf für eine detaillierte Beschreibung einer Organisation*, da sie bewusst offen gestaltet ist. Wichtig ist jedoch festzulegen, wer externe Anfragen entgegennimmt und bearbeitet (Verantwortung). Zudem ist zu bestimmen, ob und in welchem Umfang externe Personen einbezogen werden können: ++ +-- +* Keine direkte Einbindung: Externe können nur Vorschläge und Beiträge einreichen (als Pull Requests). +* Einbindung als Contributors: Externe, die häufig und gute Beiträge leisten, werden direkt eingebunden. +* Übergabe an Externe möglich: Tragen nach der Veröffentlichung Externe mehr zur Weiterentwicklung bei als die veröffentlichende Organisation, so kann die Anwendung auch an sie übertragen werden. +-- ++ +Die veröffentlichende Organisation bleibt Eigentümerin. + +Diese Variante entspricht der Organisation «klassischer» Open-Source-Projekte; siehe für weitere Informationen beispielsweise https://opensource.guide/leadership-and-governance/. + +Der Lieferant sollte nur rein technische Koordinationsaufgaben übernehmen (Code-Review, Beurteilung). + +Dritte / Partner / Intern:: +Es besteht *kein Bedarf für eine detaillierte Beschreibung einer Organisation*, da sie bewusst offen gestaltet ist. Wichtig ist jedoch festzulegen, wer externe Anfragen entgegennimmt und bearbeitet (Verantwortung). Zudem ist zu bestimmen, ob und in welchem Umfang externe Personen einbezogen werden können: ++ +-- +* Keine direkte Einbindung: Externe können nur Vorschläge und Beiträge einreichen (als Pull Requests). +* Einbindung als Contributors: Externe, die häufig und gute Beiträge leisten, werden direkt eingebunden. +* Übergabe an Externe möglich: Tragen nach der Veröffentlichung Externe mehr zur Weiterentwicklung bei als die veröffentlichende Organisation, so kann die Anwendung auch an sie übertragen werden. +-- ++ +Die veröffentlichende Organisation bleibt Eigentümerin. Diese Variante entspricht der Organisation «klassischer» Open-Source-Projekte; siehe für weitere Informationen beispielsweise https://opensource.guide/leadership-and-governance/. + +Bezüglich Governance können auch _[BITKOM2023]_ Kapitel 4.1, _[IZqCab2023]_ oder https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md#governance-models beigezogen werden. + +Beispiele für Vereinsstatuten finden sich in Anhang E. + +Hinweis: Da die Freigabe nach Art. 9 EMBAG gewährleistet sein muss, hat die Bundesverwaltung sicherzustellen, dass die Veröffentlichung nicht plötzlich zurückgezogen werden kann (siehe «Wegleitung Open Source in der Beschaffung – Softwareeinkauf nach Art. 9 EMBAG» _[BBL-WL]_, Ziffer V.2). + +=== Roadmap und Änderungsprozess + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / Auftragnehmer / -:: +Die Bundesbehörde definiert die Roadmap und entscheidet, welche Änderungen umgesetzt werden. Dafür werden die Standardprozesse des Amtes XY verwendet. + +Bund / Partner / -:: +Die Bundesbehörde definiert die Roadmap in Zusammenarbeit mit der Firma XY. Sie entscheidet, welche Änderungen umgesetzt werden. Dafür werden die Standardprozesse des Amtes XY verwendet. + +Gemeinsam / - / Intern:: +Der Prozess zur Entwicklung der Roadmap und zur Genehmigung von Änderungen ist von den Mitgliedern der Gesellschaft oder des Vereins festzulegen. Je nach Mitgliederstruktur (Anzahl, Grössenverhältnis usw.) können andere Prozesse angemessen sein. + +Die Prozesse müssen jedoch Massnahmen zur Konfliktlösung und Mehrheitsfindung enthalten. + +Gemeinsam / - / Dritte:: +Der Prozess zur Entwicklung der Roadmap und zur Genehmigung von Änderungen ist von den Mitgliedern der Gesellschaft oder des Vereins festzulegen. Je nach Mitgliederstruktur (Anzahl, Grössenverhältnis usw.) können andere Prozesse angemessen sein. ++ +Die Prozesse müssen jedoch Massnahmen zur Konfliktlösung und Mehrheitsfindung enthalten. ++ +Mit dem Zusatz, dass auch ein Kostenverteilschlüssel festzulegen ist. Zu überlegen ist zudem, wie mit der Kostenteilung für Anpassungen umzugehen ist, die von den betreffenden Mitgliedern nicht gewünscht sind. Insbesondere in Vereinen mit unterschiedlich grossen Mitgliedern können Situationen entstehen, in denen ein grosses Mitglied (z. B. die Bundesbehörde) einen erheblichen Teil der Kosten für eine Erweiterung trägt, ohne daraus einen Nutzen zu ziehen. + +offen / - / -:: +_Beispiel, nicht für alle Situationen geeignet_ + +Es besteht kein Bedarf, eine Roadmap zu erstellen; die Anwendung erfüllt die Bedürfnisse derzeit. ++ +Über Änderungen wird in einer offenen Diskussion entschieden und ein Konsens angestrebt. Der endgültige Entscheid liegt bei der Eigentümerin des Codes (Schweizerische Eidgenossenschaft). + +=== Entwicklungsprozess + +Kommt offene Entwicklung zum Tragen, so ist dies hier zu definieren. Wichtig sind die Aufgabenverteilung und die Nennung zentraler Stellen im Community-Konzept. Ebenso, wie die Sicherheit der Repository-Inhalte gewährleistet wird. + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / - / -:: +Die Committer-Rechte (Schreibzugriff auf den Code) liegen bei den vom Bund ausgewählten Personen/Stellen/Lieferanten. Nach Ablauf des Vertrags werden die jeweiligen Rechte entzogen. ++ +Die Leistungserbringer und Lieferanten sind für die Durchführung des technischen Code-Review-Prozesses für externe Beiträge verantwortlich, die vom Bund fachlich angenommen wurden. Sie sind für die technische Qualität verantwortlich. Die Lieferanten werden für diese Arbeit vom Bund entschädigt. + +Gemeinsam / Auftragnehmer / Intern:: +Grundsätzlich erhalten alle von einem Community-Mitglied beauftragten Stellen Schreibzugriff auf den Code (Committer-Rechte). Nach Ablauf des Vertrags werden die jeweiligen Rechte entzogen. ++ +Betrifft geänderter Code Kernbereiche der Anwendung, so müssen alle Änderungen von einer eigens dafür von der Community beauftragten Stelle geprüft werden. Diese Stelle ist für die technische Qualität der Anwendung verantwortlich. Sie ist zudem für die Prüfung von Änderungen zuständig, die von der Community fachlich angenommen wurden. + +Gemeinsam / Partner / Dritte:: +Die Committer-Rechte (Schreibzugriff auf den Code) liegen bei den Mitgliedern der Community. Diese Personen organisieren sich selbst und tragen gemeinsam die Verantwortung für die Qualität des Codes. ++ +Beauftragt ein Community-Mitglied einen externen Lieferanten für eine Anpassung oder Erweiterung, so wird die Anpassung von einem Mitglied der Community geprüft. Es wird dafür vom Auftraggeber entschädigt. ++ +Änderungen am Kern der Anwendung müssen von einem zweiten Mitglied der Community geprüft werden. ++ +Die Lieferanten, die Community-Mitglieder sind, sind zudem für die Prüfung externer Beiträge und neuen technischen Codes verantwortlich, der vom Verein fachlich angenommen wurde. + +offen / - / -:: +Anfänglich liegen die Committer-Rechte bei den Entwickelnden oder ihren Arbeitgebern. Committer-Rechte werden allen Entwickelnden erteilt, die während mehrerer Monate aktiv zum Projekt beitragen und angemessene Sozialkompetenz zeigen. ++ +Die einzelnen Entwickelnden behalten ihre Committer-Rechte grundsätzlich, auch wenn sie den Arbeitgeber wechseln oder der Bund einen anderen Lieferanten wählt. Committer-Rechte erlöschen nur, wenn sie freiwillig abgegeben werden oder die Mehrheit der übrigen Committer deren Entzug beschliesst. ++ +Der Bund hat das Recht, einzelne Entwickelnde der von ihm beauftragten Unternehmen als Committer zu benennen. Er hat nicht das Recht, jemandem die Committer-Rechte ohne Grund zu entziehen. ++ +Code-Reviews werden von mindestens einer Person durchgeführt, die als Committer tätig ist. Die Committer organisieren sich selbst. ++ +Der Bund verpflichtet sich, die Review-Arbeit zu entschädigen, soweit dies für ihn finanziell machbar ist. + +=== Kostenteilung und Lieferanten + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / Auftragnehmer / Intern:: +Die Lieferanten werden periodisch über WTO-Ausschreibungen oder ein freihändiges Verfahren ausgewählt (je nach Umfang der Wartungsleistungen). + +Bund / Partner / -:: +*Wichtig:* Vorgängig prüfen, ob dies im konkreten Fall beschaffungsrechtlich zulässig ist. ++ +Wir werden die Dokumentation zu diesem Punkt ergänzen. Der Bund wählt den Lieferanten XXX als strategischen Partner und strebt eine langfristige Zusammenarbeit an. + +Gemeinsam / Auftragnehmer / Intern:: +Jedes Mitglied der Community beauftragt eigenständig einen oder mehrere Softwarelieferanten mit der Umsetzung der von ihm benötigten Anpassungen und Erweiterungen. Für Anpassungen, die von mehreren Mitgliedern gewünscht werden, wird die Kostenteilung im Einzelfall vereinbart. Das Mitglied mit dem grössten Kostenanteil ist für die Auswahl und Beauftragung des Lieferanten verantwortlich. (Regelungen zur Softwarewartung) + +Gemeinsam / Auftragnehmer / Dritte:: +Der Verein wählt die Softwarelieferanten periodisch zentral über WTO-Ausschreibungen oder freihändige Verfahren aus (je nach Umfang der Wartungsleistungen). Die Kosten werden den Mitgliedern nach einem Schlüssel zugewiesen: (festzulegen: nach Bevölkerung, Nutzenden usw.) + +Gemeinsam / Partner / Intern:: +Jedes Mitglied der Community beauftragt eigenständig einen oder mehrere Softwarelieferanten mit der Umsetzung der von ihm benötigten Anpassungen und Erweiterungen. Für Anpassungen, die von mehreren Mitgliedern gewünscht werden, wird die Kostenteilung im Einzelfall vereinbart. Das Mitglied mit dem grössten Kostenanteil ist für die Auswahl und Beauftragung des Lieferanten verantwortlich. ++ +_(Regelungen zur Softwarewartung)_ Nötigenfalls ergänzt durch einen Beitrag der beteiligten Lieferanten. Beispiel: _Jedes Softwareentwicklungsunternehmen, das Mitglied der Community ist, verpflichtet sich, jährlich mindestens XY Arbeitstage auf eigene Kosten in die Weiterentwicklung, die technologische Aktualisierung oder das Marketing der Anwendung zu investieren._ + +Gemeinsam / Partner / Dritte:: +Der Verein wählt die Softwarelieferanten periodisch zentral über WTO-Ausschreibungen oder freihändige Verfahren aus (je nach Umfang der Wartungsleistungen). Die Kosten werden den Mitgliedern nach einem Schlüssel zugewiesen: (festzulegen: nach Bevölkerung, Nutzenden usw.) Nötigenfalls ergänzt durch den Zusatz: _Jedes Softwareentwicklungsunternehmen, das Mitglied der Community ist, verpflichtet sich, jährlich mindestens XY Arbeitstage auf eigene Kosten in die Weiterentwicklung, die technologische Aktualisierung oder das Marketing der Anwendung zu investieren._ + +Dritte / Auftragnehmer / -:: +Die Lieferanten werden periodisch über WTO-Ausschreibungen oder ein freihändiges Verfahren ausgewählt (je nach Umfang der Wartungsleistungen). Mit dem Zusatz: _Die von potenziellen Lieferanten beigetragenen Verbesserungen und Aktivitäten in der Community werden als Faktor in der Bewertung berücksichtigt._ ++ +Von Externen gewünschte Änderungen werden nicht vom Bund finanziert, sondern müssen von diesen selbst in Auftrag gegeben und bezahlt werden. + +Dritte / Partner / -:: +Die Lieferanten werden periodisch über WTO-Ausschreibungen oder ein freihändiges Verfahren ausgewählt (je nach Umfang der Wartungsleistungen). Mit dem Zusatz: _Die von potenziellen Lieferanten beigetragenen Verbesserungen und Aktivitäten in der Community werden als Faktor in der Bewertung berücksichtigt. Von Externen gewünschte Änderungen werden nicht vom Bund finanziert, sondern müssen von diesen selbst in Auftrag gegeben und bezahlt werden._ + +=== Marketing + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / Auftragnehmer / -:: +Der Bund vermarktet die Anwendung nicht aktiv, veröffentlicht sie aber auf Open-Source-Softwareplattformen. Die Veröffentlichung der Anwendung wird in Fachgremien bekannt gegeben. Melden sich Interessierte, so prüfen wir, ob eine gemeinsame Community aufgebaut oder mit deren Version der Software weitergearbeitet wird. + +Gemeinsam / Partner / -:: +Zusätzlich: + +Lieferanten dürfen die Anwendung vermarkten und weitere Interessierte suchen. Der Bund darf als Referenz genannt werden. Wir nehmen bewusst in Kauf, dass dadurch abweichende Versionen der Software entstehen können. + +Gemeinsam / Auftragnehmer / Intern:: +Die Anwendung wird von den Mitgliedern oder vom Verein vermarktet. + +Gemeinsam / Partner / Intern:: +Die Anwendung wird von den Lieferanten vermarktet. + +Gemeinsam / - / Dritte:: +Die Anwendung wird vom Verein, von der einfachen Gesellschaft und deren Mitgliedern vermarktet. + +offen / - / -:: +Die Anwendung darf von Lieferanten vermarktet werden, oder es kann auf explizites Marketing verzichtet werden. ++ +Alternative ohne explizites Marketing: Der Bund vermarktet die Anwendung nicht aktiv, veröffentlicht sie aber auf Open-Source-Softwareplattformen. In Fachgremien weisen wir darauf hin, dass wir die Anwendung veröffentlicht haben und dass eine Zusammenarbeit willkommen ist. Wir zeigen Interessierten die Software und versuchen, sie in unsere Prozesse zur Gestaltung der Roadmap einzubinden. + +=== Umgang mit externen Beiträgen + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Bund / Auftragnehmer / -:: +Externe Beiträge und Anfragen müssen auch dann bearbeitet werden, wenn der Bund alleiniger Entscheidträger bezüglich der Software bleibt (ausser bei minimaler Freigabe, wo ein Fork unvermeidlich ist). Wir schlagen folgendes Vorgehen vor: ++ +*Umgang mit gemeldeten Fehlern* + +Wir versuchen, von externen Personen gemeldete Fehler zu reproduzieren, und fragen nötigenfalls nach. Gelingt die Reproduktion, so gibt der Bund die Fehlerbehebung in Auftrag. Lässt sich der Fehler nicht verifizieren oder ist der Aufwand zu dessen Behebung unverhältnismässig hoch, so entschuldigen wir uns bei der meldenden Person und fragen, ob sie einen Pull Request zur Behebung einreichen könnte. ++ +*Umgang mit Anfragen* + +Wir beantworten jede eingehende Anfrage. Lässt sich eine Anfrage nicht mit vertretbarem Aufwand klären und erscheint ein weiterer Zeiteinsatz ineffizient, so entschuldigen wir uns unter Hinweis auf beschränkte Ressourcen und bieten an, die anfragende Person für die weitere Beratung mit einem Lieferanten in Kontakt zu bringen. ++ +*Umgang mit Pull Requests* + +Wir prüfen jeden Pull Request sorgfältig. Um unnötigen Aufwand auf Seiten der beitragenden Person zu vermeiden, weisen wir sofort darauf hin, wenn etwas unserer Roadmap widerspricht oder fraglich ist, ob wir den Beitrag annehmen. Der Bund entscheidet eigenständig und nach fachlichen Kriterien, welche Beiträge er annimmt. Fehlerkorrekturen, die den Review-Prozess bestanden haben, werden immer angenommen. ++ +*Umgang mit Forks* + +Wir unterstützen Forks unserer Anwendung. Wer die Anwendung einführt, sollte einen eigenen Fork erstellen. Wir prüfen die entstehenden Forks mindestens einmal jährlich und übernehmen gute und passende Erweiterungen. + +Gemeinsam / - / -:: +Extern bezeichnet Beiträge von ausserhalb der definierten Community (Vereinsmitglieder). Abweichungen von oben: + +*Umgang mit Forks* + +Wir wollen (langlebige) Forks der Anwendung verhindern. Interessierte sollen stattdessen der Community direkt beitreten. Innerhalb der Community versuchen wir sicherzustellen, dass alle Mitglieder die Hauptversion nutzen. + +Offen / - / -:: +Der Aufbau einer funktionierenden Community und einer offenen Kultur ist uns wichtig. ++ +*Umgang mit gemeldeten Fehlern* + +Wir versuchen, gemeldete Fehler zu reproduzieren und zu beheben. Wir setzen die aktive Mitwirkung der meldenden Personen voraus. Wenn möglich sollten sie direkt einen Pull Request mit einer Fehlerkorrektur erstellen. ++ +*Umgang mit Anfragen* + +Wir behandeln jede Anfrage innerhalb von höchstens einer Woche. Anfragen aktiver Beitragender werden mit Priorität und vertieft behandelt. Wir versuchen, andere Mitglieder in die Bearbeitung von Anfragen einzubeziehen. ++ +*Umgang mit Pull Requests* + +Wir wollen möglichst viele qualitativ hochwertige Pull Requests erhalten. Wir beziehen alle aktiven Beitragenden in die Reviews und die technische und fachliche Beurteilung von Pull Requests ein. Bei umstrittenen Beiträgen versuchen wir, über eine informelle Abstimmung zu einem Entscheid zu gelangen. ++ +*Umgang mit Forks* + +Wir versuchen, Forks durch aktives und offenes Community-Management unnötig zu machen. Entstehen dennoch Forks, so prüfen wir diese aktiv und versuchen, die dort entwickelten Erweiterungen und Verbesserungen zu übernehmen. In solchen Fällen fordern wir aktiv Pull Requests an. + +Allgemein ist festzuhalten, dass Beiträge von der Unterstützung anderer Nutzender bis zur Übernahme der Verantwortung für ganze Teile eines Projekts reichen können (siehe _[BITKOM2023]_ Kapitel 4.2). + +=== Betrieb der Anwendung + +_Produktmanagement / Lieferant als / Entwicklung -- Vorschlag_ + +Gemeinsam / - / -:: +Ein zentraler Betrieb kann optional zusätzlich vom zentralen Verein angeboten werden, im Sinne von Software as a Service (SaaS). Es ist zu prüfen, ob dies gewünscht ist. + +- / Partner / -:: +Es ist festzulegen, ob der Lieferant die Software auch betreiben soll. + +- / Führung / -:: +Es ist festzuhalten, dass der Lieferant für den Betrieb verantwortlich ist. + +Supportstufen und Supportkontakte sollten in diesem Kapitel ebenfalls festgelegt werden. + +== Wichtige Informationen für Community-Managerinnen und -Manager + +=== Es braucht Zeit + +Der Aufbau von Communities ist etwas, das langfristig geplant werden sollte. Ausdauer und Beständigkeit sind zwei wichtige Eigenschaften für eine erfolgreiche Community. + +=== Weitere Anregungen zum Community-Aufbau + +Weitere Anregungen für ein gutes Community-Management finden sich unter https://opensource.guide/code-of-conduct/ und https://opensource.guide/best-practices/. + +=== Kommunikation + +Die Veröffentlichung von Software und Dokumentation eröffnet der Bundesverwaltung einen neuen Kommunikationskanal. Geschieht dies nicht sorgfältig und professionell, so kann das öffentliche Ansehen des Bundes leiden. + +OSS-Communities in der Bundesverwaltung stehen bezüglich Kommunikation in einem Spannungsfeld: Einerseits gelten die allgemeinen *Vorgaben für die Kommunikation*, andererseits soll die Community eine *einfache formelle und informelle Zusammenarbeit* über Organisationsgrenzen hinweg ermöglichen, vorzugsweise ohne formelle Qualitätskontrollen und Freigaben. + +Die Nutzung öffentlicher Repositories und allenfalls öffentlicher Issue-Trackings und Wikis bedeutet, dass Äusserungen einzelner Projektmitarbeitender ungefiltert für die Öffentlichkeit sichtbar sind. Dies verlangt von den Projektmitarbeitenden ein professionelles Auftreten und die Einhaltung von Qualitätsstandards für Veröffentlichungen in solchen Umgebungen. + +In OSS-Projekten wird dies normalerweise über den *Code of Conduct* geregelt. Der Verhaltenskodex der Bundesverwaltungfootnote:[https://www.epa.admin.ch/dam/epa/de/dokumente/aktuell/medienservice/120_verhaltenskodex_d.pdf.download.pdf/120_verhaltenskodex_d.pdf] ist sehr allgemein gehalten, doch der Kerngrundsatz ist hier anwendbar: «Die Mitarbeitenden erfüllen ihre Aufgaben verantwortungsbewusst, integer und loyal. Auch im Privatleben achten sie darauf, das Ansehen, die Glaubwürdigkeit und das Image des Bundes nicht zu beeinträchtigen.» + +=== Offene Entwicklung + +Ist die Softwareentwicklung von Anfang an in einem offenen Repository geplant, so erfolgt die Freigabe automatisch. Die massgebenden Checklisten nach der Anleitung link:em002-2.pdf[Em002-2] sind zu Beginn auszufüllen, und die Entwicklungsprozesse des Leistungserbringers bzw. Lieferanten müssen dies zulassen. Der Vorteil ist, dass die Community von Anfang an aufgebaut werden kann. Mehrere Organisationen können zudem gemeinsam an der Entwicklung mitwirken. + +Geschlossene Repositories sind eine Zwischenform, werden aber für andere Partner in einer Zusammenarbeit eingesetzt. + +=== Benutzerverwaltung + +Das Projekt (oder die Trägerorganisation) legt fest, ob Entwickelnde und andere Projektmitarbeitende unter eigenem Namen oder anonym am Projekt arbeiten. Arbeiten die Personen nicht anonym und verfügen sie bereits über Logins auf den Plattformen, so ist es am einfachsten, diese zu verwenden (ob geschäftlich oder privat). + +Die Plattform sollte grundsätzlich die Einbindung Dritter erlauben, da sonst keine Entwickelnden ausserhalb des Bundes mitarbeiten können. + +Beim Verlassen des Projekts sind die entsprechenden Rechte am Projekt zu löschen. Dafür ist das Produktmanagement verantwortlich. + +=== Zusammenführung von Communities + +Wo möglich sollte die Zahl der Communities klein gehalten werden. Das bedeutet: + +* Besteht bereits eine Community, in der für ähnliche Probleme mit denselben Personen eine ähnliche Struktur vorgesehen ist, so sollte eine einzige Community genutzt werden. +* Mehrere Projekte, die zusammenhängen und dieselbe Zielgruppe ansprechen, können zu einer Community zusammengeführt werden. +* Es sollten nicht unnötig grundlegend andere Community-Strukturen geschaffen werden, wo bereits bestehende vorhanden sind. + +=== Umgang mit Beiträgen Dritter + +Der Beitrag von Software an andere Projekte wird in Kapitel 3.3 behandelt. Die gleichen Grundsätze gelten umgekehrt. + +Wichtig sind die folgenden Punkte: + +* Es muss ein geeignetes Contributor Licence Agreement verwendet werden, um sicherzustellen, dass der Quellcode anschliessend dem Bund gehört (siehe auch link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung], Kapitel zu den Contributor Licence Agreements). Dieses ist von der Eigentümerin bzw. dem Eigentümer des Beitrags zu unterzeichnen. +* Bestätigungen sind abzulegen. +* Beiträge sind vor der Integration in die Codebasis zu prüfen. +* Eingaben sollten zeitnah beantwortet (Issues, Requests, Pull Requests) und möglichst konstruktiv behandelt werden. +* Sämtliche Kanäle und Governance-Regelungen sollten im Community-Konzept, auf der Website und im Repository aufgeführt werden. + +=== Sicherheitsrelevante Meldungen + +Neben üblichen Fehlermeldungen ist – wo es die Art des Projekts erfordert – vorzusehen, dass sicherheitsrelevante Schwachstellen vertraulich gemeldet werden können, wie dies beispielsweise bei einem Bug-Bounty-Programm der Fall ist. + +Als Beispiel können die Dokumente von trustbroker.swiss dienen: + +* https://github.com/trustbroker-swiss/trustbroker.swiss/blob/main/Security-and-Vulnerability-Disclosure.md + +=== Forks vermeiden + +Forks sind in der Open-Source-Welt zwar natürlich, doch ist die Wiedereingliederung von Quellcode, Funktionen usw. aus Forks alles andere als einfach. Es kann sich lohnen, auf die Personen oder Organisationen zuzugehen, die einen Fork erwägen, und zu versuchen, sie im Hauptprojekt zu halten. Ein Ausgleich zwischen konkurrierenden Interessen ist in solchen Fällen oft nötig. + +=== Kostenaufteilung + +Es ist sinnvoll, zwischen den Hauptpartnern allgemeine Verteilschlüssel zu vereinbaren. Diese können alle paar Jahre oder bei grundlegender Änderung der Situation angepasst werden. Für eine effiziente Arbeit an der Software sollten die grossen Partner tendenziell etwas grössere Anteile übernehmen, als sie eigentlich müssten (nötigenfalls auch die Gesamtkoordination). Die Organisation soll arbeiten und nicht über Finanzen streiten. Erstreckt sich die Zusammenarbeit über mehrere Projekte (beispielsweise die Branchenlösungen im Bereich Normalspurbahnen), so sollte für alle Projekte ein einheitlicher Verteilschlüssel verwendet werden. Aus Sicht der Bundesbehörden ist es eine Verbesserung, wenn die Kosten nicht allein getragen werden müssen. + +Mögliche Kriterien für Verteilschlüssel: + +* Abschätzung der Nutzenverteilung (z. B. zwischen Bundesbehörde und einem Lieferanten, der auf weitere Kundschaft hofft) +* Zahl der Einwohnenden/Nutzenden (z. B. zwischen Ämtern, Gemeinden, Städten) +* Finanzkraft (z. B. Kantone) +* Bruttoinlandprodukt (z. B. zwischen Kantonen) +* Wer mehr Kontrolle will + +Um Diskussionen zu vermeiden, sollte der Verteilschlüssel nicht einfach an das Jahresbudget gekoppelt werden. Eine Klausel im Sinne des Verursacherprinzips kann für einzelne Partner raschere Anpassungen ermöglichen, wenn sie bereit sind, zusätzlich zu zahlen. + +Der Verteilschlüssel sollte auch für Gemeinkosten, Wartung/Support und ein Minimum an Weiterentwicklung gelten. Diese Teile sollten wenn möglich langfristig gelöst werden. + +Zu bedenken ist, dass bei Drittfinanzierung die betreffenden Parteien typischerweise mehr Mitsprache wollen. Das Community-Management muss darauf vorbereitet sein. + +=== Ergänzende Leistungen nach Art. 9 Abs. 5 und 6 EMBAG + +Die Bundesbehörden können (selbst, über Leistungserbringer oder Lieferanten) ergänzende Leistungen erbringen, insbesondere für Integration, Wartung, Sicherstellung der Informationssicherheit und Support. + +Die Einschränkung ist, dass sie den Aufgaben der Behörden dienen und mit verhältnismässigem Aufwand erbracht werden können. + +Daraus folgt, dass die Bundesbehörde nicht das Entwicklungsunternehmen für Dritte sein kann. Sie behebt Fehler, kann sicherheitsrelevante Aspekte behandeln, kann etwas Support und Integrationshilfe leisten (alles Tätigkeiten, die dem Aufbau einer Community dienen). Neuentwicklungen und zusätzliche Funktionen für Dritte sollten sich in erster Linie am normalen Arbeitszweck der Behörde orientieren. Selbstverständlich kann es sein, dass die Bereitstellung der Software Teil der Aufgabe ist; in diesem Fall können jederzeit Entwicklungen erfolgen. Festgehalten wird zudem, dass die Softwareentwicklung nicht die Kernaufgabe der Bundesbehörde ist. + +Das bedeutet: Werden Funktionen im Wesentlichen ausschliesslich für Dritte entwickelt, so sind sie partnerschaftlich oder über den Lieferanten zu integrieren. + +Um beschaffungsrechtliche Probleme zu vermeiden, ist bei der Beschaffung von Software und Leistungen darauf zu achten, dass Funktionen Dritten (allenfalls nur staatlichen Dritten) durch Lieferanten bereitgestellt werden können. + +Die Festlegung von Gebühren wurde bereits im Kapitel «Support» angesprochen. Das EMBAG ist bereits die gesetzliche Grundlage für solche Gebühren. Diese sind auf der Website der jeweiligen Bundesbehörde zu kommunizieren. Beispiele sind in Anhang G aufgeführt. + +Art. 9 Abs. 6 hält fest, dass der Privatwirtschaft normalerweise keine Konkurrenz gemacht werden soll. Das bedeutet, dass die Gebühren nicht zu tief angesetzt werden und mindestens kostendeckend sein sollten. Im Zweifelsfall sind Stundensätze eher zu hoch als zu tief anzusetzen. + +Generell wird empfohlen, mit ein bis drei verschiedenen Standardstundensätzen zu arbeiten. + +Will ein Bundesdepartement Ausnahmen zu Abs. 6 festlegen, so darf dies der Privatwirtschaft keine Konkurrenz machen. Unter Umständen ist es am einfachsten, die Gebühren festzulegen und sie zu erhöhen, falls Widerstand von Privatunternehmen entsteht, welche die Leistung tatsächlich anbieten können. + +=== Digitale Souveränität + +Solange der Bund kein eigenes Repository hat, wird zur Sicherstellung der digitalen Souveränität empfohlen, regelmässig Kopien öffentlicher Repositories zu erstellen. + +Zu beachten ist, dass nicht nur der Quellcode, sondern auch weitere Informationen wie Issue-Tracking, Wiki, Konfigurationen usw. kopiert werden. + +Zudem ist die Benutzerverwaltung zu lösen, um die Kontrolle über den veröffentlichten Quellcode sicherzustellen. Übergeordnetes Ziel ist es, eine von der jeweiligen Plattform unabhängige Entwicklung zu gewährleisten und der Community einen Wechsel zu ermöglichen.footnote:[Siehe auch https://www.bfh.ch/de/aktuell/news/2024/neue-studie-digitale-souveraenitaet/] + +== Anhang + +=== Änderungen gegenüber der Vorversion + +* Kapitel 1 «Das Wichtigste auf einen Blick» ergänzt +* Zweck der Community in Kapitel 3 ergänzt +* Kapitel 3.1 bis 3.3 zur Zusammenarbeit ergänzt +* Neues Kapitel 7.7 Umgang mit Beiträgen Dritter +* Festgehalten, dass Lieferanten nicht vollständig eigenständig veröffentlichen sollen (nach _[BBL-WL]_, V.2) +* Publicode.yml erwähnt +* Abstimmung mit dem neuen link:em002-7.pdf[Em002-7] +* Weitere redaktionelle Änderungen und Verbesserungen + +=== Referenzen + +Siehe _Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung_. + +=== Abkürzungen + +Siehe link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] und link:em002-6.pdf[Em002-6 FAQ zu OSS]. + +=== Beispiele bestehender Community-Konzepte + +Im Sinne einer Sammlung von Best Practices folgen nachstehend Community-Konzepte und vergleichbare Dokumente, die bereits erarbeitet wurden. Dies sind nicht zwingend nur Konzepte von Bundesbehörden, sondern auch von anderen Organisationen. + +* GERES Community (http://geres-community.ch) + +Einordnung: + +* Produktmanagement a) Gemeinsame Entwicklung +* Lieferant eher a) Auftragnehmer +* Kostenverteilung: b) Kostenteilung + +Hinweis: Das Gemeinderegister GERES ist nicht Open Source, doch viele Aspekte der Organisation können auch für Open-Source-Anwendungen relevant sein. Dokumente: Statuten (öffentlich) und Geschäftsordnung (auf Anfrage). + +* https://www.igovportal.ch[iGov Portal] + +#Dieses Kapitel enthält derzeit Konzepte des Kantons Bern und wird ergänzt, sobald Beispiele des Bundes verfügbar sind.# + +=== Beispiele von Zusammenarbeiten + +Die folgenden Beispiele zeigen, wie Zusammenarbeiten strukturiert wurden. + +=== Zusammenarbeit: ZenDiS in Deutschland + +ZenDiSfootnote:[https://www.zendis.de/en[ZenDiS-Website: Co-creating Digital Sovereignty]] ist eine Organisation, deren Ziel es ist, die Abhängigkeit in der öffentlichen Verwaltung (primär in Deutschland) durch die Förderung von Open-Source-Software zu verringern. + +[mermaid,align="center",alt="Ziele und Ansätze zur Stärkung der digitalen Souveränität (ZenDiS)"] +.... +block-beta + columns 12 + H1["Ziele"]:12 + G1["I. Wechselmöglichkeit"]:4 G2["II. Gestaltungsfähigkeit"]:4 G3["III. Einfluss auf Anbieter"]:4 + H2["Lösungsansätze"]:12 + B1["1. Vorausschauende Analyse
und Steuerung von
Abhängigkeiten"]:3 B3["3. Herstellerunabhängige
Modularität, (offene) Standards
und Schnittstellen in der IT"]:3 B5["5. Kooperative Mitgestaltung
von IT-Lösungen"]:3 B7["7. Rechtliche Vorgaben"]:3 + B2["2. Beschaffung bzw. Entwicklung
alternativer IT-Lösungen
(z. B. OSS)"]:3 B4["4. Aufbau digitaler Kompetenzen
und Expertenwissen"]:3 B6["6. Gemeinsames Verständnis
und Vorgehen"]:3 B8["8. Politische Steuerung"]:3 + classDef highlight fill:#dae8fc,stroke:#000000,color:#000000 + class B2 highlight +.... + +Abbildung 1: Ziele und Ansätze zur Stärkung der digitalen Souveränität (ZenDiS) + +ZenDiS arbeitet dazu mit strategischen Partnern zusammen. + +Eine Zusammenarbeit zwischen der Bundesverwaltung und ZenDiS dürfte daher kaum uneingeschränkt möglich sein, und eine Koordination wäre nicht verbindlich. Dies kann sich mit der Zeit ändern. + +Konkret müsste die Bundesverwaltung eine eigene Organisation für die Schweiz aufbauen und sich informell mit ZenDiS abstimmen. Dies könnte allenfalls über eOperations erfolgen, wobei eOperations erst tätig wird, wenn ein konkreter Bedarf angemeldet und ein Budget bereitgestellt wird. Eine Begründung für eine solche Parallelorganisation liesse sich im Kontext von E-Government oder EMBAG finden. + +Hinweis: ZenDiS untersteht dem EU- bzw. deutschen Beschaffungsrecht. Es bestehen erhebliche Unterschiede zur Schweiz. ZenDiS lässt sich daher nicht eins zu eins in der Schweiz nachbilden, und eine Zusammenarbeit mit ZenDiS ist nicht ohne Weiteres möglich. + +=== Zusammenarbeit: Open Trip Planner (OTP) + +Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] ist eine Open-Source-Anwendung für die Reiseplanung. Sie ist als Projekt der Software Freedom Conservancy in New York organisiert. Einzelne Entwickelnde sind bei Verkehrsunternehmen und Lieferanten angestellt. Bemerkenswert ist, dass ein Akteur der öffentlichen Hand – konkret ENTURfootnote:[https://entur.no/] – eine der führenden Rollen übernommen hat. ENTUR entwickelt primär für den eigenen Bedarf, hat aber auch einen Kooperationsfokus, insbesondere für die nordischen Länder. ENTUR ist als Unternehmen im Eigentum des norwegischen Verkehrsministeriums organisiert. Als grösster Akteur übernimmt ENTUR auch einen erheblichen Teil der Koordinationskosten. Alle können Feature-Wünsche einreichen; diese werden in Koordinationssitzungen diskutiert und entwickelt, wenn jemand sie finanziert. Die Finanzierung erfolgt primär pro Feature durch die interessierte Partei bzw. die interessierten Parteien. Im Kern trägt jede Partei ihre eigenen Kosten. Supportleistungen müssten in der Schweiz zudem separat ausgeschrieben werden. + +=== Neue vom Bund angestossene Zusammenarbeit: Swiss Trust Broker + +Der Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] ist eine Software des Bundes für eIAM, die als Open Source verfügbar ist. Die Entwicklung erfolgt durch den Bund. Mehrere Kantone haben entschieden, sie entweder direkt als SaaS oder mit eigenen Instanzen einzusetzen. Da sie unter der AGPL-Lizenz verfügbar ist, kommen vorgenommene Erweiterungen wiederum dem Bund zugute. Aufgrund ihrer sicherheitskritischen Natur erfolgt die Entwicklung für die Bundesverwaltung ausschliesslich durch den Bund. Andere Organisationen können Anforderungen einreichen, die umgesetzt werden, wenn das Projektteam sie als angemessen erachtet. + +=== Neue von den Kantonen angestossene Zusammenarbeit: inosca + +Über inoscafootnote:[https://inosca.ch/] haben mehrere Kantone eine Entwicklungsgemeinschaft für elektronische Bewilligungen aufgebaut, die ihren Ursprung im Projekt eBau hat.footnote:[https://github.com/inosca/ebau] eBau umfasst auch Caluma,footnote:[https://github.com/projectcaluma] ein Framework für die gemeinsame Bearbeitung – ein Beispiel für eine Komponente, die aus einer breiteren Lösung herausgelöst und zu einem eigenständigen, breit anwendbaren Framework entwickelt wurde. Dieses kann auch in anderen Projekten genutzt werden, selbst wenn einzelne Teile Ausnahmebedingungen unterliegen, sodass möglichst viele andere Stellen vom Code profitieren können. + +Die Community trifft sich mindestens einmal monatlich (optional zweimal), um sich über technische Themen auszutauschen und die gemeinsame Roadmap zu planen. Alle Beteiligten können Themen einbringen. Wird ein Thema als für die Community relevant erachtet, so melden sich interessierte Kantone und organisieren sich in einer Arbeitsgruppe. Die Ergebnisse fliessen laufend an die Community zurück. inosca arbeitet nach einem Grundprinzip: Wer gestaltet, finanziert. Das heisst, alle an einer Arbeitsgruppe beteiligten Kantone teilen sich die Kosten der neuen Funktion. Die Funktion wird ausgeschrieben und die Kosten werden nach einer vordefinierten Kostenteilungsformel unter der Community aufgeteilt. Sobald eine Funktion fertiggestellt und eingeführt ist, steht sie sofort allen anderen Kantonen frei zur Verfügung. + +Die Community hat zusätzlich entschieden, einen bescheidenen festen Jahresbetrag für die administrativen Kosten des Community-Betriebs zurückzustellen. Dieses Budget wird jedes Jahr den Parteien zugewiesen, die eine organisatorische Rolle übernehmen. + +=== SNOWPACK der WSL – direkte Beiträge von Entwickelnden + +SNOWPACKfootnote:[https://snow-models.gitlab-pages.wsl.ch/snowpack-web/] ist ein Open-Source-Projekt der WSL zur Modellierung der Schneedeckenbildung. Es handelt sich um ein hochspezialisiertes Modell, und die Community wurde entsprechend in die bestehende Fachgemeinschaft integriert. Einzelne Issues sind bereits als mögliche Beiträge vorgemerkt. Das Arbeitsmodell ist hier, dass jede Partei ihre eigenen Kosten trägt und Funktionen beisteuert. Richtlinien zu Coding Style und Release-Prozess sind in diesem Zusammenhang ebenfalls dokumentiert. + +=== Anregungen für Vereinsstatuten + +Die Statuten sollten so einfach wie möglich gehalten werden. + +Die folgenden Statuten können als Anregung dienen. + +* 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 + +#Weitere Beispiele von Statuten werden ergänzt, sobald sie verfügbar sind.# + +=== Beispiele für Support und Gebühren + +* Gebühren für statistische Dienstleistungen: https://www.fedlex.admin.ch/eli/cc/2003/326/de[https://www.fedlex.admin.ch/eli/cc/2003/326/de] +* Gebühren des EDÖB: https://www.edoeb.admin.ch/edoeb/de/home/datenschutz/grundlagen/dsfa.html +* Kostenlose Leistungen des IGE für Kurse im Bereich des geistigen Eigentums (nicht Software, aber als Beispiel): https://www.ige.ch/de/dienstleistungen/ip-academy/allgemeine-informationen/preise + +Beispiele werden ergänzt, sobald sie verfügbar sind. +endif::[] + +ifeval::["{lang}" == "fr"] +NOTE: 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 {url-repo}/tree/main[README] principal. + +== L'essentiel en bref + +Les points les plus importants du document sont énumérés ci-après. + +* La constitution ou l'exploitation d'une communauté OSS *n'est pas exigée* par l'art. 9 LMETA. +* Une communauté est pertinente lorsqu'un groupe d'utilisateurs a du sens et que des *synergies* avec d'autres utilisateurs du logiciel doivent être créées. +* Une communauté ne se limite pas au logiciel lui-même, mais peut aussi englober les processus environnants et la standardisation des données. +* La constitution d'une communauté implique toujours un *effort initial*. Celui-ci se poursuit en règle générale. Dans de nombreux cas, il est judicieux que l'office pilote supporte également les coûts de coordination. +* Les communautés doivent remplir un *but*. Il faut des personnes intéressées et des participants. +* Une communauté peut émerger puis être formalisée. +* L'objectif de la communauté est d'accroître le *bénéfice pour tous*. Principe général : « on récupère au moins autant que ce que l'on apporte ». +* La communauté devrait être *structurée aussi simplement que possible*. +* Dans un premier temps, la communauté devrait être brièvement examinée à l'aide de la liste de contrôle link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Ce n'est que si elle est pertinente qu'elle devrait être développée. +* La formalisation s'effectue au moyen d'un *concept de communauté*. Il convient de reprendre autant que possible des sources existantes. Principe général : « ne pas réinventer la roue ». +* Si une collaboration est visée, cela doit être pris en compte dès le tout début du projet, car les partenaires potentiels devraient déjà être associés lors de l'analyse des exigences. Cela doit aussi être bien planifié dès le départ sur le plan juridique et sous l'angle du droit des marchés publics. +* Les possibilités d'adhérer à une collaboration existante doivent être examinées sur le plan juridique et sous l'angle du droit des marchés publics. +* Aucune communauté ne doit être constituée pour des contributions. Toutefois, si le projet l'exige, le *Contributor Licence Agreement (CLA)* correspondant doit être signé, ou les développeurs doivent être autorisés par le projet à soumettre le logiciel sous un Developer Certificate of Origin (DCO). + +== Introduction + +Le présent guide s'adresse aux spécialistes TIC responsables d'une application qui souhaitent la proposer en open source ou contribuer à une telle application. + +Cela doit être organisé soit formellement, soit informellement. + +Le présent document fournit des informations importantes pour l'organisation et la constitution d'une communautéfootnote:[La communauté d'un projet open source représente typiquement une pyramide. + +La base de cette pyramide est constituée des utilisateurs du logiciel, en particulier ceux qui s'engagent et participent activement à la communauté, par exemple sous forme de signalements d'erreurs et de demandes de fonctionnalités ou par des contributions à des listes de diffusion. + +Directement au-dessus, dans la pyramide, se trouvent les contributeurs. Il s'agit de parties de la communauté qui proposent leurs propres contributions de code. Ils n'ont typiquement pas d'accès en écriture au dépôt. Leurs contributions sont examinées par les mainteneurs du projet et intégrées au dépôt après avoir atteint la qualité propre au projet. + +Au sommet de la pyramide se trouvent les mainteneurs ou committers d'un projet. Dans ce rôle, un développeur assume une responsabilité accrue. Cela se traduit par exemple par la possibilité d'accepter des contributions. Ce droit se manifeste souvent par un accès en écriture au dépôt. À ce niveau s'exerce le contrôle du logiciel, de sa qualité et de son étendue fonctionnelle. Dans les projets plus complexes, ce niveau peut être subdivisé. Ainsi, le noyau Linux compte notoirement des mainteneurs de sous-systèmes à plusieurs niveaux, et en définitive un seul développeur, Linus Torvalds, intègre les correctifs dans le dépôt du projet. Un autre exemple est celui des projets de l'Eclipse Foundation, qui disposent typiquement d'un project lead doté de droits supplémentaires dans le cadre du processus de développement de l'Eclipse Foundation, comme le déclenchement du processus de publication ou l'élection formelle de committers ou de project leads _[BITKOM2023]_.] ainsi que pour le développement ouvert directement en tant que projet open source. + +En deuxième élément, afin de favoriser la standardisation, un répertoire de concepts de communauté existants est tenu dans le cadre du présent document. L'idée est que de nouvelles communautés puissent être constituées avec un effort minimal sur la base de solutions éprouvées. + +Le présent document ne contient pas de recommandations directes pour l'organisation de communautés autour de bibliothèques logicielles (parties de logiciels remplissant des fonctions partielles, p. ex. la génération de PDF). Normalement, aucun concept distinct n'est élaboré pour celles-ci ; elles utilisent plutôt le modèle simple défini dans le modèle de dépôt. + +Le document link:em002-1.pdf[Em002-01 Guide pratique pour les logiciels open source dans l'administration fédérale] contient, au chapitre 4, les formes fondamentales de collaboration, au chapitre 8 les différents modèles de support et, en annexe, des informations sur le comportement de marché de l'open source. + +== Type, objectif et but d'une communauté + +Une communauté peut poursuivre les buts suivants : + +* Recensement d'exigences supplémentaires +* Diffusion de connaissances sur l'application +* Meilleurs retours des utilisateurs +* Promotion des traductions, de la documentation et des formations +* Diffusion de la standardisation +* Interaction globalement améliorée avec les utilisateurs +* Extension de la coopération à d'autres parties +* Promotion d'autres logiciels fondés sur le logiciel + +Le type de communauté le mieux adapté à une application dépend fortement de l'environnement métier, des utilisateurs potentiels et de la stratégie de l'institution qui publie. Il existe de nombreuses manières de constituer des communautés. Idéalement, un projet approprié peut rejoindre une communauté existante. Une communauté peut aussi être constituée avec un ou plusieurs partenaires sur un pied d'égalité. + +Il importe qu'une *structure de gouvernance* soit établie et que les points déterminants soient documentés dans un *concept de communauté* (voir aussi _[BITKOM2023]_ chapitre 4.1 et _[IZqCab2023]_). + +Il convient de noter que les communautés logicielles peuvent aussi être combinées avec celles portant sur les données, la standardisation et les thèmes métier. La communauté peut alors englober processus, standardisation, logiciels et données. Des cadres existants tels qu'eOperations, l'ANS et eCH peuvent également être utilisés lorsque cela est judicieux. + +Un aspect important d'une communauté qui fonctionne est que les participants reçoivent plus qu'ils n'investissent. + +Les constellations suivantes existent : + +* *Communauté autour d'un OSS de la Confédération* : la gouvernance et le concept de communauté doivent être élaborés. Dans ce contexte, il faut aussi régler la manière dont des tiers peuvent apporter des contributions. +* *Nouvelle collaboration pour résoudre un problème* : outre la gouvernance et le concept de communauté, toute la structure juridique de la collaboration doit être mise en place. +* *Adhésion à une collaboration* : l'administration fédérale doit examiner si et comment elle peut le faire. +* *Contribution à un projet de tiers* : le point à vérifier est la politique du projet en matière de contributions (Contributor Licence Agreement, Developer Certificate of Origin, etc.). + +Les questions de droit des marchés publics sont traitées dans link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et des logiciels open source]. + +=== Cas particulier : nouvelle collaboration pour le développement, la maintenance et le support de logiciels open source + +Les coûts globaux d'un logiciel open source diminuent lorsqu'il est développé et entretenu en commun. Cela peut se faire sans accords de coopération formels, ou avec rien de plus qu'une planification commune. + +Lorsqu'une collaboration plus formelle est recherchée, une analyse de marché devrait être effectuée afin de s'assurer que la collaboration est la forme de coopération la plus appropriée. Les collaborations sont plus avantageuses que le développement individuel par chaque partie (voir link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]). + +Il convient de noter que pour les collaborations, il est judicieux d'engager la collaboration très tôt dans la méthodologie de projet HERMESfootnote:[https://www.hermes.admin.ch/fr/gestion-de-projet/apercu-de-la-methode.html] — concrètement durant les phases d'analyse de la situation et des exigences. + +La collaboration est en principe admise en Suisse selon l'article 4 LMETA. + +Outre toutes les autres considérations, les collaborations comportent une dimension juridique et une dimension de droit des marchés publics. À l'heure actuelle, chaque cas est apprécié individuellement. Avec le temps, des modèles standardisés s'établiront. + +==== Dimension juridique + +Les adhésions à des associations sont envisageables, même si elles sont généralement appréciées au cas par cas : qui se trouve derrière l'association et quelles obligations sont contractées ? Une délégation des adhésions à eOperations ou à des organisations similaires serait possible. + +Tant qu'aucun argent ne circule et qu'aucune obligation formelle ne doit être contractée, un Memorandum of Understanding au niveau de l'office fédéral ou de la Chancellerie fédérale est possible. + +Une situation exigeant la conclusion d'un traité international devrait être évitée. + +Il existe en outre deux cas particuliersfootnote:[https://www.eda.admin.ch/deza/fr/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] dans lesquels une collaboration serait déjà couverte : + +* Les marchés adjugés en vertu d'un accord international concernant la réalisation conjointe d'un projet par des États signataires. +* Les marchés adjugés conformément aux procédures ou conditions particulières d'une organisation internationale. + +==== Dimension de droit des marchés publics + +Dans de nombreux cas, la collaboration se déroule entre organisations du secteur public. Dans de tels cas, l'acquisition ne pose pas de problème lorsque la configuration est « intra-étatique » (voir link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et des logiciels open source]). + +Des contrats avec des entreprises étrangères non domiciliées en Suisse sont possibles, pour autant que les exigences du droit des marchés publics soient respectées. + +L'acquisition des ressources propres d'une organisation s'effectue dans le cadre d'un processus d'acquisition ordinaire, ou est déjà achevée. + +=== Cas particulier : adhésion à une collaboration existante + +Cela requiert à la fois une base légale et le respect du droit des marchés publics. + +L'approche la plus simple consiste à participer selon le principe « chaque partie supporte ses propres coûts ». Cela peut aussi couvrir les frais généraux, pour autant que des ressources internes ou des ressources externes correctement mises au concours soient utilisées. + +Une participation directe à des collaborations étrangères est plus difficile. Un simple rattachement via un Memorandum of Understanding est l'option la plus facile à réaliser. + +=== Cas particulier : contributions de code à des projets OSS de tiers + +Lorsque l'administration fédérale apporte des modifications au code d'un projet OSS existant, il est judicieux de contribuer ces modifications directement en amont au projet d'origine. Ainsi, la maintenance courante ne doit plus être assurée par l'administration fédérale. + +Selon l'article 9 LMETA, de telles contributions sont même souhaitées. Du point de vue du droit des marchés publics, cela ne pose pas de problème. + +Il importe que ce soit le titulaire des droits qui apporte la contribution. Cela signifie que l'administration fédérale en assume la responsabilité pour le compte de ses collaborateurs et mandataires. Concrètement, tout Contributor Licence Agreement du projet doit être signé, ou un Developer Certificate of Origin doit être joint à la pull request. + +Un **Developer Certificate of Origin**footnote:[https://developercertificate.org/] *(DCO)* pour l'administration fédérale pourrait se lire ainsi : + +[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. +____ + +La structure d'un Contributor Licence Agreement est décrite dans link:em002-3.pdf[Em002-3 Guide de licences OSS], chapitre 8.9. + +Le transfert effectif du code s'effectue conformément aux directives du projet concerné. + +== Concept de communauté + +Le cœur d'une communauté réside en fin de compte dans sa structure et sa gouvernance. Celles-ci sont consignées dans un concept de communauté. + +Le concept de communauté à élaborer par la direction de projet ou d'application (ou à confier à des tiers) devrait suivre la structure de chapitres ci-après. Selon la nature de la communauté concrète, tous les sous-chapitres ne sont pas nécessaires. Idéalement, de nombreux chapitres renverront à des documents déjà standardisés ou utiliseront les processus standard des dépôts correspondants. Le concept de communauté peut aussi s'appliquer à des projets existants dirigés par d'autres, en particulier lorsque la gouvernance effective n'est pas encore documentée par écrit. + +La formalisation de la communauté rassemble tous les participants et simplifie l'intégration de nouveaux participants. + +Projet de structure d'un concept de communauté : + +[arabic] +. Tableau de synthèse (nom, dépôt, adresse de contact, licence, niveau de support, existant/nouveau) +. Objectifs +[loweralpha] +.. de l'application +.. de la communauté +. Organisation +[loweralpha] +.. Propriétaire du code +.. Forme d'organisation / organes +.. Droits de vote +.. Direction de projet +.. Questions d'acquisition (le cas échéant) +.. Autres aspects de gouvernance +. Feuille de route et processus de modification +. Processus de développement +[loweralpha] +.. Développement ouvert +.. Droits de committer +.. Processus de revue +.. Répartition des tâches et mentions nominatives +.. Sauvegardes +. Financement de la communauté +. Marketing +. Traitement des contributions externes +[loweralpha] +.. Traitement des erreurs signalées +.. Traitement des demandes +.. Traitement des pull requests +.. Traitement des forks +.. CLA, DCO et attribution des droits / de la propriété intellectuelle +. Exploitation de l'application + +En principe, chaque autorité fédérale est responsable de l'élaboration des concepts de communauté. Le secteur TNI peut publier des modèles et exemples existants et accepte des exemples correspondants en vue de leur publication. Il est également judicieux que les responsables de communauté échangent entre eux. + +Une source possible pour certaines parties est également la documentation de l'Eclipse Foundation,footnote:[Voir https://www.eclipse.org/projects/handbook/#starting] étant entendu qu'il convient ici de procéder à une adaptation appropriée dans l'esprit de « ne faire que le nécessaire ». + +== Décisions de principe lors de la constitution d'une communauté + +Les principes de la communauté, ou la renonciation à celle-ci, sont déterminés à l'aide de link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Les questions de principe déterminantes figurent dans la boîte morphologique ci-dessous ; chaque dimension est présentée dans les sections qui suivent. + +[.landscape] +[cols="3,2,2,2,2,2",options="header"] +|=== +|Dimension |(a) |(b) |(c) |(d) |(e) + +|A -- Gestion du produit +|Confédération +|Organisation commune +|Organisation ouverte +|Tiers +| + +|B -- Intégration des fournisseurs +|Mandataire +|Partenaire +|Indépendant +|Direction +| + +|C -- Répartition des coûts +|Confédération +|Chacun pour soi +|Principe de causalité +|Clé de répartition +|Contribution + +|D -- Support +|Publication minimale +|Support par la Confédération +|Support par des tiers +| +| + +|E -- Développement +|Interne +|Tiers +|Ouvert +| +| +|=== + +_Boîte morphologique communauté OSS._ + +Il est recommandé, lors de la conception de la communauté, de *se concentrer avant tout sur le proche avenir* ; s'il n'existe par exemple pas encore de parties intéressées concrètes pour l'application, il n'est généralement guère judicieux de définir une communauté dotée d'une société simple, de sa propre association et de processus complexes pour l'élaboration de la feuille de route.footnote:[Avec une association (ou une fondation), une personne morale distincte est créée pour s'occuper du logiciel et du produit. Cela ne se justifie qu'à partir d'un certain niveau d'importance, de complexité et de l'existence de plusieurs partenaires (sur un pied d'égalité). Une feuille de route sert à montrer au public élargi et aux utilisateurs potentiels supplémentaires du logiciel ce qui est prévu.]footnote:[Il peut aussi être possible, en particulier pour des projets impliquant dès le départ plusieurs acteurs étatiques, de s'adresser à des fondations existantes et d'examiner si les projets et la gouvernance peuvent être conduits sous leur égide, à l'instar de https://finos.org ou https://osr.finos.org ou https://www.eclipse.org/collaborations/ ou https://iot.eclipse.org ou https://outreach.eclipse.foundation/open-regulatory-compliance.] + +=== Gestion du produit + +Selon le type d'application, son importance stratégique et sa position dans le cycle de vie, il existe différentes variantes pour représenter la gestion du produit. Pour les organisations au sein des autorités fédérales, cela concerne toujours les responsables d'application. La définition de la feuille de route fonctionnelle et technologique ainsi que les processus de publication sont particulièrement pertinents pour le concept de communauté. + +Possibilités : + +[loweralpha] +. *Organisations au sein de la Confédération* : la Confédération veut garder le contrôle ; elle définit seule la feuille de route. +. *Organisation commune* : avec d'autres utilisateurs ou fournisseurs. +. *Organisation ouverte* : liens lâches, pas de feuille de route active. +. *Tiers* : soit le produit existe déjà, soit le travail doit être externalisé. + +==== Organisations au sein de la Confédération : + +Si l'application revêt une grande importance stratégique ou si la Confédération dépend de sa capacité à mettre en œuvre rapidement ses modifications, il peut être judicieux de garder le contrôle. + +L'autorité fédérale décide seule, par l'intermédiaire de la responsabilité des exigences, de ce qui est intégré dans le logiciel et à quel moment. + +Pour les autres utilisateurs potentiels de l'application, cela signifie qu'ils sont pratiquement contraints d'utiliser leur propre version (fork) de l'application. + +À défaut, ils n'ont guère la possibilité de mettre en œuvre des adaptations et extensions qui peuvent leur être importantes. Cela ne plaide pas contre une publication en open source : les outils de gestion de codefootnote:[p. ex. GitHub] offrent un large soutien pour de tels scénarios, et les adaptations ainsi que les corrections d'erreurs peuvent être reprises de manière sélective dans les deux sens. + +Un partage des coûts est typiquement difficile avec ce modèle. + +==== Commun (la Confédération dirige ou partenaires sur un pied d'égalité) + +Les décisions relatives à la feuille de route et aux priorités devraient être coordonnées et prises conjointement avec les autres membres de la communauté. La Confédération participe en tant que membre de la communauté, mais n'est pas l'organisation pilote. + +Pour que la prise de décision commune fonctionne, des structures et des règles doivent être fixées au préalable. Cela définit aussi la manière dont les coûts de mise en œuvre des adaptations décidées en commun sont répartis entre les parties. + +Avec ce modèle, une version unique de l'application est créée, puis utilisée par tous les membres. Les coûts totaux sont de ce fait nettement inférieurs par rapport aux autres variantes. La flexibilité de chaque utilisateur est toutefois moindre, et ils doivent coordonner au préalable leurs demandes d'adaptation avec tous les autres. La prise de décision est plus lente et plus laborieuse. + +Ce modèle convient le mieux aux applications destinées à être développées conjointement avec d'autres organisations clairement définies (p. ex. les cantons). + +==== Organisation ouverte + +Dans ce modèle, les processus et structures ne sont définis que de manière lâche. La Confédération conserve formellement le contrôle, mais est ouverte aux contributions et adaptations. + +Aucune feuille de route, ou seulement une feuille de route très sommaire, n'est définie ; le consensus est trouvé de manière informelle et dans des discussions directement sur la plateforme de publication. La communauté elle-même est plutôt dynamique ; des membres peuvent être très actifs un certain temps puis se retirer. + +Ce modèle convient aussi aux applications plus petites déjà utilisées en production et « achevées ». C'est également la meilleure forme, en général, pour des applications ou composants à orientation technique qui s'adressent potentiellement à un public plus large ne pouvant pas être défini précisément à l'avance. + +==== Tiers + +Dans ce modèle, les processus et structures sont définis par un tiers et l'autorité fédérale est membre de la communauté sans en avoir la direction. Cela peut tenir au fait que le projet a par exemple été défini par un autre État ou canton. Ou il se peut que la Confédération ne soit pas intéressée à poursuivre elle-même le programme et transfère cette tâche. + +=== Intégration des fournisseurs + +Il existe en principe les possibilités suivantes pour intégrer les fournisseurs : + +[loweralpha] +. *Fournisseur comme mandataire* : il est en principe considéré comme remplaçable à moyen terme. Le fournisseur doit développer l'application de manière économique et de haute qualité sur la base des commandes de la gestion du produit (ou de la communauté), mais n'a au plus qu'une influence consultative sur la feuille de route et la priorisation. +. *Partenaires à long terme avec codécision* : ils doivent pouvoir codéterminer activement le développement. Cela renforce leur rôle et ils sont potentiellement disposés à investir eux-mêmes dans l'application. Typiquement, dans ce modèle, les fournisseurs distribuent le logiciel et recherchent activement de nouveaux clients. +. *Indépendant :* les fournisseurs définissent eux-mêmes s'ils veulent travailler sur le projet et de quelle manière. Cela peut se produire par exemple lorsque plusieurs fournisseurs veulent générer leur propre activité sur la base du logiciel. Des licences libérales peuvent potentiellement le favoriser. Cela peut aussi se produire lorsque la stratégie de la Confédération diverge de celle du fournisseur. Dans ce scénario, il est probable que le fournisseur crée un fork. +. *Direction* : si le fournisseur reprend la gestion du produit, il en a la direction. Le développement est alors déterminé par lui. En contrepartie, cela peut aussi signifier que l'administration fédérale n'a que très peu de responsabilités à assumer. Avec une publication minimale, il est possible que le fournisseur assume ce rôle de son propre chef. + +Si le fournisseur assume un rôle fort, cela présente des avantages pour l'administration fédérale : par une commercialisation active de l'application, il y a une chance que la communauté croisse plus vite et plus fortement, réduisant ainsi plus rapidement les coûts par membre. + +Si un modèle avec forte codécision des fournisseurs est choisi, il faut veiller à ce qu'il n'en résulte pas une dérogation aux règles du droit des marchés publics. Il est généralement recommandé d'impliquer au moins deux fournisseurs afin de ne pas créer une dépendance trop forte envers un seul. Il devrait aussi être possible pour d'autres fournisseurs de rejoindre la communauté. + +=== Répartition des coûts + +Les options suivantes sont disponibles pour répartir les coûts de maintenance, de développement ultérieur et de nouvelles fonctionnalités : + +[loweralpha] +. *Organisations au sein de la Confédération* : en particulier lors de la constitution d'écosystèmes ou si l'autorité fédérale conserve le contrôle total, elle doit aussi en supporter les coûts. +. *Chacun pour soi* : chacun paie lui-même les modifications qu'il souhaite. Au besoin, il est décidé au cas par cas de financer certaines extensions en commun. Les coûts récurrents sont facturés selon une clé de répartition ou à la demande. +. *Principe de causalité* : ceux qui ont effectivement besoin des prestations ou fonctionnalités les paient. Des tarifs horaires standardisés peuvent être appliqués. +. *Clé de répartition* : les coûts sont répartis au sein de la communauté selon une clé définie. Seules les extensions spécifiques y dérogent. Celles-ci devraient être payées directement par les utilisateurs concernés. Le diviseur de coûts peut être, par exemple, la taille du canton concerné ou le nombre d'utilisateurs. Concernant la clé de répartition, voir aussi le chapitre « Répartition des coûts ». +. *Contribution* : lorsque l'autorité fédérale n'apporte que du personnel à un projet existant. + +Fondamentalement, la variante b (partage des coûts) n'a généralement de sens que s'il existe aussi une gestion commune du produit comme dans la variante b (commun). Seuls ceux qui peuvent avoir voix au chapitre seront disposés à supporter les coûts subséquents des décisions. + +=== Support + +Dans le cadre de la répartition des coûts et de la charge, il importe de clarifier qui fournit quel support. Selon l'art. 9 LMETA, une pure publication minimale est possible. Cette variante peut ne pas produire l'effet souhaité et ne constitue pas en soi une communauté dans laquelle l'autorité fédérale a de l'influence. + +[loweralpha] +. *Publication minimale* : aucun support (c'est-à-dire que la publication a généralement lieu sans support organisé ni participation de l'autorité fédérale). +. *Support par la Confédération* : l'autorité fédérale (ou son prestataire) fournit un support défini. +. *Support par des tiers* : l'autorité fédérale ou la communauté définit une organisation de support. + +L'effet recherché, p. ex. sur l'écosystème suisse ou un financement initial d'une communauté, peut conduire la Confédération à fournir du support. L'étendue du support doit naturellement être définie. En principe, un émolument peut aussi être perçu. En raison des mécanismes de la Confédération, les prestataires ou fournisseurs sont alors plus à même de proposer un support commercial. + +Les offices peuvent proposer un support payant conformément à la LMETA (le cas échéant aussi via des prestataires et des tiers). Pour ce faire, ils doivent publier les émoluments correspondants sur leur site web, la base légale nécessaire étant en place. Le raccordement au système de paiement peut être discuté avec le DFF. + +Des exemples de support et d'émoluments figurent à l'annexe G. + +=== Développement + +La méthodologie fondamentale du développement peut aussi influencer le type de communauté. + +[loweralpha] +. *Interne* : l'utilisation de dépôts internes signifie que des tiers ne peuvent pas travailler directement. Plus la séparation est stricte, plus la Confédération doit fournir d'efforts d'intégration si elle veut reprendre des extensions de tiers. Le processus de publication est également plus complexe. +. *Tiers* : soit un fournisseur travaille de son côté, soit le produit déjà lancé ou dirigé par un tiers est développé selon des règles définies. +. *Ouvert* : le développement logiciel a lieu directement dans un dépôt public. La publication selon la LMETA est ainsi largement garantie. Les dépenses interviennent pendant le développement. Dans ce scénario, la collaboration avec des tiers peut aussi intervenir plus tôt (et plus facilement). + +== Contenus détaillés pour le concept de communauté + +Ce chapitre donne des indications pour la rédaction du concept de communauté sur la base des décisions de principe prises (selon le chapitre 5). + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +ouvert / Partenaire / Confédération:: +Contenus ou suggestions, si les décisions de principe sont : + +Gestion du produit c) Organisation ouverte + +Intégration des fournisseurs : b) Fournisseur comme partenaire + +Répartition des coûts : b) Chacun pour soi + +_Le texte ci-dessus peut être copié dans le modèle et adapté._ + +Commun / - / Chacun pour soi:: +Contenus ou suggestions, si les décisions de principe sont : + +Gestion du produit b) Développement commun + +Intégration des fournisseurs : a) ou b) (non pertinent) + +Répartition des coûts : c) Principe de causalité ou d) Partage des coûts + +Commun / - / Auteur:: +{empty} + +Le concept de communauté devrait être un document dynamique, pouvant être adapté en concertation avec la communauté. Le concept devrait refléter la situation actuelle et proposer des options de développement futures. Si d'autres membres rejoignent ultérieurement la communauté, l'organisation et les processus peuvent être précisés et des mécanismes plus complexes introduits. Les sous-chapitres suivants suivent directement la structure proposée du concept de communauté (voir chapitre 4). + +Si la gestion du produit incombe à des tiers, ceux-ci définissent les concepts pour la communauté. + +=== Données clés + +Les données clés suivantes devraient être établies et publiées pour chaque communauté, afin que les personnes potentiellement intéressées puissent s'inscrire pour le logiciel et la communauté : + +* Nom du logiciel +* Dépôt +* Propriétaire +* Unité d'organisation / office responsable +* Adresse de contact +* Licence utilisée +* Niveau de support +* Projet existant + +Ces indications peuvent toutes être représentées avec publiccode.yml.footnote:[https://yml.publiccode.tools/] + +=== Objectifs + +L'objectif devrait contenir le but réel ou la « vision » de l'application. Cette vision devrait aussi figurer dans le fichier *README.md* du dépôt (voir link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[liste de contrôle Em002-2.2 Analyse et préparation OSS]). + +Dans le même temps, il convient de décrire ce que vise la communauté : + +* Qui doit adhérer ? +* Qui sont les parties potentiellement intéressées ? +* Faut-il rechercher activement de nouveaux membres ? +* Quels sont les principaux objectifs poursuivis par la publication en open source ? + +=== Organisation et gouvernance + +En principe, pour les nouveaux développements, l'objectif est que la Confédération soit titulaire des droits principaux sur le code source. + +Le type de conduite de projet dépend de l'organisation qui avait la direction (SAFe, HERMES) au sein de la Confédération. Pour la forme d'organisation, il convient toujours de viser un minimum de frais généraux (existant plutôt que nouveau ; société simple plutôt qu'association). + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / - / Interne:: +Comme la Confédération conserve le contrôle direct, aucune structure organisationnelle supplémentaire n'est nécessaire. + +L'entité qui publie (p. ex. un office fédéral) reste propriétaire et assume toutes les tâches de coordination. Dans ce cas, le chapitre « Organisation » peut être très bref. + +Commun / - / Interne:: +Pour ce scénario, l'organisation en *société simple* est généralement recommandée. + +Afin de permettre le développement commun et la coordination de la feuille de route et des exigences, il est recommandé de créer deux groupes, chacun comptant un participant par membre de la communauté : ++ +-- +* Organe de pilotage : définit la stratégie et la priorisation. +* Groupe d'experts : élabore les exigences et les contenus concrets au niveau technique. Selon l'ampleur, un groupe d'experts distinct peut aussi être institué par thème. +-- ++ +Le propriétaire du code est l'office qui l'a publié. ++ +Si les structures deviennent plus complexes ou si plus de cinq utilisateurs ou membres supplémentaires sont impliqués, il peut valoir la peine d'examiner si la communauté ne serait pas mieux organisée sous forme d'association. Comparer les explications de la variante ci-dessous. + +Commun / - / Tiers:: +L'organisation en *association* est recommandée. + +Soit une association est fondée spécialement pour l'application, soit l'application est transférée à une association existante. Une association est recommandée car, à défaut, la répartition des coûts devient complexe et les tâches de coordination représentent vraisemblablement assez de travail pour employer un gérant à temps partiel pour l'association. ++ +Les droits sur le code sont alors transférés à l'association, qui assume la gestion de la communauté et les commandes auprès des fournisseurs. + +Commun / Mandataire / Interne:: +L'organisation en *association* est recommandée. Soit une association est fondée spécialement pour l'application, soit l'application est transférée à une association existante. Une association est recommandée car, à défaut, la répartition des coûts devient complexe et les tâches de coordination représentent vraisemblablement assez de travail pour employer un gérant à temps partiel pour l'association. ++ +Les droits sur le code sont alors transférés à l'association, qui assume la gestion de la communauté et les commandes auprès des fournisseurs. + +Ici, les fournisseurs ne sont pas membres de l'association, mais uniquement mandataires. Le gérant ne devrait pas être fourni par un fournisseur. + +Commun / Mandataire / Tiers:: +L'organisation en *association* est recommandée. Soit une association est fondée spécialement pour l'application, soit l'application est transférée à une association existante. Une association est recommandée car, à défaut, la répartition des coûts devient complexe et les tâches de coordination représentent vraisemblablement assez de travail pour employer un gérant à temps partiel pour l'association. + +Les droits sur le code sont alors transférés à l'association, qui assume la gestion de la communauté et les commandes auprès des fournisseurs. + +Les fournisseurs sont membres de l'association ; le gérant peut aussi être fourni par un fournisseur. + +ouvert / - / Interne:: +Il n'est *pas nécessaire de décrire en détail une organisation*, celle-ci étant délibérément conçue de manière ouverte. Il importe toutefois d'établir qui reçoit et traite les demandes externes (responsabilité). Il faut aussi déterminer si et dans quelle mesure des personnes externes peuvent être associées : ++ +-- +* Aucune intégration directe : les externes ne peuvent soumettre que des suggestions et des contributions (sous forme de pull requests). +* Intégration comme contributeurs : les externes qui apportent des contributions fréquentes et de qualité sont directement intégrés. +* Transfert à des externes possible : si, après la publication, des externes contribuent davantage au développement que l'organisation qui publie, l'application peut aussi leur être transférée. +-- ++ +L'organisation qui publie reste propriétaire. Cette variante correspond à l'organisation des projets open source « classiques » ; voir par exemple https://opensource.guide/leadership-and-governance/ pour plus d'informations. + +ouvert / Mandataire / Interne:: +Il n'est *pas nécessaire de décrire en détail une organisation*, celle-ci étant délibérément conçue de manière ouverte. Il importe toutefois d'établir qui reçoit et traite les demandes externes (responsabilité). Il faut aussi déterminer si et dans quelle mesure des personnes externes peuvent être associées : ++ +-- +* Aucune intégration directe : les externes ne peuvent soumettre que des suggestions et des contributions (sous forme de pull requests). +* Intégration comme contributeurs : les externes qui apportent des contributions fréquentes et de qualité sont directement intégrés. +* Transfert à des externes possible : si, après la publication, des externes contribuent davantage au développement que l'organisation qui publie, l'application peut aussi leur être transférée. +-- ++ +L'organisation qui publie reste propriétaire. + +Cette variante correspond à l'organisation des projets open source « classiques » ; voir par exemple https://opensource.guide/leadership-and-governance/ pour plus d'informations. + +Le fournisseur ne devrait assumer que des tâches de coordination purement techniques (revue de code, évaluation). + +Tiers / Partenaire / Interne:: +Il n'est *pas nécessaire de décrire en détail une organisation*, celle-ci étant délibérément conçue de manière ouverte. Il importe toutefois d'établir qui reçoit et traite les demandes externes (responsabilité). Il faut aussi déterminer si et dans quelle mesure des personnes externes peuvent être associées : ++ +-- +* Aucune intégration directe : les externes ne peuvent soumettre que des suggestions et des contributions (sous forme de pull requests). +* Intégration comme contributeurs : les externes qui apportent des contributions fréquentes et de qualité sont directement intégrés. +* Transfert à des externes possible : si, après la publication, des externes contribuent davantage au développement que l'organisation qui publie, l'application peut aussi leur être transférée. +-- ++ +L'organisation qui publie reste propriétaire. Cette variante correspond à l'organisation des projets open source « classiques » ; voir par exemple https://opensource.guide/leadership-and-governance/ pour plus d'informations. + +S'agissant de la gouvernance, _[BITKOM2023]_ chapitre 4.1, _[IZqCab2023]_ ou https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md#governance-models peuvent également être consultés. + +Des exemples de statuts d'association figurent à l'annexe E. + +Remarque : la publication devant être garantie conformément à l'art. 9 LMETA, l'administration fédérale doit s'assurer que celle-ci ne puisse pas être soudainement retirée (voir les « directives Open Source dans les acquisitions — achat de logiciels selon l'art. 9 LMETA » _[BBL-WL]_, chiffre V.2). + +=== Feuille de route et processus de modification + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / Mandataire / -:: +L'autorité fédérale définit la feuille de route et décide quelles modifications sont mises en œuvre. Les processus standard de l'office XY sont utilisés à cette fin. + +Confédération / Partenaire / -:: +L'autorité fédérale définit la feuille de route en collaboration avec l'entreprise XY. Elle décide quelles modifications sont mises en œuvre. Les processus standard de l'office XY sont utilisés à cette fin. + +Commun / - / Interne:: +Le processus d'élaboration de la feuille de route et d'approbation des modifications doit être déterminé par les membres de la société ou de l'association. Selon la structure des membres (nombre, rapport de taille, etc.), d'autres processus peuvent être appropriés. + +Les processus doivent toutefois comporter des mesures de résolution des conflits et de recherche de majorité. + +Commun / - / Tiers:: +Le processus d'élaboration de la feuille de route et d'approbation des modifications doit être déterminé par les membres de la société ou de l'association. Selon la structure des membres (nombre, rapport de taille, etc.), d'autres processus peuvent être appropriés. ++ +Les processus doivent toutefois comporter des mesures de résolution des conflits et de recherche de majorité. ++ +Avec l'ajout qu'une clé de répartition des coûts doit également être établie. Il convient aussi de réfléchir à la manière de traiter le partage des coûts pour des adaptations non souhaitées par les membres concernés. En particulier dans les associations comptant des membres de tailles inégales, des situations peuvent survenir où un grand membre (p. ex. l'autorité fédérale) supporte une part importante des coûts d'une extension sans en tirer profit. + +ouvert / - / -:: +_Exemple, ne convient pas à toutes les situations_ + +Il n'est pas nécessaire d'établir une feuille de route ; l'application répond actuellement aux besoins. ++ +Les modifications sont décidées dans une discussion ouverte et un consensus est recherché. La décision finale appartient au propriétaire du code (Confédération suisse). + +=== Processus de développement + +Si le développement ouvert entre en jeu, il doit être défini ici. La répartition des tâches et la désignation des postes centraux dans le concept de communauté sont importantes. De même que la manière dont la sécurité du contenu du dépôt est assurée. + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / - / -:: +Les droits de committer (accès en écriture au code) appartiennent aux personnes/entités/fournisseurs sélectionnés par la Confédération. À l'expiration du contrat, les droits correspondants sont révoqués. ++ +Les prestataires et fournisseurs sont responsables de la conduite du processus technique de revue de code pour les contributions externes acceptées sur le fond par la Confédération. Ils répondent de la qualité technique. Les fournisseurs sont indemnisés pour ce travail par la Confédération. + +Commun / Mandataire / Interne:: +En principe, toutes les entités mandatées par un membre de la communauté reçoivent un accès en écriture au code (droits de committer). À l'expiration du contrat, les droits correspondants sont révoqués. ++ +Lorsque du code modifié touche des domaines centraux de l'application, toutes les modifications doivent être examinées par une entité spécialement mandatée à cet effet par la communauté. Cette entité répond de la qualité technique de l'application. Elle est aussi chargée d'examiner les modifications acceptées sur le fond par la communauté. + +Commun / Partenaire / Tiers:: +Les droits de committer (accès en écriture au code) appartiennent aux membres de la communauté. Ces personnes s'organisent elles-mêmes et assument conjointement la responsabilité de la qualité du code. ++ +Si un membre de la communauté mandate un fournisseur externe pour une adaptation ou une extension, celle-ci est examinée par un membre de la communauté. Il est indemnisé pour cela par le mandant. ++ +Les modifications du cœur de l'application doivent être examinées par un second membre de la communauté. ++ +Les fournisseurs membres de la communauté sont en outre chargés d'examiner les contributions externes et le nouveau code technique accepté sur le fond par l'association. + +ouvert / - / -:: +Initialement, les droits de committer appartiennent aux développeurs ou à leurs employeurs. Les droits de committer sont accordés à tous les développeurs qui contribuent activement au projet pendant plusieurs mois et font preuve d'une compétence sociale appropriée. ++ +Les développeurs conservent en principe leurs droits de committer, même s'ils changent d'employeur ou si la Confédération choisit un autre fournisseur. Les droits de committer ne s'éteignent que s'ils sont abandonnés volontairement ou si la majorité des autres committers décide de les révoquer. ++ +La Confédération a le droit de désigner comme committers certains développeurs des entreprises qu'elle mandate. Elle n'a pas le droit de retirer sans motif les droits de committer à quelqu'un. ++ +Les revues de code sont effectuées par au moins une personne agissant comme committer. Les committers s'organisent eux-mêmes. ++ +La Confédération s'engage à indemniser le travail de revue dans la mesure où cela lui est financièrement possible. + +=== Partage des coûts et fournisseurs + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / Mandataire / Interne:: +Les fournisseurs sont sélectionnés périodiquement par appels d'offres OMC ou par une procédure de gré à gré (selon l'ampleur des prestations de maintenance). + +Confédération / Partenaire / -:: +*Important :* vérifier au préalable si cela est admissible au regard du droit des marchés publics dans le cas concret. ++ +Nous compléterons la documentation sur ce point. La Confédération choisit le fournisseur XXX comme partenaire stratégique et vise une coopération à long terme. + +Commun / Mandataire / Interne:: +Chaque membre de la communauté mandate de manière autonome un ou plusieurs fournisseurs de logiciels pour mettre en œuvre les adaptations et extensions dont il a besoin. Pour les adaptations souhaitées par plusieurs membres, le partage des coûts est convenu au cas par cas. Le membre supportant la plus grande part des coûts est responsable de la sélection et du mandat au fournisseur. (Réglementations relatives à la maintenance logicielle) + +Commun / Mandataire / Tiers:: +L'association sélectionne périodiquement les fournisseurs de logiciels de manière centralisée par appels d'offres OMC ou procédures de gré à gré (selon l'ampleur des prestations de maintenance). Les coûts sont attribués aux membres selon une clé : (à définir : par population, utilisateurs, etc.) + +Commun / Partenaire / Interne:: +Chaque membre de la communauté mandate de manière autonome un ou plusieurs fournisseurs de logiciels pour mettre en œuvre les adaptations et extensions dont il a besoin. Pour les adaptations souhaitées par plusieurs membres, le partage des coûts est convenu au cas par cas. Le membre supportant la plus grande part des coûts est responsable de la sélection et du mandat au fournisseur. ++ +_(Réglementations relatives à la maintenance logicielle)_ Au besoin complété par une contribution des fournisseurs participants. Exemple : _Chaque entreprise de développement logiciel membre de la communauté s'engage à investir chaque année au moins XY jours de travail à ses propres frais dans le développement, la mise à jour technologique ou le marketing de l'application._ + +Commun / Partenaire / Tiers:: +L'association sélectionne périodiquement les fournisseurs de logiciels de manière centralisée par appels d'offres OMC ou procédures de gré à gré (selon l'ampleur des prestations de maintenance). Les coûts sont attribués aux membres selon une clé : (à définir : par population, utilisateurs, etc.) Au besoin complété par l'ajout suivant : _Chaque entreprise de développement logiciel membre de la communauté s'engage à investir chaque année au moins XY jours de travail à ses propres frais dans le développement, la mise à jour technologique ou le marketing de l'application._ + +Tiers / Mandataire / -:: +Les fournisseurs sont sélectionnés périodiquement par appels d'offres OMC ou par une procédure de gré à gré (selon l'ampleur des prestations de maintenance). Avec l'ajout suivant : _Les améliorations apportées par les fournisseurs potentiels et leurs activités dans la communauté sont prises en compte comme facteur dans l'évaluation._ ++ +Les modifications souhaitées par des externes ne sont pas financées par la Confédération, mais doivent être commandées et payées par eux-mêmes. + +Tiers / Partenaire / -:: +Les fournisseurs sont sélectionnés périodiquement par appels d'offres OMC ou par une procédure de gré à gré (selon l'ampleur des prestations de maintenance). Avec l'ajout suivant : _Les améliorations apportées par les fournisseurs potentiels et leurs activités dans la communauté sont prises en compte comme facteur dans l'évaluation. Les modifications souhaitées par des externes ne sont pas financées par la Confédération, mais doivent être commandées et payées par eux-mêmes._ + +=== Marketing + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / Mandataire / -:: +La Confédération ne commercialise pas activement l'application, mais la publie sur des plateformes de logiciels open source. La publication de l'application est annoncée dans les organes spécialisés. Si des parties intéressées se manifestent, nous examinons s'il convient de constituer une communauté commune ou de poursuivre avec leur version du logiciel. + +Commun / Partenaire / -:: +En complément : + +Les fournisseurs peuvent commercialiser l'application et rechercher d'autres parties intéressées. La Confédération peut être citée comme référence. Nous acceptons consciemment que des versions divergentes du logiciel puissent en résulter. + +Commun / Mandataire / Interne:: +L'application est commercialisée par les membres ou par l'association. + +Commun / Partenaire / Interne:: +L'application est commercialisée par les fournisseurs. + +Commun / - / Tiers:: +L'application est commercialisée par l'association, la société simple et leurs membres. + +ouvert / - / -:: +L'application peut être commercialisée par des fournisseurs, ou il peut être renoncé à un marketing explicite. ++ +Alternative sans marketing explicite : la Confédération ne commercialise pas activement l'application, mais la publie sur des plateformes de logiciels open source. Dans les organes spécialisés, nous signalons que nous avons publié l'application et qu'une collaboration est bienvenue. Nous présentons le logiciel aux personnes intéressées et tentons de les intégrer dans nos processus d'élaboration de la feuille de route. + +=== Traitement des contributions externes + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Confédération / Mandataire / -:: +Les contributions et demandes externes doivent aussi être traitées même si la Confédération reste seule décideuse concernant le logiciel (sauf en cas de publication minimale, où un fork est inévitable). Nous proposons l'approche suivante : ++ +*Traitement des erreurs signalées* + +Nous tentons de reproduire les erreurs signalées par des personnes externes et demandons des précisions au besoin. Si la reproduction réussit, la Confédération commande la correction des erreurs. Si l'erreur ne peut pas être vérifiée ou si l'effort de correction est disproportionné, nous présentons nos excuses à la personne ayant signalé l'erreur et lui demandons si elle pourrait soumettre une pull request pour y remédier. ++ +*Traitement des demandes* + +Nous répondons à chaque demande entrante. Si une demande ne peut pas être traitée avec un effort raisonnable et qu'un investissement supplémentaire de temps semble inefficient, nous présentons nos excuses en invoquant des ressources limitées et proposons de mettre la personne en contact avec un fournisseur pour un conseil plus approfondi. ++ +*Traitement des pull requests* + +Nous examinons chaque pull request avec soin. Afin d'éviter un effort inutile du côté du contributeur, nous signalons immédiatement si quelque chose contredit notre feuille de route ou s'il est douteux que nous acceptions la contribution. La Confédération décide de manière autonome et selon des critères techniques quelles contributions elle accepte. Les corrections d'erreurs ayant passé le processus de revue sont toujours acceptées. ++ +*Traitement des forks* + +Nous soutenons les forks de notre application. Celui qui déploie l'application devrait créer son propre fork. Nous examinons les forks qui en résultent au moins une fois par an et reprenons les extensions bonnes et adaptées. + +Commun / - / -:: +Externe désigne les contributions provenant de l'extérieur de la communauté définie (membres de l'association). Différences par rapport à ci-dessus : + +*Traitement des forks* + +Nous voulons éviter les forks (durables) de l'application. Les personnes intéressées devraient plutôt rejoindre directement la communauté. Au sein de la communauté, nous tentons de garantir que tous les membres utilisent la version principale. + +Ouvert / - / -:: +La constitution d'une communauté qui fonctionne et d'une culture ouverte nous importe. ++ +*Traitement des erreurs signalées* + +Nous tentons de reproduire et de corriger les erreurs signalées. Nous présupposons la collaboration active des personnes qui signalent. Si possible, elles devraient créer directement une pull request avec une correction d'erreur. ++ +*Traitement des demandes* + +Nous traitons chaque demande dans un délai d'une semaine au maximum. Les demandes de contributeurs actifs sont traitées en priorité et de manière approfondie. Nous tentons d'associer d'autres membres au traitement des demandes. ++ +*Traitement des pull requests* + +Nous souhaitons recevoir autant de pull requests de haute qualité que possible. Nous associons tous les contributeurs actifs aux revues ainsi qu'à l'évaluation technique et métier des pull requests. Pour les contributions controversées, nous tentons de parvenir à une décision par un vote informel. ++ +*Traitement des forks* + +Nous tentons de rendre les forks inutiles par une gestion de communauté active et ouverte. Si des forks apparaissent malgré tout, nous les examinons activement et tentons de reprendre les extensions et améliorations qui y ont été développées. Dans de tels cas, nous sollicitons activement des pull requests. + +De manière générale, il convient de relever que les contributions peuvent aller du soutien à d'autres utilisateurs jusqu'à la prise en charge de la responsabilité de parties entières d'un projet (voir _[BITKOM2023]_ chapitre 4.2). + +=== Exploitation de l'application + +_Gestion du produit / Fournisseur comme / Développement -- Proposition_ + +Commun / - / -:: +Une exploitation centralisée peut être proposée en option par l'association centrale, au sens du Software as a Service (SaaS). Il convient d'examiner si cela est souhaité. + +- / Partenaire / -:: +Il convient de préciser si le fournisseur doit aussi exploiter le logiciel. + +- / Direction / -:: +Il convient d'indiquer que le fournisseur est responsable de l'exploitation. + +Les niveaux de support et les contacts de support devraient également être précisés dans ce chapitre. + +== Informations importantes pour les responsables de communauté + +=== Cela prend du temps + +La constitution de communautés est une démarche à planifier sur le long terme. La persévérance et la constance sont deux qualités importantes pour une communauté réussie. + +=== Autres suggestions pour la constitution d'une communauté + +D'autres suggestions pour une bonne gestion de communauté figurent sur https://opensource.guide/code-of-conduct/ et https://opensource.guide/best-practices/. + +=== Communication + +La publication de logiciels et de documentation ouvre un nouveau canal de communication pour l'administration fédérale. Si cela n'est pas fait avec soin et professionnalisme, l'image publique de la Confédération peut en pâtir. + +Les communautés OSS de l'administration fédérale se trouvent dans un champ de tension en matière de communication : d'une part s'appliquent les *prescriptions générales de communication*, d'autre part la communauté doit permettre une *collaboration formelle et informelle simple* au-delà des frontières organisationnelles, de préférence sans contrôles qualité ni validations formels. + +L'utilisation de dépôts publics et, le cas échéant, de suivis de problèmes et de wikis publics signifie que les propos de chaque collaborateur du projet sont visibles sans filtre par le public. Cela exige des collaborateurs du projet une attitude professionnelle et le respect de standards de qualité pour les publications dans de tels environnements. + +Dans les projets OSS, cela est normalement réglé par le *Code of Conduct*. Le code de comportement de l'administration fédéralefootnote:[https://www.epa.admin.ch/dam/epa/fr/dokumente/aktuell/medienservice/120_verhaltenskodex_f.pdf.download.pdf/120_verhaltenskodex_f.pdf] est très général, mais le principe central est applicable ici : « Les collaborateurs accomplissent leurs tâches avec conscience, intégrité et loyauté. Dans leur vie privée aussi, ils veillent à ne pas porter atteinte à la réputation, à la crédibilité et à l'image de la Confédération. » + +=== Développement ouvert + +Si le développement logiciel est prévu dès le départ dans un dépôt ouvert, la publication se fait automatiquement. Les listes de contrôle déterminantes selon les instructions link:em002-2.pdf[Em002-2] doivent être remplies au début, et les processus de développement du prestataire ou du fournisseur doivent le permettre. L'avantage est que la communauté peut être constituée dès le tout début. Plusieurs organisations peuvent en outre collaborer au développement. + +Les dépôts fermés constituent une forme intermédiaire, mais sont utilisés pour d'autres partenaires dans une collaboration. + +=== Gestion des utilisateurs + +Le projet (ou l'organisation porteuse) détermine si les développeurs et autres collaborateurs du projet travaillent sous leur propre nom ou de manière anonyme. Si les personnes ne travaillent pas anonymement et disposent déjà de comptes sur les plateformes, il est plus simple d'utiliser ceux-ci (professionnels ou privés). + +La plateforme devrait en principe permettre l'intégration de tiers, faute de quoi aucun développeur extérieur à la Confédération ne pourra collaborer. + +Lors du départ du projet, les droits correspondants sur le projet doivent être supprimés. La gestion du produit en est responsable. + +=== Fusion de communautés + +Dans la mesure du possible, le nombre de communautés devrait rester restreint. Cela signifie : + +* S'il existe déjà une communauté où une structure similaire est prévue pour des problèmes similaires impliquant les mêmes personnes, une seule communauté devrait être utilisée. +* Plusieurs projets connexes s'adressant au même public cible peuvent être regroupés en une seule communauté. +* Il ne faut pas créer inutilement des structures de communauté fondamentalement différentes là où il en existe déjà. + +=== Traitement des contributions de tiers + +La contribution de logiciels à d'autres projets est traitée au chapitre 3.3. Les mêmes principes s'appliquent en sens inverse. + +Les points suivants sont importants : + +* Un Contributor Licence Agreement approprié doit être utilisé afin de garantir que le code source appartienne ensuite à la Confédération (voir aussi link:em002-3.pdf[Em002-3 Guide de licences OSS], chapitre sur les Contributor Licence Agreements). Celui-ci doit être signé par le propriétaire de la contribution. +* Les confirmations doivent être classées. +* Les contributions doivent être examinées avant leur intégration dans la base de code. +* Les soumissions devraient recevoir une réponse dans un délai raisonnable (issues, requests, pull requests) et être traitées de la manière la plus constructive possible. +* Tous les canaux et arrangements de gouvernance devraient figurer dans le concept de communauté, sur le site web et dans le dépôt. + +=== Signalements relevant de la sécurité + +Outre les signalements d'erreurs usuels, il convient de prévoir — lorsque la nature du projet l'exige — que les vulnérabilités relevant de la sécurité puissent être signalées de manière confidentielle, comme c'est le cas par exemple d'un programme de bug bounty. + +Les documents de trustbroker.swiss peuvent servir d'exemple : + +* https://github.com/trustbroker-swiss/trustbroker.swiss/blob/main/Security-and-Vulnerability-Disclosure.md + +=== Éviter les forks + +Si les forks sont naturels dans le monde de l'open source, la réintégration du code source, des fonctionnalités et ainsi de suite issus de forks est loin d'être simple. Il peut valoir la peine d'approcher les personnes ou organisations envisageant un fork et de tenter de les maintenir engagées dans le projet principal. Trouver un équilibre entre des intérêts concurrents est souvent nécessaire dans de tels cas. + +=== Répartition des coûts + +Il est judicieux de convenir de clés de répartition générales entre les principaux partenaires. Celles-ci peuvent être adaptées tous les quelques années ou lorsque la situation change fondamentalement. Pour un travail efficace sur le logiciel, les grands partenaires devraient plutôt assumer des parts un peu plus importantes qu'ils ne le devraient effectivement (au besoin aussi la coordination générale). L'organisation doit travailler et non se disputer sur les finances. Si la collaboration porte sur plusieurs projets (par exemple les solutions sectorielles dans le domaine des chemins de fer à voie normale), une clé de répartition uniforme devrait être utilisée pour tous les projets. Du point de vue des autorités fédérales, c'est une amélioration si les coûts ne doivent pas être supportés seuls. + +Critères possibles pour les clés de répartition : + +* Estimation de la répartition des bénéfices (p. ex. entre une autorité fédérale et un fournisseur espérant d'autres clients) +* Nombre d'habitants/d'utilisateurs (p. ex. entre offices, communes, villes) +* Capacité financière (p. ex. cantons) +* Produit intérieur brut (p. ex. entre cantons) +* Qui veut davantage de contrôle + +Pour éviter les discussions, la clé de répartition ne devrait pas être simplement liée au budget annuel. Une clause dans l'esprit du principe de causalité peut permettre des adaptations plus rapides pour certains partenaires s'ils sont disposés à payer un supplément. + +La clé de répartition devrait aussi s'appliquer aux frais généraux, à la maintenance/au support et à un minimum de développement ultérieur. Ces parties devraient si possible être résolues sur le long terme. + +Il convient de garder à l'esprit que, lorsque des financements de tiers interviennent, ces parties voudront typiquement avoir davantage voix au chapitre. La gestion de la communauté doit être outillée pour y faire face. + +=== Prestations complémentaires selon l'art. 9, al. 5 et 6, LMETA + +Les autorités fédérales peuvent (elles-mêmes, par l'intermédiaire de prestataires ou de fournisseurs) fournir des prestations complémentaires, en particulier pour l'intégration, la maintenance, la garantie de la sécurité de l'information et le support. + +La limite est qu'elles doivent servir les tâches des autorités et pouvoir être fournies avec un effort proportionné. + +Il en découle que l'autorité fédérale ne peut pas être l'entreprise de développement pour des tiers. Elle corrige des erreurs, peut traiter des aspects relevant de la sécurité, peut fournir un certain support et une aide à l'intégration (toutes activités contribuant à constituer une communauté). Les nouveaux développements et fonctionnalités supplémentaires pour des tiers devraient avant tout s'orienter sur le but de travail normal de l'autorité. Il se peut naturellement que la mise à disposition du logiciel fasse partie de la tâche ; dans ce cas, des développements peuvent être réalisés à tout moment. Il est également précisé que le développement logiciel n'est pas la tâche principale de l'autorité fédérale. + +Cela signifie que si des fonctionnalités sont développées pour l'essentiel exclusivement pour des tiers, elles doivent être intégrées en partenariat ou par l'intermédiaire du fournisseur. + +Pour éviter des problèmes de droit des marchés publics, il convient, lors de l'acquisition de logiciels et de prestations, de veiller à ce que des fonctionnalités puissent être fournies à des tiers (le cas échéant uniquement à des tiers étatiques) par des fournisseurs. + +La fixation des émoluments a déjà été abordée au chapitre « Support ». La LMETA constitue déjà la base légale de tels émoluments. Ceux-ci doivent être communiqués sur le site web de l'autorité fédérale concernée. Des exemples figurent à l'annexe G. + +L'art. 9, al. 6, prévoit qu'il ne faut normalement pas concurrencer le secteur privé. Cela signifie que les émoluments ne devraient pas être fixés trop bas et devraient au moins couvrir les coûts. En cas de doute, il vaut mieux fixer des tarifs horaires trop élevés que trop bas. + +De manière générale, il est recommandé de travailler avec un à trois tarifs horaires standard différents. + +Si un département fédéral souhaite définir des exceptions à l'al. 6, cela ne doit pas concurrencer le secteur privé. Dans certaines circonstances, le plus simple peut être de fixer les émoluments et de les augmenter en cas d'opposition d'entreprises privées effectivement en mesure d'offrir la prestation. + +=== Souveraineté numérique + +Tant que la Confédération ne dispose pas de son propre dépôt, il est recommandé, pour assurer la souveraineté numérique, de réaliser régulièrement des copies des dépôts publics. + +Il convient de noter que ce n'est pas seulement le code source qui est copié, mais aussi d'autres informations telles que le suivi des problèmes, le wiki, les configurations, etc. + +Par ailleurs, la gestion des utilisateurs doit être réglée afin d'assurer le contrôle du code source publié. L'objectif général est de garantir un développement indépendant de la plateforme concernée et de permettre à la communauté de changer.footnote:[Voir aussi https://www.bfh.ch/de/aktuell/news/2024/neue-studie-digitale-souveraenitaet/] + +== Annexe + +=== Modifications par rapport à la version précédente + +* Chapitre 1 « L'essentiel en bref » ajouté +* But de la communauté ajouté au chapitre 3 +* Chapitres 3.1 à 3.3 sur la collaboration ajoutés +* Nouveau chapitre 7.7 Traitement des contributions de tiers +* Précisé que les fournisseurs ne devraient pas publier entièrement de leur propre chef (conformément à _[BBL-WL]_, V.2) +* Publicode.yml mentionné +* Harmonisation avec le nouveau link:em002-7.pdf[Em002-7] +* Autres modifications et améliorations rédactionnelles + +=== Références + +Voir _Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale_. + +=== Abréviations + +Voir link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] et link:em002-6.pdf[Em002-6 FAQ sur l'OSS]. + +=== Exemples de concepts de communauté existants + +Dans l'esprit d'une collecte de bonnes pratiques figurent ci-après des concepts de communauté et documents comparables déjà élaborés. Il ne s'agit pas nécessairement de concepts d'autorités fédérales uniquement, mais aussi d'autres organisations. + +* GERES Community (http://geres-community.ch) + +Classification : + +* Gestion du produit a) Développement commun +* Fournisseur plutôt a) Mandataire +* Répartition des coûts : b) Partage des coûts + +Remarque : le registre communal GERES n'est pas open source, mais de nombreux aspects de l'organisation peuvent aussi être pertinents pour des applications open source. Documents : statuts (publics) et règlement intérieur (sur demande). + +* https://www.igovportal.ch[iGov Portal] + +#Ce chapitre contient actuellement des concepts du canton de Berne et sera complété dès que des exemples fédéraux seront disponibles.# + +=== Exemples de collaborations + +Les exemples suivants illustrent comment des collaborations ont été structurées. + +=== Collaboration : ZenDiS en Allemagne + +ZenDiSfootnote:[https://www.zendis.de/en[Page d'accueil ZenDiS : Co-creating Digital Sovereignty]] est une organisation dont le but est de réduire la dépendance dans l'administration publique (principalement en Allemagne) en promouvant les logiciels open source. + +[mermaid,align="center",alt="Objectifs et approches pour renforcer la souveraineté numérique (ZenDiS)"] +.... +block-beta + columns 12 + H1["Objectifs"]:12 + G1["I. Possibilité de changer de fournisseur"]:4 G2["II. Capacité de conception"]:4 G3["III. Influence sur les fournisseurs"]:4 + H2["Approches de solution"]:12 + B1["1. Analyse et pilotage
prospectifs des dépendances"]:3 B3["3. Modularité indépendante du
fournisseur, standards (ouverts)
et interfaces informatiques"]:3 B5["5. Co-conception coopérative
des solutions informatiques"]:3 B7["7. Exigences juridiques"]:3 + B2["2. Acquisition ou développement
de solutions informatiques
alternatives (p. ex. OSS)"]:3 B4["4. Développement des compétences
numériques et de l'expertise"]:3 B6["6. Compréhension et
démarche communes"]:3 B8["8. Pilotage politique"]:3 + classDef highlight fill:#dae8fc,stroke:#000000,color:#000000 + class B2 highlight +.... + +Figure 1 : Objectifs et approches pour renforcer la souveraineté numérique (ZenDiS) + +ZenDiS collabore à cette fin avec des partenaires stratégiques. + +Une coopération entre l'administration fédérale et ZenDiS ne devrait donc guère être possible sans restriction, et une coordination ne serait pas contraignante. Cela peut changer avec le temps. + +Concrètement, l'administration fédérale devrait mettre en place sa propre organisation pour la Suisse et se coordonner de manière informelle avec ZenDiS. Cela pourrait éventuellement se faire via eOperations, étant précisé qu'eOperations ne devient active que lorsqu'un besoin concret est annoncé et qu'un budget est mis à disposition. Une justification d'une telle organisation parallèle pourrait être trouvée dans le contexte de la cyberadministration ou de la LMETA. + +Remarque : ZenDiS est soumise au droit des marchés publics de l'UE et de l'Allemagne. Il existe des différences importantes par rapport à la Suisse. ZenDiS ne peut donc pas être reproduite à l'identique en Suisse, et une coopération avec ZenDiS n'est pas évidente. + +=== Collaboration : Open Trip Planner (OTP) + +Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] est une application open source de planification de voyages. Elle est organisée comme un projet de la Software Freedom Conservancy à New York. Certains développeurs sont employés par des entreprises de transport et des fournisseurs. Fait notable, un acteur du secteur public — concrètement ENTURfootnote:[https://entur.no/] — a assumé l'un des rôles dirigeants. ENTUR développe avant tout pour ses propres besoins, mais a aussi une orientation coopérative, en particulier pour les pays nordiques. ENTUR est organisée comme une société détenue par le ministère norvégien des transports et des communications. En tant que plus grand acteur, ENTUR absorbe également une part importante des coûts de coordination. Chacun peut soumettre des demandes de fonctionnalités ; celles-ci sont discutées lors de réunions de coordination et développées si quelqu'un les finance. Le financement est assuré principalement par fonctionnalité, par la ou les parties intéressées. Pour l'essentiel, chaque partie supporte ses propres coûts. Les prestations de support devraient en outre faire l'objet d'un appel d'offres distinct en Suisse. + +=== Nouvelle collaboration initiée par la Confédération : Swiss Trust Broker + +Le Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] est un logiciel de la Confédération pour eIAM, disponible en open source. Le développement est assuré par la Confédération. Plusieurs cantons ont décidé de le déployer soit directement en SaaS, soit avec leurs propres instances. Comme il est disponible sous licence AGPL, les extensions réalisées profitent à leur tour à la Confédération. Compte tenu de son caractère critique pour la sécurité, le développement pour l'administration fédérale est assuré exclusivement par la Confédération. D'autres organisations peuvent soumettre des exigences, qui seront mises en œuvre si l'équipe de projet les juge appropriées. + +=== Nouvelle collaboration initiée par les cantons : inosca + +Via inosca,footnote:[https://inosca.ch/] plusieurs cantons ont constitué une communauté de développement axée sur les autorisations électroniques, née du projet eBau.footnote:[https://github.com/inosca/ebau] eBau comprend aussi Caluma,footnote:[https://github.com/projectcaluma] un framework d'édition collaborative — un exemple de composant extrait d'une solution plus large et développé en un framework autonome et largement applicable. Celui-ci peut aussi être utilisé dans d'autres projets, même lorsque certaines parties sont soumises à des conditions d'exception, permettant ainsi au plus grand nombre d'autres entités de profiter du code. + +La communauté se réunit au moins une fois par mois (en option deux fois) pour échanger sur des sujets techniques et planifier la feuille de route commune. Tous les participants peuvent soumettre des sujets. Lorsqu'un sujet est jugé pertinent pour la communauté, les cantons intéressés se manifestent et s'organisent en groupe de travail. Les résultats sont restitués en continu à la communauté. inosca fonctionne selon un principe fondamental : qui conçoit, finance. Autrement dit, tous les cantons participant à un groupe de travail se partagent les coûts de la nouvelle fonctionnalité. La fonctionnalité est mise au concours et les coûts sont répartis au sein de la communauté selon une formule de partage des coûts prédéfinie. Dès qu'une fonctionnalité est achevée et déployée, elle devient immédiatement disponible gratuitement pour tous les autres cantons. + +La communauté a en outre décidé de réserver un modeste montant annuel fixe pour couvrir les frais administratifs liés au fonctionnement de la communauté. Ce budget est attribué chaque année aux parties assumant un rôle organisationnel. + +=== SNOWPACK du WSL — contributions directes de développeurs + +SNOWPACKfootnote:[https://snow-models.gitlab-pages.wsl.ch/snowpack-web/] est un projet open source développé par le WSL pour modéliser la formation du manteau neigeux. Il s'agit d'un modèle hautement spécialisé, et la communauté a en conséquence été intégrée dans la communauté spécialisée existante. Certains problèmes ont déjà été identifiés comme contributions potentielles. Le modèle de travail est ici que chaque partie supporte ses propres coûts et apporte des fonctionnalités. Les directives relatives au style de codage et au processus de publication sont également documentées dans ce contexte. + +=== Inspiration pour des statuts d'association + +Les statuts devraient être aussi simples que possible. + +Les statuts suivants peuvent servir d'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 + +#D'autres exemples de statuts seront ajoutés dès qu'ils seront disponibles.# + +=== Exemples de support et d'émoluments + +* Émoluments pour les prestations statistiques : https://www.fedlex.admin.ch/eli/cc/2003/326/fr[https://www.fedlex.admin.ch/eli/cc/2003/326/fr] +* Émoluments du PFPDT : https://www.edoeb.admin.ch/edoeb/fr/home/datenschutz/grundlagen/dsfa.html +* Prestations gratuites de l'IPI pour des cours dans le domaine de la propriété intellectuelle (pas un logiciel, mais à titre d'exemple) : https://www.ige.ch/fr/prestations/ip-academy/informations-generales/prix + +Des exemples seront ajoutés dès qu'ils seront disponibles. +endif::[] + +ifeval::["{lang}" == "it"] +NOTE: 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 {url-repo}/tree/main[README] principale. + +== L'essenziale in breve + +Di seguito sono elencati i punti più importanti del documento. + +* La costituzione o la gestione di una community OSS *non è richiesta* dall'art. 9 LMeCA. +* Una community è rilevante quando un gruppo di utenti ha senso e devono essere create *sinergie* con altri utenti del software. +* Una community non si limita al software stesso, ma può comprendere anche i processi circostanti e la standardizzazione dei dati. +* Per costituire una community occorre sempre un *onere iniziale*. Esso prosegue di regola nel tempo. In molti casi è opportuno che l'ufficio capofila sostenga anche i costi di coordinamento. +* Le community devono perseguire uno *scopo*. Occorrono interessati e partecipanti. +* Una community può nascere e poi essere formalizzata. +* L'obiettivo della community è accrescere il *beneficio per tutti*. Principio generale: «si ottiene almeno quanto si apporta». +* La community dovrebbe essere *strutturata nel modo più semplice possibile*. +* In un primo momento la community dovrebbe essere esaminata brevemente mediante la lista di controllo link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Soltanto se è opportuna dovrebbe essere sviluppata ulteriormente. +* La formalizzazione avviene mediante un *concetto di community*. Occorre riprendere il più possibile da fonti esistenti. Principio generale: «non reinventare la ruota». +* Se si mira a una collaborazione, ciò va considerato già all'inizio del progetto, poiché i potenziali partner dovrebbero essere coinvolti sin dall'analisi dei requisiti. Anche sotto il profilo giuridico e del diritto degli acquisti pubblici ciò va pianificato bene sin dall'inizio. +* Le possibilità di aderire a una collaborazione esistente vanno esaminate sotto il profilo giuridico e del diritto degli acquisti pubblici. +* Per i contributi non occorre costituire alcuna community. Se tuttavia il progetto lo richiede, va firmato il corrispondente *Contributor Licence Agreement (CLA)* oppure gli sviluppatori devono essere autorizzati dal progetto a presentare il software sotto un Developer Certificate of Origin (DCO). + +== Introduzione + +La presente guida si rivolge agli specialisti TIC responsabili di un'applicazione che intendono offrirla come open source o contribuire a una simile applicazione. + +Ciò va organizzato in modo formale o informale. + +Il presente documento fornisce informazioni importanti per l'organizzazione e la costituzione di una communityfootnote:[La community di un progetto open source rappresenta tipicamente una piramide. + +La base di questa piramide è costituita dagli utenti del software, in particolare da quelli impegnati che partecipano attivamente alla community, per esempio sotto forma di segnalazioni di errori e richieste di funzionalità o mediante contributi a mailing list. + +Direttamente sopra, nella piramide, si trovano i contributori. Si tratta di parti della community che propongono propri contributi di codice. Essi tipicamente non hanno accesso in scrittura al repository. I loro contributi sono esaminati dai manutentori del progetto e integrati nel repository dopo aver raggiunto la qualità tipica del progetto. + +Al vertice della piramide si trovano i manutentori o committer di un progetto. In tale ruolo uno sviluppatore assume una responsabilità maggiore. Ciò si manifesta per esempio nella possibilità di accettare contributi. Tale diritto si concretizza spesso nell'accesso in scrittura al repository. A questo livello si esercita il controllo sul software, sulla sua qualità e sulla sua gamma di funzioni. Nei progetti più complessi tale livello può essere ulteriormente suddiviso. Il kernel Linux, per esempio, conta notoriamente manutentori di sottosistemi su più livelli e, in definitiva, un solo sviluppatore, Linus Torvalds, integra le patch nel repository del progetto. Un altro esempio è dato dai progetti della Eclipse Foundation, che dispongono tipicamente di un project lead con diritti supplementari nell'ambito del processo di sviluppo della Eclipse Foundation, quali l'avvio del processo di rilascio o l'elezione formale di committer o project lead _[BITKOM2023]_.] nonché per lo sviluppo aperto direttamente come progetto open source. + +Quale secondo elemento, per promuovere la standardizzazione, nell'ambito del presente documento è tenuto un repertorio di concetti di community esistenti. L'idea è che nuove community possano essere costituite con un onere minimo sulla base di soluzioni collaudate. + +Il presente documento non contiene raccomandazioni dirette per l'organizzazione di community attorno a librerie software (parti di software che svolgono funzioni parziali, p. es. la generazione di PDF). Normalmente per esse non viene elaborato alcun concetto proprio; si utilizza invece il modello semplice definito nel modello di archiviazione del repository. + +Il documento link:em002-1.pdf[Em002-01 Guida pratica per il software open source nell'Amministrazione federale] contiene, nel capitolo 4, le forme fondamentali di collaborazione, nel capitolo 8 i diversi modelli di supporto e, nell'allegato, informazioni sul comportamento di mercato dell'open source. + +== Tipo, obiettivo e scopo di una community + +Una community può perseguire i seguenti scopi: + +* Rilevamento di requisiti supplementari +* Diffusione di conoscenze sull'applicazione +* Migliori riscontri dagli utenti +* Promozione di traduzioni, documentazione e formazione +* Diffusione della standardizzazione +* Interazione complessivamente migliore con gli utenti +* Estensione della cooperazione ad altre parti +* Promozione di ulteriore software basato sul software + +Quale tipo di community sia più adatto a un'applicazione dipende fortemente dal contesto specialistico, dai potenziali utenti e dalla strategia dell'istituzione che pubblica. Vi sono molti modi diversi di costituire community. Idealmente, un progetto adeguato può aderire a una community esistente. In alternativa, una community può essere costituita con uno o più partner con pari diritti. + +È importante che venga stabilita una *struttura di governance* e che i punti determinanti siano documentati in un *concetto di community* (cfr. anche _[BITKOM2023]_ capitolo 4.1 e _[IZqCab2023]_). + +Va rilevato che le community per il software possono anche essere combinate con quelle per i dati, la standardizzazione e i temi specialistici. La community può allora comprendere processi, standardizzazione, software e dati. Strutture esistenti quali eOperations, ADS ed eCH possono parimenti essere utilizzate ove opportuno. + +Un aspetto importante di una community funzionante è che i partecipanti ricevano più di quanto investono. + +Esistono le seguenti costellazioni: + +* *Community attorno a un OSS della Confederazione*: la governance e il concetto di community vanno elaborati. In tale contesto occorre anche disciplinare come terzi possano apportare contributi. +* *Nuova collaborazione per risolvere un problema*: oltre alla governance e al concetto di community va costituita l'intera struttura giuridica della collaborazione. +* *Adesione a una collaborazione*: l'Amministrazione federale deve esaminare se e come può farlo. +* *Contributo a un progetto di terzi*: va verificata la politica del progetto in materia di contributi (Contributor Licence Agreement, Developer Certificate of Origin ecc.). + +Le questioni di diritto degli acquisti pubblici sono trattate in link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e del software open source]. + +=== Caso particolare: nuova collaborazione per lo sviluppo, la manutenzione e il supporto di software open source + +I costi complessivi del software open source diminuiscono quando esso è sviluppato e mantenuto congiuntamente. Ciò può avvenire senza accordi di cooperazione formali, o con nulla più di una pianificazione comune. + +Se si mira a una collaborazione più formale, andrebbe svolta un'analisi di mercato per assicurarsi che la collaborazione sia la forma di cooperazione più adeguata. Le collaborazioni sono più economiche dello sviluppo individuale da parte di ciascuna parte (cfr. link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]). + +Va rilevato che per le collaborazioni è opportuno avviare la collaborazione molto presto nella metodologia di progetto HERMESfootnote:[https://www.hermes.admin.ch/it/gestione-di-progetti/panoramica-del-metodo.html] — concretamente durante le fasi di analisi della situazione e dei requisiti. + +La collaborazione è in linea di principio ammessa in Svizzera secondo l'articolo 4 LMeCA. + +Oltre a tutte le altre considerazioni, le collaborazioni presentano sia una dimensione giuridica sia una dimensione di diritto degli acquisti pubblici. Attualmente ogni caso è valutato singolarmente. Con il tempo si affermeranno modelli standardizzati. + +==== Dimensione giuridica + +Le adesioni ad associazioni sono praticabili, anche se sono di regola valutate caso per caso: chi sta dietro l'associazione e quali obblighi vengono assunti? Una delega delle adesioni a eOperations o a organizzazioni analoghe sarebbe possibile. + +Fintanto che non circola denaro e non devono essere assunti obblighi formali, è possibile un Memorandum of Understanding a livello di ufficio federale o di Cancelleria federale. + +Una situazione che richieda la conclusione di un trattato internazionale andrebbe evitata. + +Esistono inoltre due casi particolarifootnote:[https://www.eda.admin.ch/deza/it/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] in cui una collaborazione sarebbe già coperta: + +* Le commesse aggiudicate in virtù di un accordo internazionale concernente la realizzazione congiunta di un progetto da parte di Stati firmatari. +* Le commesse aggiudicate conformemente alle procedure o condizioni particolari di un'organizzazione internazionale. + +==== Dimensione di diritto degli acquisti pubblici + +In molti casi la collaborazione avviene tra organizzazioni del settore pubblico. In tali casi l'acquisto non pone problemi se la configurazione è «intrastatale» (cfr. link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e del software open source]). + +Contratti con imprese estere non domiciliate in Svizzera sono possibili, purché siano soddisfatte le esigenze del diritto degli acquisti pubblici. + +L'acquisto delle risorse proprie di un'organizzazione avviene nel quadro di un processo d'acquisto ordinario, oppure è già concluso. + +=== Caso particolare: adesione a una collaborazione esistente + +Ciò richiede sia una base legale sia il rispetto del diritto degli acquisti pubblici. + +L'approccio più semplice è la partecipazione secondo il principio «ciascuna parte sostiene i propri costi». Ciò può coprire anche le spese generali, purché siano impiegate risorse interne oppure risorse esterne correttamente messe a concorso. + +Una partecipazione diretta a collaborazioni estere è più difficile. Una semplice aggregazione mediante un Memorandum of Understanding è l'opzione più facile da realizzare. + +=== Caso particolare: contributi di codice a progetti OSS di terzi + +Quando l'Amministrazione federale apporta modifiche al codice di un progetto OSS esistente, è opportuno contribuire tali modifiche direttamente a monte al progetto originario. In tal modo la manutenzione corrente non deve più essere assicurata dall'Amministrazione federale. + +Secondo l'articolo 9 LMeCA tali contributi sono anzi auspicati. Sotto il profilo del diritto degli acquisti pubblici ciò non pone problemi. + +È importante che sia il titolare dei diritti ad apportare il contributo. Ciò significa che l'Amministrazione federale se ne assume la responsabilità per conto dei propri collaboratori e mandatari. Concretamente va firmato l'eventuale Contributor Licence Agreement del progetto, oppure va allegato alla pull request un Developer Certificate of Origin. + +Un **Developer Certificate of Origin**footnote:[https://developercertificate.org/] *(DCO)* per l'Amministrazione federale potrebbe recitare: + +[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. +____ + +La struttura di un Contributor Licence Agreement è descritta in link:em002-3.pdf[Em002-3 Guida alle licenze OSS], capitolo 8.9. + +Il trasferimento effettivo del codice avviene conformemente alle direttive del rispettivo progetto. + +== Concetto di community + +Il nucleo di una community è in definitiva la sua struttura e la sua governance. Queste sono fissate in un concetto di community. + +Il concetto di community, che va elaborato dalla direzione del progetto o dell'applicazione (o commissionato a terzi), dovrebbe seguire la seguente struttura di capitoli. A seconda della natura della community concreta non tutti i sottocapitoli sono necessari. Idealmente molti capitoli rinvieranno a documenti già standardizzati o utilizzeranno processi standard dei repository corrispondenti. Il concetto di community può essere applicato anche a progetti esistenti diretti da altri, in particolare se la governance effettiva non è ancora documentata per iscritto. + +Formalizzando la community si riuniscono tutti i partecipanti e si semplifica l'inserimento di nuovi partecipanti. + +Bozza di struttura di un concetto di community: + +[arabic] +. Tabella riassuntiva (nome, repository, indirizzo di contatto, licenza, livello di supporto, esistente/nuovo) +. Obiettivi +[loweralpha] +.. dell'applicazione +.. della community +. Organizzazione +[loweralpha] +.. Proprietario del codice +.. Forma organizzativa / organi +.. Diritti di voto +.. Direzione del progetto +.. Questioni d'acquisto (se del caso) +.. Ulteriori aspetti di governance +. Roadmap e processo di modifica +. Processo di sviluppo +[loweralpha] +.. Sviluppo aperto +.. Diritti di committer +.. Processo di revisione +.. Ripartizione dei compiti e menzioni nominative +.. Backup +. Finanziamento della community +. Marketing +. Trattamento dei contributi esterni +[loweralpha] +.. Trattamento degli errori segnalati +.. Trattamento delle richieste +.. Trattamento delle pull request +.. Trattamento dei fork +.. CLA, DCO e attribuzione di diritti / proprietà intellettuale +. Esercizio dell'applicazione + +In linea di principio ogni autorità federale è responsabile dell'elaborazione dei concetti di community. Il settore TDT può pubblicare modelli ed esempi esistenti e accoglie esempi corrispondenti in vista della pubblicazione. È inoltre opportuno che i responsabili di community si scambino informazioni tra loro. + +Una possibile fonte per alcune parti è anche la documentazione della Eclipse Foundation,footnote:[Cfr. https://www.eclipse.org/projects/handbook/#starting] fermo restando che qui va effettuato un adeguato adattamento nello spirito del «fare solo il necessario». + +== Decisioni di principio nella costituzione di una community + +I principi della community, o la rinuncia a essa, sono stabiliti mediante link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Le questioni di principio determinanti figurano nella scatola morfologica seguente; ogni dimensione è illustrata nelle sezioni successive. + +[.landscape] +[cols="3,2,2,2,2,2",options="header"] +|=== +|Dimensione |(a) |(b) |(c) |(d) |(e) + +|A -- Gestione del prodotto +|Confederazione +|Organizzazione comune +|Organizzazione aperta +|Terzi +| + +|B -- Coinvolgimento dei fornitori +|Mandatario +|Partner +|Indipendente +|Direzione +| + +|C -- Ripartizione dei costi +|Confederazione +|Ciascuno per sé +|Principio di causalità +|Chiave di ripartizione +|Contributo + +|D -- Supporto +|Pubblicazione minima +|Supporto da parte della Confederazione +|Supporto da parte di terzi +| +| + +|E -- Sviluppo +|Interno +|Terzi +|Aperto +| +| +|=== + +_Scatola morfologica community OSS._ + +È consigliabile, nel configurare la community, *concentrarsi in primo luogo sul prossimo futuro*; se per esempio non vi sono ancora interessati concreti all'applicazione, di regola ha poco senso definire una community con una società semplice, una propria associazione e processi complessi per l'elaborazione della roadmap.footnote:[Con un'associazione (o una fondazione) si crea una persona giuridica distinta che si occupa del software e del prodotto. Ciò si giustifica soltanto a partire da un certo livello di importanza, complessità e in presenza di più partner (con pari diritti). Una roadmap serve a mostrare al pubblico più ampio e ai potenziali ulteriori utenti del software che cosa è previsto.]footnote:[Può anche essere possibile, in particolare per progetti che coinvolgono sin dall'inizio più attori statali, rivolgersi a fondazioni esistenti e verificare se i progetti e la governance possano essere condotti sotto la loro egida, analogamente a https://finos.org o https://osr.finos.org o https://www.eclipse.org/collaborations/ o https://iot.eclipse.org o https://outreach.eclipse.foundation/open-regulatory-compliance.] + +=== Gestione del prodotto + +A seconda del tipo di applicazione, della sua importanza strategica e della sua posizione nel ciclo di vita, esistono diverse varianti per rappresentare la gestione del prodotto. Per le organizzazioni in seno alle autorità federali ciò riguarda sempre i responsabili dell'applicazione. Per il concetto di community sono particolarmente rilevanti la definizione della roadmap funzionale e tecnologica nonché i processi di rilascio. + +Possibilità: + +[loweralpha] +. *Organizzazioni in seno alla Confederazione*: la Confederazione vuole mantenere il controllo; definisce da sola la roadmap. +. *Organizzazione comune*: insieme ad altri utenti o fornitori. +. *Organizzazione aperta*: legami lassi, nessuna roadmap attiva. +. *Terzi*: o il prodotto esiste già, oppure il lavoro deve essere esternalizzato. + +==== Organizzazioni in seno alla Confederazione: + +Se l'applicazione ha grande importanza strategica o se la Confederazione dipende dalla possibilità di attuare rapidamente le proprie modifiche, può essere opportuno mantenere il controllo. + +L'autorità federale decide da sola, tramite la responsabilità dei requisiti, che cosa confluisce nel software e quando. + +Per i potenziali altri utenti dell'applicazione ciò significa che sono praticamente costretti a utilizzare una propria versione (fork) dell'applicazione. + +In caso contrario hanno ben poche possibilità di attuare adattamenti ed estensioni che possono essere per loro importanti. Ciò non depone contro una pubblicazione come open source: gli strumenti di gestione del codicefootnote:[p. es. GitHub] offrono un ampio supporto per simili scenari, e adattamenti e correzioni di errori possono essere ripresi selettivamente in entrambe le direzioni. + +Una ripartizione dei costi è tipicamente difficile con questo modello. + +==== Comune (la Confederazione ha la direzione o partner con pari diritti) + +Le decisioni su roadmap e priorità dovrebbero essere coordinate e prese congiuntamente con gli altri membri della community. La Confederazione partecipa quale membro della community, ma non è l'organizzazione capofila. + +Affinché la decisione comune funzioni, strutture e regole devono essere stabilite preventivamente. Ciò definisce anche come i costi di attuazione degli adattamenti decisi congiuntamente sono ripartiti tra le parti. + +Con questo modello si crea un'unica versione dell'applicazione, utilizzata poi da tutti i membri. I costi complessivi risultano pertanto nettamente inferiori rispetto alle altre varianti. La flessibilità dei singoli utenti è tuttavia minore ed essi devono coordinare preventivamente le proprie richieste di adattamento con tutti gli altri. La decisione è più lenta e più laboriosa. + +Questo modello è particolarmente adatto ad applicazioni da sviluppare congiuntamente con altre organizzazioni chiaramente definite (p. es. i Cantoni). + +==== Organizzazione aperta + +In questo modello i processi e le strutture sono definiti soltanto in modo lasso. La Confederazione mantiene formalmente il controllo, ma è aperta a contributi e adattamenti. + +Non viene definita alcuna roadmap, o soltanto una molto sommaria; il consenso è raggiunto informalmente e in discussioni direttamente sulla piattaforma di pubblicazione. La community stessa è piuttosto dinamica; i membri possono essere molto attivi per un certo periodo e poi ritirarsi. + +Questo modello è adatto anche ad applicazioni più piccole già in uso produttivo e «concluse». È inoltre di regola la forma migliore per applicazioni o componenti a orientamento tecnico che si rivolgono potenzialmente a un pubblico più ampio non definibile con precisione in anticipo. + +==== Terzi + +In questo modello i processi e le strutture sono definiti da terzi e l'autorità federale è membro della community senza averne la direzione. Ciò può derivare dal fatto che il progetto è stato per esempio definito da un altro Stato o Cantone. Oppure può darsi che la Confederazione non sia interessata a proseguire essa stessa il programma e trasferisca tale compito. + +=== Coinvolgimento dei fornitori + +Per il coinvolgimento dei fornitori esistono in linea di principio le seguenti possibilità: + +[loweralpha] +. *Fornitore quale mandatario*: è in linea di principio considerato sostituibile a medio termine. Il fornitore deve sviluppare l'applicazione in modo economico e con alta qualità sulla base delle commesse della gestione del prodotto (o della community), ma ha al massimo un'influenza consultiva su roadmap e priorità. +. *Partner a lungo termine con codecisione*: devono poter codeterminare attivamente lo sviluppo. Ciò rafforza il loro ruolo ed essi sono potenzialmente disposti a investire essi stessi nell'applicazione. Tipicamente, in questo modello, i fornitori distribuiscono il software e cercano attivamente nuovi clienti. +. *Indipendente:* i fornitori stabiliscono da sé se e come intendono lavorare al progetto. Ciò può accadere per esempio se più fornitori intendono generare attività proprie sulla base del software. Licenze liberali possono potenzialmente favorirlo. Può accadere anche se la strategia della Confederazione diverge da quella del fornitore. In tale scenario è probabile che il fornitore crei un fork. +. *Direzione*: se il fornitore assume la gestione del prodotto, ne ha la direzione. Lo sviluppo è allora determinato da lui. D'altro canto ciò può anche significare che l'Amministrazione federale deve assumersi ben poca responsabilità. Con una pubblicazione minima è possibile che il fornitore assuma tale ruolo di propria iniziativa. + +Se il fornitore assume un ruolo forte, ciò comporta vantaggi per l'Amministrazione federale: mediante una commercializzazione attiva dell'applicazione vi è la possibilità che la community cresca più rapidamente e più fortemente, riducendo così più velocemente i costi per membro. + +Se si sceglie un modello con forte codecisione dei fornitori, occorre vigilare affinché non ne derivi una deroga alle prescrizioni del diritto degli acquisti pubblici. Di regola è consigliabile coinvolgere almeno due fornitori per non creare una dipendenza troppo forte da uno solo. Dovrebbe inoltre sussistere la possibilità che altri fornitori aderiscano alla community. + +=== Ripartizione dei costi + +Per ripartire i costi di manutenzione, sviluppo ulteriore e nuove funzionalità sono disponibili le seguenti opzioni: + +[loweralpha] +. *Organizzazioni in seno alla Confederazione*: in particolare nella costituzione di ecosistemi o se l'autorità federale mantiene il controllo totale, essa deve anche sostenerne i costi. +. *Ciascuno per sé*: ognuno paga da sé le modifiche che desidera. Se necessario si decide caso per caso di finanziare congiuntamente determinate estensioni. I costi ricorrenti sono fatturati secondo una chiave di ripartizione o a richiesta. +. *Principio di causalità*: chi ha effettivamente bisogno delle prestazioni o funzionalità le paga. Possono essere applicate tariffe orarie standardizzate. +. *Chiave di ripartizione*: i costi sono ripartiti all'interno della community secondo una chiave definita. Soltanto le estensioni specifiche vi derogano. Queste dovrebbero essere pagate direttamente dagli utenti interessati. Il divisore dei costi può essere per esempio la dimensione del Cantone interessato o il numero di utenti. Riguardo alla chiave di ripartizione cfr. anche il capitolo «Ripartizione dei costi». +. *Contributo*: quando l'autorità federale apporta soltanto personale a un progetto esistente. + +Fondamentalmente la variante b (ripartizione dei costi) ha di regola senso soltanto se esiste anche una gestione comune del prodotto come nella variante b (comune). Soltanto chi può avere voce in capitolo sarà disposto a sostenere i costi conseguenti alle decisioni. + +=== Supporto + +Nell'ambito della ripartizione dei costi e dell'onere occorre chiarire chi fornisce quale supporto. Secondo l'art. 9 LMeCA è possibile una pura pubblicazione minima. Tale variante può non produrre l'effetto desiderato e non costituisce di per sé una community in cui l'autorità federale abbia influenza. + +[loweralpha] +. *Pubblicazione minima*: nessun supporto (ossia la pubblicazione avviene di regola senza supporto organizzato e senza partecipazione dell'autorità federale). +. *Supporto da parte della Confederazione*: l'autorità federale (o il suo fornitore di prestazioni) fornisce un supporto definito. +. *Supporto da parte di terzi*: l'autorità federale o la community definisce un'organizzazione di supporto. + +L'effetto da conseguire, p. es. sull'ecosistema svizzero o un finanziamento iniziale di una community, può indurre la Confederazione a fornire supporto. L'entità del supporto va naturalmente definita. In linea di principio può anche essere riscosso un emolumento. Per via dei meccanismi della Confederazione, i fornitori di prestazioni o i fornitori sono più verosimilmente in grado di offrire un supporto commerciale. + +Gli uffici possono offrire supporto a pagamento conformemente alla LMeCA (eventualmente anche tramite fornitori di prestazioni e terzi). A tal fine devono pubblicare i relativi emolumenti sul proprio sito web, poiché la necessaria base legale sussiste. Il collegamento al sistema di pagamento può essere discusso con il DFF. + +Esempi di supporto ed emolumenti figurano nell'allegato G. + +=== Sviluppo + +Anche la metodologia fondamentale dello sviluppo può influire sul tipo di community. + +[loweralpha] +. *Interno*: l'utilizzo di repository interni significa che terzi non possono collaborare direttamente. Più rigorosa è la separazione, maggiore è l'onere di integrazione che la Confederazione deve sostenere se intende riprendere estensioni di terzi. Anche il processo di pubblicazione è più complesso. +. *Terzi*: o un fornitore lavora per conto proprio, oppure il prodotto già avviato o diretto da terzi è sviluppato secondo regole definite. +. *Aperto*: lo sviluppo software avviene direttamente in un repository pubblico. La pubblicazione secondo la LMeCA è così ampiamente garantita. Gli oneri si producono durante lo sviluppo. In tale scenario la collaborazione con terzi può avvenire anche prima (e più facilmente). + +== Contenuti dettagliati per il concetto di community + +Il presente capitolo fornisce indicazioni per la redazione del concetto di community sulla base delle decisioni di principio prese (secondo il capitolo 5). + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +aperto / Partner / Confederazione:: +Contenuti o suggerimenti, se le decisioni di principio sono: + +Gestione del prodotto c) Organizzazione aperta + +Coinvolgimento dei fornitori: b) Fornitore quale partner + +Ripartizione dei costi: b) Ciascuno per sé + +_Il testo di cui sopra può essere copiato nel modello e adattato._ + +Comune / - / Ciascuno per sé:: +Contenuti o suggerimenti, se le decisioni di principio sono: + +Gestione del prodotto b) Sviluppo comune + +Coinvolgimento dei fornitori: a) o b) (non rilevante) + +Ripartizione dei costi: c) Principio di causalità o d) Ripartizione dei costi + +Comune / - / Causante:: +{empty} + +Il concetto di community dovrebbe essere un documento dinamico, adattabile d'intesa con la community. Il concetto dovrebbe rispecchiare la situazione attuale e proporre opzioni di sviluppo future. Se in seguito aderiscono altri membri alla community, l'organizzazione e i processi possono essere ulteriormente elaborati e possono essere introdotti meccanismi più complessi. I sottocapitoli seguenti seguono direttamente la struttura proposta del concetto di community (cfr. capitolo 4). + +Se la gestione del prodotto spetta a terzi, questi definiscono i concetti per la community. + +=== Dati essenziali + +I seguenti dati essenziali dovrebbero essere elaborati e pubblicati per ogni community, affinché i potenziali interessati possano registrarsi per il software e la community: + +* Nome del software +* Repository +* Proprietario +* Unità organizzativa / ufficio responsabile +* Indirizzo di contatto +* Licenza utilizzata +* Livello di supporto +* Progetto esistente + +Queste indicazioni possono essere tutte rappresentate con publiccode.yml.footnote:[https://yml.publiccode.tools/] + +=== Obiettivi + +L'obiettivo dovrebbe contenere lo scopo effettivo o la «visione» dell'applicazione. Tale visione dovrebbe figurare anche nel file *README.md* del repository (cfr. link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[lista di controllo Em002-2.2 Analisi e preparazione OSS]). + +Al tempo stesso andrebbe descritto che cosa persegue la community: + +* Chi deve aderire? +* Chi sono i potenziali interessati? +* Vanno ricercati attivamente nuovi membri? +* Quali sono gli obiettivi principali perseguiti con la pubblicazione come open source? + +=== Organizzazione e governance + +In linea di principio, per i nuovi sviluppi si mira a che la Confederazione sia titolare dei diritti principali sul codice sorgente. + +Il tipo di conduzione del progetto dipende da quale organizzazione aveva la direzione (SAFe, HERMES) in seno alla Confederazione. Per la forma organizzativa va sempre perseguito un onere amministrativo minimo (esistente anziché nuovo; società semplice anziché associazione). + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / - / Interno:: +Poiché la Confederazione mantiene il controllo diretto, non sono necessarie strutture organizzative supplementari. + +L'ente che pubblica (p. es. un ufficio federale) resta proprietario e assume tutti i compiti di coordinamento. In tal caso il capitolo «Organizzazione» può essere tenuto molto breve. + +Comune / - / Interno:: +Per questo scenario si raccomanda di regola l'organizzazione quale *società semplice*. + +Affinché lo sviluppo comune e il coordinamento di roadmap e requisiti siano possibili, è consigliabile costituire due organi, ciascuno con un partecipante per membro della community: ++ +-- +* Organo direttivo: definisce strategia e priorità. +* Gruppo specialistico: elabora requisiti e contenuti concreti a livello tecnico. A seconda dell'ampiezza può essere istituito anche un gruppo specialistico per ogni tema. +-- ++ +Proprietario del codice è l'ufficio che lo ha pubblicato. ++ +Se le strutture diventano più complesse o se sono coinvolti più di cinque utenti o membri supplementari, può valere la pena esaminare se la community non sia meglio organizzata come associazione. Si confrontino le spiegazioni della variante immediatamente sottostante. + +Comune / - / Terzi:: +Si raccomanda l'organizzazione quale *associazione*. + +O viene fondata un'associazione appositamente per l'applicazione, oppure l'applicazione viene trasferita a un'associazione esistente. Un'associazione è raccomandata perché altrimenti la ripartizione dei costi diventa complessa e i compiti di coordinamento comportano verosimilmente lavoro sufficiente per assumere un gerente a tempo parziale per l'associazione. ++ +I diritti sul codice sono allora trasferiti all'associazione, che assume la gestione della community e le ordinazioni presso i fornitori. + +Comune / Mandatario / Interno:: +Si raccomanda l'organizzazione quale *associazione*. O viene fondata un'associazione appositamente per l'applicazione, oppure l'applicazione viene trasferita a un'associazione esistente. Un'associazione è raccomandata perché altrimenti la ripartizione dei costi diventa complessa e i compiti di coordinamento comportano verosimilmente lavoro sufficiente per assumere un gerente a tempo parziale per l'associazione. ++ +I diritti sul codice sono allora trasferiti all'associazione, che assume la gestione della community e le ordinazioni presso i fornitori. + +Qui i fornitori non sono membri dell'associazione, bensì soltanto mandatari. Il gerente non dovrebbe essere fornito da un fornitore. + +Comune / Mandatario / Terzi:: +Si raccomanda l'organizzazione quale *associazione*. O viene fondata un'associazione appositamente per l'applicazione, oppure l'applicazione viene trasferita a un'associazione esistente. Un'associazione è raccomandata perché altrimenti la ripartizione dei costi diventa complessa e i compiti di coordinamento comportano verosimilmente lavoro sufficiente per assumere un gerente a tempo parziale per l'associazione. + +I diritti sul codice sono allora trasferiti all'associazione, che assume la gestione della community e le ordinazioni presso i fornitori. + +I fornitori sono membri dell'associazione; il gerente può anche essere fornito da un fornitore. + +aperto / - / Interno:: +Non vi è *alcuna necessità di una descrizione dettagliata di un'organizzazione*, poiché essa è deliberatamente concepita in modo aperto. È tuttavia importante stabilire chi riceve e tratta le richieste esterne (responsabilità). Va inoltre determinato se e in quale misura persone esterne possono essere coinvolte: ++ +-- +* Nessuna integrazione diretta: gli esterni possono soltanto presentare suggerimenti e contributi (come pull request). +* Integrazione quali contributori: gli esterni che apportano contributi frequenti e di qualità sono integrati direttamente. +* Trasferimento a esterni possibile: se, dopo la pubblicazione, gli esterni contribuiscono allo sviluppo più dell'organizzazione che pubblica, l'applicazione può anche essere loro trasferita. +-- ++ +L'organizzazione che pubblica resta proprietaria. Questa variante corrisponde all'organizzazione dei progetti open source «classici»; cfr. per esempio https://opensource.guide/leadership-and-governance/ per maggiori informazioni. + +aperto / Mandatario / Interno:: +Non vi è *alcuna necessità di una descrizione dettagliata di un'organizzazione*, poiché essa è deliberatamente concepita in modo aperto. È tuttavia importante stabilire chi riceve e tratta le richieste esterne (responsabilità). Va inoltre determinato se e in quale misura persone esterne possono essere coinvolte: ++ +-- +* Nessuna integrazione diretta: gli esterni possono soltanto presentare suggerimenti e contributi (come pull request). +* Integrazione quali contributori: gli esterni che apportano contributi frequenti e di qualità sono integrati direttamente. +* Trasferimento a esterni possibile: se, dopo la pubblicazione, gli esterni contribuiscono allo sviluppo più dell'organizzazione che pubblica, l'applicazione può anche essere loro trasferita. +-- ++ +L'organizzazione che pubblica resta proprietaria. + +Questa variante corrisponde all'organizzazione dei progetti open source «classici»; cfr. per esempio https://opensource.guide/leadership-and-governance/ per maggiori informazioni. + +Il fornitore dovrebbe assumere soltanto compiti di coordinamento puramente tecnici (code review, valutazione). + +Terzi / Partner / Interno:: +Non vi è *alcuna necessità di una descrizione dettagliata di un'organizzazione*, poiché essa è deliberatamente concepita in modo aperto. È tuttavia importante stabilire chi riceve e tratta le richieste esterne (responsabilità). Va inoltre determinato se e in quale misura persone esterne possono essere coinvolte: ++ +-- +* Nessuna integrazione diretta: gli esterni possono soltanto presentare suggerimenti e contributi (come pull request). +* Integrazione quali contributori: gli esterni che apportano contributi frequenti e di qualità sono integrati direttamente. +* Trasferimento a esterni possibile: se, dopo la pubblicazione, gli esterni contribuiscono allo sviluppo più dell'organizzazione che pubblica, l'applicazione può anche essere loro trasferita. +-- ++ +L'organizzazione che pubblica resta proprietaria. Questa variante corrisponde all'organizzazione dei progetti open source «classici»; cfr. per esempio https://opensource.guide/leadership-and-governance/ per maggiori informazioni. + +Riguardo alla governance possono essere consultati anche _[BITKOM2023]_ capitolo 4.1, _[IZqCab2023]_ o https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md#governance-models. + +Esempi di statuti associativi figurano nell'allegato E. + +Nota: poiché la pubblicazione deve essere garantita conformemente all'art. 9 LMeCA, l'Amministrazione federale deve assicurare che essa non possa essere improvvisamente ritirata (cfr. le «direttive Open Source negli acquisti — acquisto di software secondo l'art. 9 LMeCA» _[BBL-WL]_, numero V.2). + +=== Roadmap e processo di modifica + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / Mandatario / -:: +L'autorità federale definisce la roadmap e decide quali modifiche vengono attuate. A tal fine sono utilizzati i processi standard dell'ufficio XY. + +Confederazione / Partner / -:: +L'autorità federale definisce la roadmap in collaborazione con l'impresa XY. Essa decide quali modifiche vengono attuate. A tal fine sono utilizzati i processi standard dell'ufficio XY. + +Comune / - / Interno:: +Il processo di elaborazione della roadmap e di approvazione delle modifiche va stabilito dai membri della società o dell'associazione. A seconda della struttura dei membri (numero, rapporto dimensionale ecc.) possono essere adeguati altri processi. + +I processi devono tuttavia prevedere misure per la risoluzione dei conflitti e la formazione della maggioranza. + +Comune / - / Terzi:: +Il processo di elaborazione della roadmap e di approvazione delle modifiche va stabilito dai membri della società o dell'associazione. A seconda della struttura dei membri (numero, rapporto dimensionale ecc.) possono essere adeguati altri processi. ++ +I processi devono tuttavia prevedere misure per la risoluzione dei conflitti e la formazione della maggioranza. ++ +Con l'aggiunta che va stabilita anche una chiave di ripartizione dei costi. Occorre inoltre riflettere su come trattare la ripartizione dei costi per adattamenti non desiderati dai membri interessati. In particolare nelle associazioni con membri di dimensioni disuguali possono verificarsi situazioni in cui un grande membro (p. es. l'autorità federale) sostiene una parte rilevante dei costi di un'estensione senza trarne alcun beneficio. + +aperto / - / -:: +_Esempio, non adatto a tutte le situazioni_ + +Non occorre elaborare una roadmap; l'applicazione soddisfa attualmente le esigenze. ++ +Le modifiche sono decise in una discussione aperta e si ricerca un consenso. La decisione finale spetta al proprietario del codice (Confederazione Svizzera). + +=== Processo di sviluppo + +Se entra in gioco lo sviluppo aperto, esso va definito qui. Sono importanti la ripartizione dei compiti e l'indicazione delle posizioni centrali nel concetto di community. Nonché il modo in cui è garantita la sicurezza dei contenuti del repository. + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / - / -:: +I diritti di committer (accesso in scrittura al codice) spettano alle persone/agli enti/ai fornitori selezionati dalla Confederazione. Alla scadenza del contratto i rispettivi diritti sono revocati. ++ +I fornitori di prestazioni e i fornitori sono responsabili dello svolgimento del processo tecnico di code review per i contributi esterni accettati nel merito dalla Confederazione. Essi rispondono della qualità tecnica. I fornitori sono indennizzati per tale lavoro dalla Confederazione. + +Comune / Mandatario / Interno:: +In linea di principio tutti gli enti incaricati da un membro della community ricevono l'accesso in scrittura al codice (diritti di committer). Alla scadenza del contratto i rispettivi diritti sono revocati. ++ +Se il codice modificato riguarda settori centrali dell'applicazione, tutte le modifiche devono essere esaminate da un ente appositamente incaricato dalla community. Tale ente risponde della qualità tecnica dell'applicazione. Esso è inoltre competente per l'esame delle modifiche accettate nel merito dalla community. + +Comune / Partner / Terzi:: +I diritti di committer (accesso in scrittura al codice) spettano ai membri della community. Tali persone si organizzano da sé e assumono congiuntamente la responsabilità della qualità del codice. ++ +Se un membro della community incarica un fornitore esterno di un adattamento o di un'estensione, l'adattamento è esaminato da un membro della community. Esso è indennizzato a tal fine dal committente. ++ +Le modifiche al nucleo dell'applicazione devono essere esaminate da un secondo membro della community. ++ +I fornitori membri della community sono inoltre responsabili dell'esame dei contributi esterni e del nuovo codice tecnico accettato nel merito dall'associazione. + +aperto / - / -:: +Inizialmente i diritti di committer spettano agli sviluppatori o ai loro datori di lavoro. I diritti di committer sono concessi a tutti gli sviluppatori che contribuiscono attivamente al progetto per più mesi e dimostrano un'adeguata competenza sociale. ++ +I singoli sviluppatori conservano in linea di principio i propri diritti di committer, anche se cambiano datore di lavoro o se la Confederazione sceglie un altro fornitore. I diritti di committer si estinguono soltanto se vengono ceduti volontariamente o se la maggioranza degli altri committer ne decide la revoca. ++ +La Confederazione ha il diritto di designare quali committer singoli sviluppatori delle imprese che incarica. Non ha il diritto di revocare a qualcuno i diritti di committer senza motivo. ++ +Le code review sono effettuate da almeno una persona che agisce quale committer. I committer si organizzano da sé. ++ +La Confederazione si impegna a indennizzare il lavoro di revisione nella misura in cui ciò le sia finanziariamente possibile. + +=== Ripartizione dei costi e fornitori + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / Mandatario / Interno:: +I fornitori sono selezionati periodicamente mediante bandi OMC o una procedura per incarico diretto (a seconda dell'ampiezza delle prestazioni di manutenzione). + +Confederazione / Partner / -:: +*Importante:* verificare preventivamente se ciò sia ammissibile sotto il profilo del diritto degli acquisti pubblici nel caso concreto. ++ +Completeremo la documentazione su questo punto. La Confederazione sceglie il fornitore XXX quale partner strategico e mira a una cooperazione a lungo termine. + +Comune / Mandatario / Interno:: +Ogni membro della community incarica autonomamente uno o più fornitori di software di attuare gli adattamenti e le estensioni di cui necessita. Per gli adattamenti desiderati da più membri, la ripartizione dei costi è concordata caso per caso. Il membro con la quota di costi maggiore è responsabile della scelta e dell'incarico al fornitore. (Disciplinamenti per la manutenzione del software) + +Comune / Mandatario / Terzi:: +L'associazione seleziona periodicamente i fornitori di software in modo centralizzato mediante bandi OMC o procedure per incarico diretto (a seconda dell'ampiezza delle prestazioni di manutenzione). I costi sono attribuiti ai membri secondo una chiave: (da definire: per popolazione, utenti ecc.) + +Comune / Partner / Interno:: +Ogni membro della community incarica autonomamente uno o più fornitori di software di attuare gli adattamenti e le estensioni di cui necessita. Per gli adattamenti desiderati da più membri, la ripartizione dei costi è concordata caso per caso. Il membro con la quota di costi maggiore è responsabile della scelta e dell'incarico al fornitore. ++ +_(Disciplinamenti per la manutenzione del software)_ Se necessario integrati da un contributo dei fornitori partecipanti. Esempio: _Ogni impresa di sviluppo software membro della community si impegna a investire annualmente almeno XY giorni lavorativi a proprie spese nello sviluppo, nell'aggiornamento tecnologico o nel marketing dell'applicazione._ + +Comune / Partner / Terzi:: +L'associazione seleziona periodicamente i fornitori di software in modo centralizzato mediante bandi OMC o procedure per incarico diretto (a seconda dell'ampiezza delle prestazioni di manutenzione). I costi sono attribuiti ai membri secondo una chiave: (da definire: per popolazione, utenti ecc.) Se necessario integrati dall'aggiunta: _Ogni impresa di sviluppo software membro della community si impegna a investire annualmente almeno XY giorni lavorativi a proprie spese nello sviluppo, nell'aggiornamento tecnologico o nel marketing dell'applicazione._ + +Terzi / Mandatario / -:: +I fornitori sono selezionati periodicamente mediante bandi OMC o una procedura per incarico diretto (a seconda dell'ampiezza delle prestazioni di manutenzione). Con l'aggiunta: _I miglioramenti apportati dai potenziali fornitori e le loro attività nella community sono considerati quale fattore nella valutazione._ ++ +Le modifiche desiderate da esterni non sono finanziate dalla Confederazione, bensì devono essere commissionate e pagate da essi stessi. + +Terzi / Partner / -:: +I fornitori sono selezionati periodicamente mediante bandi OMC o una procedura per incarico diretto (a seconda dell'ampiezza delle prestazioni di manutenzione). Con l'aggiunta: _I miglioramenti apportati dai potenziali fornitori e le loro attività nella community sono considerati quale fattore nella valutazione. Le modifiche desiderate da esterni non sono finanziate dalla Confederazione, bensì devono essere commissionate e pagate da essi stessi._ + +=== Marketing + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / Mandatario / -:: +La Confederazione non commercializza attivamente l'applicazione, ma la pubblica su piattaforme di software open source. La pubblicazione dell'applicazione è annunciata negli organi specializzati. Se si manifestano interessati, esaminiamo se costituire una community comune o proseguire con la loro versione del software. + +Comune / Partner / -:: +In aggiunta: + +I fornitori possono commercializzare l'applicazione e cercare ulteriori interessati. La Confederazione può essere citata come referenza. Accettiamo consapevolmente che ne possano derivare versioni divergenti del software. + +Comune / Mandatario / Interno:: +L'applicazione è commercializzata dai membri o dall'associazione. + +Comune / Partner / Interno:: +L'applicazione è commercializzata dai fornitori. + +Comune / - / Terzi:: +L'applicazione è commercializzata dall'associazione, dalla società semplice e dai loro membri. + +aperto / - / -:: +L'applicazione può essere commercializzata dai fornitori, oppure si può rinunciare a un marketing esplicito. ++ +Alternativa senza marketing esplicito: la Confederazione non commercializza attivamente l'applicazione, ma la pubblica su piattaforme di software open source. Negli organi specializzati segnaliamo di aver pubblicato l'applicazione e che una collaborazione è benvenuta. Mostriamo il software agli interessati e cerchiamo di integrarli nei nostri processi di elaborazione della roadmap. + +=== Trattamento dei contributi esterni + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Confederazione / Mandatario / -:: +I contributi e le richieste esterni devono essere trattati anche se la Confederazione resta l'unica decisore riguardo al software (salvo in caso di pubblicazione minima, dove un fork è inevitabile). Proponiamo il seguente modo di procedere: ++ +*Trattamento degli errori segnalati* + +Cerchiamo di riprodurre gli errori segnalati da persone esterne e chiediamo precisazioni se necessario. Se la riproduzione riesce, la Confederazione commissiona la correzione degli errori. Se l'errore non può essere verificato o se l'onere per correggerlo è sproporzionato, ci scusiamo con la persona che ha segnalato l'errore e le chiediamo se potrebbe presentare una pull request per porvi rimedio. ++ +*Trattamento delle richieste* + +Rispondiamo a ogni richiesta in entrata. Se una richiesta non può essere chiarita con un onere ragionevole e un ulteriore impiego di tempo appare inefficiente, ci scusiamo richiamando le risorse limitate e offriamo di mettere in contatto la persona con un fornitore per una consulenza approfondita. ++ +*Trattamento delle pull request* + +Esaminiamo con cura ogni pull request. Per evitare oneri inutili al contributore, segnaliamo immediatamente se qualcosa contraddice la nostra roadmap o se è dubbio che accetteremo il contributo. La Confederazione decide autonomamente e secondo criteri tecnici quali contributi accettare. Le correzioni di errori che hanno superato il processo di revisione sono sempre accettate. ++ +*Trattamento dei fork* + +Sosteniamo i fork della nostra applicazione. Chi introduce l'applicazione dovrebbe creare un proprio fork. Esaminiamo i fork che ne risultano almeno una volta all'anno e riprendiamo le estensioni valide e adeguate. + +Comune / - / -:: +Per esterni si intendono i contributi provenienti dall'esterno della community definita (membri dell'associazione). Differenze rispetto a quanto sopra: + +*Trattamento dei fork* + +Vogliamo evitare fork (duraturi) dell'applicazione. Gli interessati dovrebbero invece aderire direttamente alla community. All'interno della community cerchiamo di assicurare che tutti i membri utilizzino la versione principale. + +Aperto / - / -:: +La costituzione di una community funzionante e di una cultura aperta è per noi importante. ++ +*Trattamento degli errori segnalati* + +Cerchiamo di riprodurre e correggere gli errori segnalati. Presupponiamo la collaborazione attiva delle persone che segnalano. Se possibile, esse dovrebbero creare direttamente una pull request con una correzione dell'errore. ++ +*Trattamento delle richieste* + +Trattiamo ogni richiesta entro al massimo una settimana. Le richieste di contributori attivi sono trattate in via prioritaria e in modo approfondito. Cerchiamo di coinvolgere altri membri nel trattamento delle richieste. ++ +*Trattamento delle pull request* + +Vogliamo ricevere il maggior numero possibile di pull request di elevata qualità. Coinvolgiamo tutti i contributori attivi nelle revisioni e nella valutazione tecnica e specialistica delle pull request. Per i contributi controversi cerchiamo di giungere a una decisione mediante una votazione informale. ++ +*Trattamento dei fork* + +Cerchiamo di rendere superflui i fork mediante una gestione della community attiva e aperta. Se nondimeno emergono fork, li esaminiamo attivamente e cerchiamo di riprendere le estensioni e i miglioramenti ivi sviluppati. In tali casi sollecitiamo attivamente pull request. + +In generale va rilevato che i contributi possono spaziare dal sostegno ad altri utenti fino all'assunzione della responsabilità di intere parti di un progetto (cfr. _[BITKOM2023]_ capitolo 4.2). + +=== Esercizio dell'applicazione + +_Gestione del prodotto / Fornitore quale / Sviluppo -- Proposta_ + +Comune / - / -:: +Un esercizio centralizzato può essere offerto in opzione dall'associazione centrale, nel senso del Software as a Service (SaaS). Va esaminato se ciò è desiderato. + +- / Partner / -:: +Va precisato se il fornitore debba anche esercire il software. + +- / Direzione / -:: +Va indicato che il fornitore è responsabile dell'esercizio. + +I livelli di supporto e i contatti di supporto dovrebbero parimenti essere precisati in questo capitolo. + +== Informazioni importanti per i responsabili di community + +=== Ci vuole tempo + +La costituzione di community è qualcosa che va pianificato a lungo termine. Perseveranza e costanza sono due qualità importanti per una community di successo. + +=== Ulteriori suggerimenti per la costituzione di una community + +Ulteriori suggerimenti per una buona gestione della community figurano su https://opensource.guide/code-of-conduct/ e https://opensource.guide/best-practices/. + +=== Comunicazione + +La pubblicazione di software e documentazione apre all'Amministrazione federale un nuovo canale di comunicazione. Se ciò non avviene con cura e professionalità, l'immagine pubblica della Confederazione può risentirne. + +Le community OSS dell'Amministrazione federale si trovano in un campo di tensione riguardo alla comunicazione: da un lato valgono le *prescrizioni generali di comunicazione*, dall'altro la community deve consentire una *collaborazione formale e informale semplice* oltre i confini organizzativi, preferibilmente senza controlli di qualità e approvazioni formali. + +L'utilizzo di repository pubblici ed eventualmente di issue tracking e wiki pubblici significa che le dichiarazioni dei singoli collaboratori del progetto sono visibili al pubblico senza filtri. Ciò richiede ai collaboratori del progetto un atteggiamento professionale e il rispetto di standard qualitativi per le pubblicazioni in simili contesti. + +Nei progetti OSS ciò è normalmente disciplinato mediante il *Code of Conduct*. Il codice di comportamento dell'Amministrazione federalefootnote:[https://www.epa.admin.ch/dam/epa/it/dokumente/aktuell/medienservice/120_verhaltenskodex_i.pdf.download.pdf/120_verhaltenskodex_i.pdf] è formulato in modo molto generale, ma il principio centrale è qui applicabile: «I collaboratori adempiono i loro compiti in modo responsabile, integro e leale. Anche nella vita privata badano a non pregiudicare la reputazione, la credibilità e l'immagine della Confederazione.» + +=== Sviluppo aperto + +Se lo sviluppo software è previsto sin dall'inizio in un repository aperto, la pubblicazione avviene automaticamente. Le liste di controllo determinanti secondo le istruzioni link:em002-2.pdf[Em002-2] vanno compilate all'inizio e i processi di sviluppo del fornitore di prestazioni o del fornitore devono consentirlo. Il vantaggio è che la community può essere costituita sin dal principio. Più organizzazioni possono inoltre collaborare allo sviluppo. + +I repository chiusi costituiscono una forma intermedia, ma sono impiegati per altri partner in una collaborazione. + +=== Gestione degli utenti + +Il progetto (o l'organizzazione promotrice) stabilisce se gli sviluppatori e gli altri collaboratori del progetto lavorano a nome proprio o in forma anonima. Se le persone non lavorano in forma anonima e dispongono già di login sulle piattaforme, è più semplice utilizzare questi (siano essi professionali o privati). + +La piattaforma dovrebbe in linea di principio consentire l'integrazione di terzi, poiché altrimenti nessuno sviluppatore esterno alla Confederazione potrà collaborare. + +Al momento dell'uscita dal progetto i relativi diritti sul progetto vanno cancellati. Ne è responsabile la gestione del prodotto. + +=== Fusione di community + +Ove possibile il numero di community andrebbe mantenuto ridotto. Ciò significa: + +* Se esiste già una community in cui è prevista una struttura analoga per problemi analoghi con le stesse persone, andrebbe utilizzata un'unica community. +* Più progetti correlati che si rivolgono allo stesso pubblico target possono essere riuniti in un'unica community. +* Non andrebbero create inutilmente strutture di community fondamentalmente diverse laddove ne esistano già. + +=== Trattamento dei contributi di terzi + +Il contributo di software ad altri progetti è trattato nel capitolo 3.3. Gli stessi principi valgono in senso inverso. + +Sono importanti i punti seguenti: + +* Va utilizzato un Contributor Licence Agreement adeguato per assicurare che il codice sorgente appartenga in seguito alla Confederazione (cfr. anche link:em002-3.pdf[Em002-3 Guida alle licenze OSS], capitolo sui Contributor Licence Agreement). Esso va firmato dal proprietario del contributo. +* Le conferme vanno archiviate. +* I contributi vanno esaminati prima dell'integrazione nella base di codice. +* Alle sottomissioni andrebbe risposto tempestivamente (issue, request, pull request) e trattandole nel modo più costruttivo possibile. +* Tutti i canali e i disciplinamenti di governance andrebbero indicati nel concetto di community, sul sito web e nel repository. + +=== Segnalazioni rilevanti per la sicurezza + +Oltre alle consuete segnalazioni di errori va previsto — ove la natura del progetto lo richieda — che le vulnerabilità rilevanti per la sicurezza possano essere segnalate in modo confidenziale, come avviene per esempio con un programma di bug bounty. + +I documenti di trustbroker.swiss possono servire da esempio: + +* https://github.com/trustbroker-swiss/trustbroker.swiss/blob/main/Security-and-Vulnerability-Disclosure.md + +=== Evitare i fork + +Se i fork sono naturali nel mondo open source, la reintegrazione di codice sorgente, funzionalità e così via provenienti da fork è tutt'altro che semplice. Può valere la pena rivolgersi alle persone o organizzazioni che stanno valutando un fork e tentare di mantenerle coinvolte nel progetto principale. Trovare un equilibrio tra interessi concorrenti è spesso necessario in tali casi. + +=== Ripartizione dei costi + +È opportuno concordare chiavi di ripartizione generali tra i partner principali. Queste possono essere adeguate ogni qualche anno o quando la situazione cambia fondamentalmente. Per un lavoro efficiente sul software i grandi partner dovrebbero piuttosto assumere quote un po' maggiori di quanto dovrebbero effettivamente (se necessario anche il coordinamento complessivo). L'organizzazione deve lavorare e non litigare sulle finanze. Se la collaborazione riguarda più progetti (per esempio le soluzioni settoriali nel settore delle ferrovie a scartamento normale), andrebbe utilizzata per tutti i progetti una chiave di ripartizione uniforme. Dal punto di vista delle autorità federali è un miglioramento se i costi non devono essere sostenuti da sole. + +Possibili criteri per le chiavi di ripartizione: + +* Stima della ripartizione dei benefici (p. es. tra un'autorità federale e un fornitore che spera in altri clienti) +* Numero di abitanti/utenti (p. es. tra uffici, Comuni, città) +* Capacità finanziaria (p. es. Cantoni) +* Prodotto interno lordo (p. es. tra Cantoni) +* Chi desidera maggiore controllo + +Per evitare discussioni, la chiave di ripartizione non dovrebbe essere semplicemente legata al budget annuale. Una clausola nello spirito del principio di causalità può consentire adeguamenti più rapidi per singoli partner, se questi sono disposti a pagare un supplemento. + +La chiave di ripartizione dovrebbe applicarsi anche alle spese generali, alla manutenzione/al supporto e a un minimo di sviluppo ulteriore. Queste parti andrebbero se possibile risolte a lungo termine. + +Va tenuto presente che, in presenza di finanziamenti di terzi, tali parti vorranno tipicamente maggiore voce in capitolo. La gestione della community deve essere attrezzata per farvi fronte. + +=== Prestazioni supplementari secondo l'art. 9 cpv. 5 e 6 LMeCA + +Le autorità federali possono (esse stesse, tramite fornitori di prestazioni o fornitori) erogare prestazioni supplementari, in particolare per l'integrazione, la manutenzione, la garanzia della sicurezza delle informazioni e il supporto. + +Il limite è che esse devono servire i compiti delle autorità e poter essere erogate con un onere proporzionato. + +Ne consegue che l'autorità federale non può essere l'impresa di sviluppo per terzi. Essa corregge errori, può trattare aspetti rilevanti per la sicurezza, può fornire un certo supporto e aiuto all'integrazione (tutte attività che contribuiscono a costituire una community). I nuovi sviluppi e le funzionalità supplementari per terzi dovrebbero orientarsi in primo luogo allo scopo di lavoro normale dell'autorità. Può naturalmente darsi che la messa a disposizione del software faccia parte del compito; in tal caso possono essere realizzati sviluppi in qualsiasi momento. Si rileva inoltre che lo sviluppo software non è il compito principale dell'autorità federale. + +Ciò significa che, se determinate funzionalità sono sviluppate essenzialmente in via esclusiva per terzi, esse vanno integrate in partenariato o tramite il fornitore. + +Per evitare problemi di diritto degli acquisti pubblici, nell'acquisto di software e prestazioni occorre badare a che funzionalità possano essere messe a disposizione di terzi (eventualmente soltanto terzi statali) dai fornitori. + +La fissazione degli emolumenti è già stata toccata nel capitolo «Supporto». La LMeCA costituisce già la base legale per tali emolumenti. Questi vanno comunicati sul sito web della rispettiva autorità federale. Esempi figurano nell'allegato G. + +L'art. 9 cpv. 6 stabilisce che di norma non si deve fare concorrenza al settore privato. Ciò significa che gli emolumenti non dovrebbero essere fissati troppo bassi e dovrebbero quantomeno coprire i costi. In caso di dubbio è preferibile fissare tariffe orarie troppo alte anziché troppo basse. + +In generale si raccomanda di lavorare con una fino a tre diverse tariffe orarie standard. + +Se un dipartimento federale intende definire eccezioni al cpv. 6, ciò non deve fare concorrenza al settore privato. In determinate circostanze può essere più semplice fissare gli emolumenti e aumentarli in caso di opposizione di imprese private effettivamente in grado di offrire la prestazione. + +=== Sovranità digitale + +Fintanto che la Confederazione non dispone di un proprio repository, per garantire la sovranità digitale si raccomanda di realizzare regolarmente copie dei repository pubblici. + +Va osservato che non viene copiato soltanto il codice sorgente, bensì anche altre informazioni quali issue tracking, wiki, configurazioni ecc. + +Occorre inoltre risolvere la gestione degli utenti per assicurare il controllo sul codice sorgente pubblicato. L'obiettivo generale è garantire uno sviluppo indipendente dalla rispettiva piattaforma e consentire alla community di cambiare.footnote:[Cfr. anche https://www.bfh.ch/de/aktuell/news/2024/neue-studie-digitale-souveraenitaet/] + +== Allegato + +=== Modifiche rispetto alla versione precedente + +* Aggiunto il capitolo 1 «L'essenziale in breve» +* Scopo della community aggiunto al capitolo 3 +* Aggiunti i capitoli 3.1–3.3 sulla collaborazione +* Nuovo capitolo 7.7 Trattamento dei contributi di terzi +* Precisato che i fornitori non dovrebbero pubblicare interamente di propria iniziativa (conformemente a _[BBL-WL]_, V.2) +* Menzionato publicode.yml +* Armonizzazione con il nuovo link:em002-7.pdf[Em002-7] +* Ulteriori modifiche e miglioramenti redazionali + +=== Riferimenti + +Cfr. _Em002 Linee guida strategiche per il software open source nell'Amministrazione federale_. + +=== Abbreviazioni + +Cfr. link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] ed link:em002-6.pdf[Em002-6 FAQ sull'OSS]. + +=== Esempi di concetti di community esistenti + +Nello spirito di una raccolta di best practice figurano di seguito concetti di community e documenti comparabili già elaborati. Non si tratta necessariamente soltanto di concetti di autorità federali, ma anche di altre organizzazioni. + +* GERES Community (http://geres-community.ch) + +Classificazione: + +* Gestione del prodotto a) Sviluppo comune +* Fornitore piuttosto a) Mandatario +* Ripartizione dei costi: b) Ripartizione dei costi + +Nota: il registro comunale GERES non è open source, ma molti aspetti dell'organizzazione possono essere rilevanti anche per applicazioni open source. Documenti: statuti (pubblici) e regolamento interno (su richiesta). + +* https://www.igovportal.ch[iGov Portal] + +#Il presente capitolo contiene attualmente concetti del Cantone di Berna e sarà completato non appena saranno disponibili esempi federali.# + +=== Esempi di collaborazioni + +I seguenti esempi illustrano come sono state strutturate le collaborazioni. + +=== Collaborazione: ZenDiS in Germania + +ZenDiSfootnote:[https://www.zendis.de/en[Pagina iniziale ZenDiS: Co-creating Digital Sovereignty]] è un'organizzazione il cui obiettivo è ridurre la dipendenza nell'amministrazione pubblica (principalmente in Germania) promuovendo il software open source. + +[mermaid,align="center",alt="Obiettivi e approcci per rafforzare la sovranità digitale (ZenDiS)"] +.... +block-beta + columns 12 + H1["Obiettivi"]:12 + G1["I. Possibilità di cambiare fornitore"]:4 G2["II. Capacità di configurazione"]:4 G3["III. Influenza sui fornitori"]:4 + H2["Approcci risolutivi"]:12 + B1["1. Analisi e gestione previdenti
delle dipendenze"]:3 B3["3. Modularità indipendente dal
fornitore, standard (aperti)
e interfacce informatiche"]:3 B5["5. Configurazione cooperativa
delle soluzioni informatiche"]:3 B7["7. Prescrizioni giuridiche"]:3 + B2["2. Acquisto o sviluppo di
soluzioni informatiche
alternative (p. es. OSS)"]:3 B4["4. Sviluppo di competenze
digitali e conoscenze
specialistiche"]:3 B6["6. Comprensione e
procedura comuni"]:3 B8["8. Pilotaggio politico"]:3 + classDef highlight fill:#dae8fc,stroke:#000000,color:#000000 + class B2 highlight +.... + +Figura 1: Obiettivi e approcci per rafforzare la sovranità digitale (ZenDiS) + +A tal fine ZenDiS collabora con partner strategici. + +Una cooperazione tra l'Amministrazione federale e ZenDiS non dovrebbe quindi essere possibile senza restrizioni, e un coordinamento non sarebbe vincolante. Ciò può cambiare con il tempo. + +Concretamente l'Amministrazione federale dovrebbe costituire una propria organizzazione per la Svizzera e coordinarsi informalmente con ZenDiS. Ciò potrebbe eventualmente avvenire tramite eOperations, fermo restando che eOperations diventa attiva soltanto quando è annunciato un fabbisogno concreto ed è messo a disposizione un budget. Una motivazione per una simile organizzazione parallela potrebbe essere trovata nel contesto del governo elettronico o della LMeCA. + +Nota: ZenDiS è soggetta al diritto degli acquisti pubblici dell'UE e della Germania. Vi sono differenze rilevanti rispetto alla Svizzera. ZenDiS non può quindi essere replicata uno a uno in Svizzera, e una cooperazione con ZenDiS non è agevole. + +=== Collaborazione: Open Trip Planner (OTP) + +Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] è un'applicazione open source per la pianificazione di viaggi. È organizzata come progetto della Software Freedom Conservancy a New York. Singoli sviluppatori sono impiegati presso imprese di trasporto e fornitori. È degno di nota che un attore del settore pubblico — concretamente ENTURfootnote:[https://entur.no/] — abbia assunto uno dei ruoli guida. ENTUR sviluppa in primo luogo per il proprio fabbisogno, ma ha anche un orientamento cooperativo, in particolare per i Paesi nordici. ENTUR è organizzata quale società di proprietà del Ministero norvegese dei trasporti e delle comunicazioni. In quanto maggiore attore, ENTUR assorbe anche una quota rilevante dei costi di coordinamento. Chiunque può presentare richieste di funzionalità; queste sono discusse nelle riunioni di coordinamento e sviluppate se qualcuno le finanzia. Il finanziamento avviene principalmente per singola funzionalità, da parte della o delle parti interessate. In sostanza ciascuna parte sostiene i propri costi. In Svizzera le prestazioni di supporto dovrebbero inoltre essere messe a concorso separatamente. + +=== Nuova collaborazione avviata dalla Confederazione: Swiss Trust Broker + +Il Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] è un software della Confederazione per eIAM, disponibile come open source. Lo sviluppo è svolto dalla Confederazione. Diversi Cantoni hanno deciso di impiegarlo direttamente come SaaS o con istanze proprie. Essendo disponibile sotto licenza AGPL, le estensioni realizzate vanno a loro volta a beneficio della Confederazione. Data la sua natura critica per la sicurezza, lo sviluppo per l'Amministrazione federale è svolto esclusivamente dalla Confederazione. Altre organizzazioni possono presentare requisiti, che saranno attuati se il team di progetto li ritiene adeguati. + +=== Nuova collaborazione avviata dai Cantoni: inosca + +Tramite inoscafootnote:[https://inosca.ch/] diversi Cantoni hanno costituito una comunità di sviluppo incentrata sulle autorizzazioni elettroniche, nata dal progetto eBau.footnote:[https://github.com/inosca/ebau] eBau comprende anche Caluma,footnote:[https://github.com/projectcaluma] un framework per l'elaborazione collaborativa — un esempio di componente estratto da una soluzione più ampia e sviluppato in un framework autonomo e ampiamente applicabile. Esso può essere utilizzato anche in altri progetti, anche laddove alcune parti siano soggette a condizioni di eccezione, consentendo così al maggior numero possibile di altri enti di beneficiare del codice. + +La community si riunisce almeno una volta al mese (in opzione due volte) per scambiarsi opinioni su temi tecnici e pianificare la roadmap comune. Tutti i partecipanti possono proporre temi. Se un tema è ritenuto rilevante per la community, i Cantoni interessati si annunciano e si organizzano in un gruppo di lavoro. I risultati sono restituiti continuamente alla community. inosca opera secondo un principio fondamentale: chi progetta, finanzia. Ossia, tutti i Cantoni che partecipano a un gruppo di lavoro si dividono i costi della nuova funzionalità. La funzionalità è messa a concorso e i costi sono ripartiti all'interno della community secondo una formula di ripartizione predefinita. Non appena una funzionalità è completata e introdotta, diventa immediatamente disponibile gratuitamente per tutti gli altri Cantoni. + +La community ha inoltre deciso di accantonare un modesto importo annuo fisso per coprire i costi amministrativi di gestione della community. Tale budget è attribuito ogni anno alle parti che assumono un ruolo organizzativo. + +=== SNOWPACK del WSL — contributi diretti degli sviluppatori + +SNOWPACKfootnote:[https://snow-models.gitlab-pages.wsl.ch/snowpack-web/] è un progetto open source sviluppato dal WSL per modellizzare la formazione del manto nevoso. Si tratta di un modello altamente specializzato e la community è stata di conseguenza integrata nella comunità specialistica esistente. Alcuni issue sono già stati individuati quali potenziali contributi. Il modello di lavoro è qui che ciascuna parte sostiene i propri costi e apporta funzionalità. Le direttive su stile di codifica e processo di rilascio sono parimenti documentate in tale contesto. + +=== Spunti per statuti associativi + +Gli statuti dovrebbero essere mantenuti il più semplici possibile. + +I seguenti statuti possono servire da spunto. + +* 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 + +#Ulteriori esempi di statuti saranno aggiunti non appena disponibili.# + +=== Esempi di supporto ed emolumenti + +* Emolumenti per prestazioni statistiche: https://www.fedlex.admin.ch/eli/cc/2003/326/it[https://www.fedlex.admin.ch/eli/cc/2003/326/it] +* Emolumenti dell'IFPDT: https://www.edoeb.admin.ch/edoeb/it/home/datenschutz/grundlagen/dsfa.html +* Prestazioni gratuite dell'IPI per corsi nel settore della proprietà intellettuale (non software, ma a titolo di esempio): https://www.ige.ch/it/prestazioni/ip-academy/informazioni-generali/prezzi + +Gli esempi saranno aggiunti non appena disponibili. +endif::[] + +ifeval::["{lang}" == "rm"] +NOTE: 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 {url-repo}/tree/main[README]. + +== L'essenzial en curt + +Sutvart èn inditgads ils puncts ils pli impurtants dal document. + +* La construcziun u il manaschi d'ina communitad OSS *n'è betg necessari* tenor l'art. 9 EMBAG. +* Ina communitad è relevanta, sch'ina gruppa d'utilisaders è sensada e sche *sinergias* cun auters utilisaders dal software duain vegnir creadas. +* Ina communitad na sa limitescha betg al software sez, mabain po era cumpigliar ils process en il conturn e la standardisaziun da datas. +* Per construir ina communitad sto adina vegnir prestà ina *lavur iniziala*. Quella cuntinuescha per ordinari. Savens è sensa che l'uffizi manant purtia era ils custs da coordinaziun. +* Communitads duain ademplir in *intent*. I dovra interessads e participants. +* Ina communitad po naschair e vegnir formalisada pli tard. +* La finamira da la communitad è d'augmentar il *profit per tuts*. Princip: «Ins survegn almain uschè bler enavos sco quai ch'ins metta en». +* La communitad duess esser *structurada uschè simplamain sco pussaivel*. +* En in emprim pass duess la communitad vegnir examinada curtamain cun agid da la glista da controlla link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Mo sch'ella è sensada duess ella vegnir sviluppada vinavant. +* La formalisaziun ha lieu via in *concept da communitad*. Uschè bler sco pussaivel duess vegnir surpiglià da funtaunas existentas. Princip: «Betg reinventar la roda». +* Sch'ina collavuraziun vegn aspirada, sto quai vegnir resguardà gia al cumenzament dal project, perquai che partenaris potenzials duessan vegnir integrads gia tar l'analisa da las pretensiuns. Era giuridicamain e dal puntg da vista dal dretg d'acquist sto quai vegnir planisà bain da l'entschatta. +* Las pussaivladads per entrar en ina collavuraziun existenta ston vegnir examinadas giuridicamain e dal puntg da vista dal dretg d'acquist. +* Per contribuziuns na sto vegnir construida nagina communitad. Sche il project pretenda quai, sto dentant vegnir suttascrit il *Contributor Licence Agreement (CLA)* correspundent u ston ils sviluppaders esser autorisads dal project da suttametter il software sut in Developer Certificate of Origin (DCO). + +== Introducziun + +Questa guida s'adressa a persunas spezialisadas en TIC ch'èn responsablas per ina applicaziun e che vulan la purscher sco open source u contribuir ad ina tala applicaziun. + +Quai sto vegnir organisà u formalmain u informalmain. + +Quest document furnescha infurmaziuns impurtantas per l'organisaziun e la construcziun d'ina communitadfootnote:[La communitad d'in project open source represchenta tipicamain ina piramida. + +Il fundament da questa piramida furman ils utilisaders dal software, en spezial quels engaschads che sa participeschan activamain a la communitad, per exempel en furma d'annunzias da sbagls e da giavischs da funcziuns u tras contribuziuns a glistas da mail. + +Directamain survart stattan en la piramida ils contributors. Quai èn parts da la communitad che proponan agnas contribuziuns da code. Els n'han tipicamain nagin access da scriver al repositori. Lur contribuziuns vegnan examinadas dals maintainers dal project e surpigliadas en il repositori suenter avair cuntanschì la qualitad tipica dal project. + +Al sum da la piramida stattan ils maintainers resp. committers d'in project. En quest rol porta ina sviluppadra u in sviluppader ina pli gronda responsabladad. Quai sa mussa per exempel en la pussaivladad d'acceptar contribuziuns. Quest dretg sa manifestescha savens via l'access da scriver al repositori. Sin quest nivel ha lieu la controlla dal software, da sia qualitad e da sia extensiun funcziunala. Tar projects pli cumplexs po quest nivel vegnir sutdividì vinavant. Uschia ha per exempel il kernel Linux sco enconuschent maintainers da subsistems sin plirs nivels, e finalmain surpiglia mo ina suletta persunalitad da svilup, Linus Torvalds, ils patchs en il repositori dal project. In ulteriur exempel èn projects da la Eclipse Foundation che disponan tipicamain d'in project lead cun dretgs supplementars en il rom dal process da svilup da la Eclipse Foundation, sco il lantschar dal process da release u la elecziun formala da committers u da project leads _[BITKOM2023]_.] sco er per il svilup avert directamain sco project open source. + +Sco segund element vegn manà, per promover la standardisaziun, en il rom da quest document in register da concepts da communitad existents. L'idea è che novas communitads possian vegnir construidas cun ina lavur minimala sin la basa da soluziuns cun success. + +Quest document na cuntegna naginas recumandaziuns directas per l'organisaziun da communitads per bibliotecas da software (parts da software che ademplan funcziuns parzialas, p.ex. la producziun da PDF). Normalmain na vegn elavurà per quellas nagin concept agen; empè da quai utiliseschan ellas il model simpel fixà en il model d'archivaziun dal repositori. + +Il document link:em002-1.pdf[Em002-01 Guida pratica per software open source en l'administraziun federala] cuntegna en il chapitel 4 furmas fundamentalas da collavuraziun, en il chapitel 8 ils differents models da support ed en l'agiunta infurmaziuns davart il cumportament dal martgà da l'open source. + +== Gener, finamira ed intent d'ina communitad + +Ina communitad po persequitar ils suandants intents: + +* Relevaziun da pretensiuns supplementaras +* Derasaziun da savida davart l'applicaziun +* Meglers resuns dals utilisaders +* Promoziun da translaziuns, documentaziun e scolaziuns +* Derasaziun da la standardisaziun +* En general ina interacziun meglierada cun ils utilisaders +* Ampliaziun da la collavuraziun ad ulteriurs participants +* Promoziun d'ulteriur software sin la basa dal software + +Tge gener da communitad ch'è il pli adattà per ina applicaziun dependa ferm dal conturn spezialisà, dals utilisaders potenzials e da la strategia da l'instituziun che publitgescha. I dat bleras vias differentas da construir communitads. Idealmain po in project adattà sa participar ad ina communitad existenta. Alternativamain po ina communitad vegnir construida cun in u plirs partenaris cun ils medems dretgs. + +Impurtant è ch'ina *structura da governanza* vegnia fixada e ch'ils puncts relevants vegnian documentads en in *concept da communitad* (vesair era _[BITKOM2023]_ chapitel 4.1 e _[IZqCab2023]_). + +Da resguardar è che communitads per software pon era vegnir cumbinadas cun talas per datas, standardisaziun e temas spezialisads. La communitad po lura cumpigliar process, standardisaziun, software e datas. Structuras existentas sco eOperations, ADS ed eCH pon era vegnir duvradas, nua che quai è sensa. + +In aspect impurtant d'ina communitad che funcziuna è ch'ils participants survegnian dapli che quai ch'els investeschan. + +I existan las suandantas constellaziuns: + +* *Communitad enturn in OSS da la Confederaziun*: La governanza ed il concept da communitad ston vegnir elavurads. En quest connex sto era vegnir reglà, co che terzas persunas pon prestar contribuziuns. +* *Nova collavuraziun per schliar in problem*: Ultra da la governanza e dal concept da communitad sto vegnir construida l'entira structura giuridica da la collavuraziun. +* *Entrada en ina collavuraziun*: L'administraziun federala sto examinar, sche e co ch'ella po far quai. +* *Contribuziun ad in project da terzas persunas*: Da examinar è la politica dal project per contribuziuns (Contributor Licence Agreement, Developer Certificate of Origin etc.). + +Dumondas dal dretg d'acquist vegnan tractadas en link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source]. + +=== Cas spezial: Nova collavuraziun per svilup, mantenziun e support da software open source + +Ils custs totals dal software open source sa reduceschan, sch'el vegn sviluppà e tgirà vinavant cuminaivlamain. Quai po capitar senza cunvegnas da cooperaziun formalas u cun betg dapli ch'ina planisaziun cuminaivla. + +Sch'ina collavuraziun pli formala vegn aspirada, duess vegnir fatga ina sclerida dal martgà per garantir che la collavuraziun saja la furma da cooperaziun la pli adattada. Collavuraziuns èn pli favuraivlas ch'in svilup singul da mintga partida (vesair link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]). + +Da resguardar è che tar collavuraziuns è sensa da lantschar la collavuraziun fitg baud en la metodica da project HERMESfootnote:[https://www.hermes.admin.ch/de/projektmanagement/methodenuebersicht.html] – concretamain durant las fasas analisa da la situaziun e pretensiuns. + +La collavuraziun è en Svizra fundamentalmain permessa tenor l'artitgel 4 EMBAG. + +Ultra da tuttas autras reflexiuns han collavuraziuns tant ina dimensiun giuridica sco era ina dimensiun dal dretg d'acquist. Actualmain vegn mintga cas giuditgà singularmain. Cun il temp sa vegnan a stabilir models standardisads. + +==== Dimensiun giuridica + +Commembranzas en associaziuns èn realisablas, vegnan dentant per ordinari giuditgadas en il cas singul: Tgi stat davos l'associaziun, e tge obligaziuns vegnan surpigliadas? Ina delegaziun da commembranzas ad eOperations u ad organisaziuns sumegliantas fiss pussaivla. + +Uschè ditg che nagin daner na flueschia e che naginas obligaziuns formalas na ston vegnir surpigliadas, è in Memorandum of Understanding sin il nivel da l'uffizi federal u da la Chanzlia federala pussaivel. + +Ina situaziun che pretenda la conclusiun d'in contract internaziunal duess vegnir evitada. + +I dat ultra da quai dus cas spezials,footnote:[https://www.eda.admin.ch/deza/de/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] en ils quals ina collavuraziun fiss gia cuverta: + +* Incumbensas attribuidas en il rom d'ina cunvegna internaziunala davart la realisaziun cuminaivla d'in project tras stadis signatars. +* Incumbensas attribuidas tenor las proceduras u cundiziuns spezialas d'ina organisaziun internaziunala. + +==== Dimensiun dal dretg d'acquist + +En blers cas ha la collavuraziun lieu tranter organisaziuns dal sectur public. En tals cas è l'acquist senza problems, uschenavant che la constellaziun è «entaifer il stadi» (vesair link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source]). + +Contracts cun interpresas estras senza sedia en Svizra èn pussaivels, uschenavant che las pretensiuns dal dretg d'acquist èn ademplidas. + +L'acquist da las atgnas resursas d'ina organisaziun ha lieu en il rom d'in process d'acquist usità u è gia terminà. + +=== Cas spezial: Entrada en ina collavuraziun existenta + +Quai pretenda tant ina basa legala sco era l'observaziun dal dretg d'acquist. + +Il pli simpel è la participaziun tenor il princip «mintga partida porta ses agens custs». Uschia sa laschan era cuvrir ils custs generals, uschenavant che vegnan duvradas u resursas internas u resursas externas messas a concurs correctamain. + +Ina participaziun directa a collavuraziuns estras è pli difficila. In simpel colliament via in Memorandum of Understanding è il pli simpel da cuntanscher. + +=== Cas spezial: Contribuziuns da code a projects OSS da terzas persunas + +Sche l'administraziun federala fa midadas al code d'in project OSS existent, è sensa da contribuir questas midadas directamain upstream al project original. Uschia na sto la mantenziun currenta betg pli vegnir prestada da l'administraziun federala. + +Tenor l'artitgel 9 EMBAG èn talas contribuziuns schizunt giavischadas. Dal puntg da vista dal dretg d'acquist è quai senza problems. + +Impurtant è che il possessur dals dretgs prestia la contribuziun. Quai munta che l'administraziun federala porta la responsabladad per quai per ses collaboraturs ed incumbensads. Concretamain sto in eventual Contributor Licence Agreement dal project vegnir suttascrit u sto in Developer Certificate of Origin vegnir agiuntà a la pull request. + +In **Developer Certificate of Origin**footnote:[https://developercertificate.org/] *(DCO)* per l'administraziun federala pudess suandar: + +[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. +____ + +La structura d'in Contributor Licence Agreement vegn descritta en link:em002-3.pdf[Em002-3 Guida da licenzas OSS], chapitel 8.9. + +La surdada effectiva dal code ha lieu tenor las directivas dal project respectiv. + +== Concept da communitad + +Il center d'ina communitad èn a la fin sia structura e sia governanza. Quellas vegnan tegnidas en scrit en in concept da communitad. + +Il concept da communitad da elavurar da la responsabladad dal project u da l'applicaziun (u dà en incumbensa a terzas persunas) duess suandar questa structura da chapitels. Tut tenor il gener da la communitad concreta n'èn betg tut ils sutchapitels necessaris. Idealmain renviescha ina gronda part dals chapitels a documents gia standardisads u utiliseschan process standard dals repositoris correspundents. Il concept da communitad sa lascha era applitgar a projects existents manads dad auters, en spezial sche la governanza effectiva n'è anc betg documentada en scrit. + +Cun la formalisaziun da la communitad vegnan tut ils participants manads ensemen e l'onboarding da novs participants vegn simplifitgà. + +Sboz da structura d'in concept da communitad: + +[arabic] +. Tabella da survista (num, repositori, adressa da contact, licenza, profunditad dal support, existent/nov) +. Finamiras +[loweralpha] +.. da l'applicaziun +.. da la communitad +. Organisaziun +[loweralpha] +.. Possessura dal code +.. Furma d'organisaziun / gremis +.. Dretgs da votar +.. Direcziun dal project +.. Dumondas d'acquist (sche applitgabel) +.. Ulteriurs aspects da governanza +. Roadmap e process da midada +. Process da svilup +[loweralpha] +.. Svilup avert +.. Dretgs da committer +.. Process da review +.. Repartiziun da las incumbensas e menziuns da nums +.. Backups +. Finanziaziun da la communitad +. Marketing +. Tractament da contribuziuns externas +[loweralpha] +.. Tractament da sbagls annunziads +.. Tractament da dumondas +.. Tractament da pull requests +.. Tractament da forks +.. CLA, DCO ed attribuziun da dretgs/proprietad intellectuala +. Manaschi da l'applicaziun + +Fundamentalmain è mintga autoritad federala responsabla per l'elavuraziun dals concepts da communitad. Il sectur TDT po publitgar models/exempels existents ed acceptescha exempels correspundents per la publicaziun. Sensa è ultra da quai ch'ils managers da communitad barattian infurmaziuns tranter els. + +Ina funtauna pussaivla per parts è era la documentaziun da la Eclipse Foundation,footnote:[Vesair https://www.eclipse.org/projects/handbook/#starting] cun quai ch'i sto vegnir fatg qua in tailoring adequat en il senn da «far mo il necessari». + +== Decisiuns fundamentalas tar la construcziun d'ina communitad + +Ils princips da la communitad – u la renunzia ad ella – vegnan fixads cun agid da link:em002-4-1-checklist-oss-community.pdf[Em002-4.1]. Las dumondas fundamentalas relevantas sa chattan en la chascha morfologica qua sutvart; mintga dimensiun vegn explitgada en ils chapitels suandants. + +[.landscape] +[cols="3,2,2,2,2,2",options="header"] +|=== +|Dimensiun |(a) |(b) |(c) |(d) |(e) + +|A -- Management dal product +|Confederaziun +|Organisaziun cuminaivla +|Organisaziun averta +|Terzas persunas +| + +|B -- Integraziun dals furniturs +|Incumbensà +|Partenari +|Independent +|Direcziun +| + +|C -- Repartiziun dals custs +|Confederaziun +|Mintgin per sasez +|Princip dal chaschunader +|Clav da repartiziun +|Contribuziun + +|D -- Support +|Relaschada minimala +|Support tras la Confederaziun +|Support tras terzas persunas +| +| + +|E -- Svilup +|Intern +|Terzas persunas +|Avert +| +| +|=== + +_Chascha morfologica communitad OSS._ + +I è recumandabel da *sa concentrar en emprima lingia sin il futur proxim* tar la concepziun da la communitad; sch'i n'existan per exempel anc nagins interessads concrets per l'applicaziun, è quai per ordinari pauc sensa da definir ina communitad cun ina societad simpla, ina atgna associaziun e process cumplexs per il svilup da la roadmap.footnote:[Cun ina associaziun (u ina fundaziun) vegn creada ina atgna persuna giuridica che sa premura per il software e per il product. Quai paja pir a partir d'ina tscherta impurtanza, cumplexitad e da l'existenza da plirs partenaris (cun ils medems dretgs). Ina roadmap serva a mussar al public pli vast ed als potenzials ulteriurs utilisaders dal software quai ch'è planisà.]footnote:[En spezial tar projects, als quals plirs acturs statals èn participads da l'entschatta, po era esser pussaivel da s'adressar a fundaziuns existentas e d'examinar, sche ils projects e la governanza pon vegnir manads sut lur tetg, analog a https://finos.org u https://osr.finos.org u https://www.eclipse.org/collaborations/ u https://iot.eclipse.org u https://outreach.eclipse.foundation/open-regulatory-compliance.] + +=== Management dal product + +Tut tenor il gener da l'applicaziun, sia impurtanza strategica e ses stadi en il ciclus da vita existan differentas variantas per represchentar il management dal product. Tar organisaziuns entaifer autoritads federalas pertutga quai adina ils responsabels da l'applicaziun. Per il concept da communitad èn spezialmain relevants la definiziun da la roadmap spezialisada e tecnologica sco er ils process da release. + +Pussaivladads: + +[loweralpha] +. *Organisaziuns entaifer la Confederaziun*: La Confederaziun vul mantegnair la controlla; ella definescha suletta la roadmap. +. *Organisaziun cuminaivla*: Ensemen cun auters utilisaders u furniturs. +. *Organisaziun averta*: Colliaziuns lasas, nagina roadmap activa. +. *Terzas persunas*: U il product exista gia u la lavur duai vegnir externalisada. + +==== Organisaziuns entaifer la Confederaziun: + +Sche l'applicaziun ha ina gronda impurtanza strategica u sche la Confederaziun dependa da pudair realisar spert sias midadas, po esser sensa da mantegnair la controlla. + +L'autoritad federala decida via la responsabladad da las pretensiuns suletta, tge ch'influescha cura en il software. + +Per auters utilisaders potenzials da l'applicaziun munta quai ch'els èn praticamain sfurzads dad utilisar ina atgna versiun (fork) da l'applicaziun. + +Uschiglio n'han els bunamain naginas pussaivladads da realisar adattaments ed extensiuns che pon esser impurtants per els. Quai na discurra betg cunter ina publicaziun sco open source: Ils utensilis per administrar il codefootnote:[p.ex. GitHub] porschan in vast sustegn per tals scenaris, ed adattaments e correcturas da sbagls pon vegnir surpigliads selectivamain en omaduas direcziuns. + +Ina partiziun dals custs è tipicamain difficila cun quest model. + +==== Cuminaivel (la Confederaziun ha la direcziun u partenaris cun ils medems dretgs) + +Decisiuns davart la roadmap e las prioritads duessan vegnir accordadas e prendidas cuminaivlamain cun ils auters commembers da la communitad. La Confederaziun sa participescha sco commembra da la communitad, ma n'è betg l'organisaziun mananta. + +Per che il prender decisiuns cuminaivel funcziunia, ston structuras e reglas vegnir fixadas anticipadamain. Uschia vegn era definì, co ch'ils custs per la realisaziun dals adattaments decidids cuminaivlamain vegnan repartids. + +Cun quest model nascha ina suletta versiun da l'applicaziun che vegn lura duvrada da tut ils commembers. Uschia èn ils custs totals cleramain pli bass en cumparegliaziun cun las autras variantas. La flexibilitad dals singuls utilisaders è dentant pli pitschna, ed els ston accordar anticipadamain lur giavischs d'adattaziun cun tut ils auters. Il prender decisiuns è pli plaun e pli custaivel. + +Quest model s'adatta il meglier per applicaziuns che duain vegnir sviluppadas vinavant cuminaivlamain cun autras organisaziuns cleramain definidas (p.ex. chantuns). + +==== Organisaziun averta + +Tar quest model èn ils process e las structuras mo definids lasamain. La Confederaziun mantegna formalmain la controlla, ma è averta per contribuziuns ed adattaments. + +I na vegn definida nagina u mo ina fitg gruassa roadmap; il consens vegn cuntanschì informalmain ed en discussiuns directamain sin la plattafurma da publicaziun. La communitad sezza è pli tgunsch dinamica; commembers pon esser fitg activs in tschert temp e sa retrair lura puspè. + +Quest model s'adatta era per applicaziuns pli pitschnas ch'èn gia en diever productiv e «finidas». Igl è ultra da quai per ordinari la megldra furma per applicaziuns u cumponentas orientadas tecnicamain che s'adresseschan potenzialmain ad ina gruppa da destinaziun pli vasta che na sa lascha betg determinar exactamain anticipadamain. + +==== Terzas persunas + +Tar quest model vegnan ils process e las structuras definids da terzas persunas e l'autoritad federala è commembra da la communitad, ma n'ha betg la direcziun. Quai po derivar dal fatg che il project è vegnì definì per exempel dad in auter stadi u chantun. U i po esser che la Confederaziun n'è betg interessada da manar vinavant sezza il program e transferescha questa incumbensa. + +=== Integraziun dals furniturs + +Per l'integraziun da furniturs existan fundamentalmain las suandantas pussaivladads: + +[loweralpha] +. *Furnitur sco incumbensà*: El vala a media vista fundamentalmain sco remplazzabel. Il furnitur duai sviluppar l'applicaziun sin la basa d'incumbensas dal management dal product (u da la communitad) favuraivlamain ed en auta qualitad, ma ha al pli ina influenza cussegliadra sin la roadmap e la prioritisaziun. +. *Partenaris a lunga vista cun cundecisiun*: Els duain pudair cundeterminar activamain il svilup. Quai rinforza lur rol ed els èn potenzialmain pronts d'investir sezs en l'applicaziun. Tipicamain derasan ils furniturs en quest model il software e tschertgan activamain novas clientas e novs clients. +. *Independent:* Ils furniturs fixeschan sezs, sche e co ch'els vulan lavurar al project. Quai po capitar per exempel, sche plirs furniturs vulan generar in agen martgà sin la basa dal software. Licenzas liberalas pon promover quai potenzialmain. Quai po era capitar, sche la strategia da la Confederaziun divergescha da quella dal furnitur. En quest scenari è probabel che il furnitur creescha in fork. +. *Direcziun*: Sche il furnitur surpiglia il management dal product, ha el la direcziun. Il svilup vegn lura determinà dad el. Da l'autra vart po quai era munta che l'administraziun federala sto surpigliar mo fitg pauca responsabladad. Tar ina relaschada minimala è pussaivel che il furnitur surpiglia quest rol independentamain. + +Sche il furnitur surpiglia in rol ferm, porta quai avantatgs per l'administraziun federala: Tras la commercialisaziun activa da l'applicaziun exista la schanza che la communitad creschia pli spert e pli ferm e che ils custs per commember sa reduceschian pli svelt. + +Sch'in model cun ina ferma cundecisiun dals furniturs vegn tschernì, sto vegnir fatg adatg che nagina divergenza da las prescripziuns dal dretg d'acquist na resultia da quai. Per ordinari è recumandabel d'integrar almain dus furniturs per betg crear ina dependenza memia ferma d'in sulet furnitur. Ultra da quai duess exister la pussaivladad che ulteriurs furniturs possian entrar en la communitad. + +=== Repartiziun dals custs + +Per la repartiziun dals custs per mantenziun, svilup vinavant e novas funcziuns stattan a disposiziun las suandantas opziuns: + +[loweralpha] +. *Organisaziuns entaifer la Confederaziun*: En spezial tar la construcziun d'ecosistems u sche l'autoritad federala vul mantegnair la controlla cumpletta, sto l'autoritad federala era purtar ils custs. +. *Mintgin per sasez*: Tuts pajan sezs las midadas ch'els giavischan. Sche necessari vegn decidì en il cas singul da pajar cuminaivlamain tschertas extensiuns. Custs repetitivs vegnan facturads tenor ina clav da repartiziun u tenor basegn. +. *Princip dal chaschunader*: Tgi che dovra effectivamain las prestaziuns u funcziuns, paja per quellas. I pon vegnir applitgadas tariffas oraras standardisadas. +. *Clav da repartiziun*: Ils custs vegnan repartids entaifer la communitad tenor ina clav definida. Mo extensiuns specificas divergeschan da quai. Quellas duessan vegnir pajadas directamain dals utilisaders pertutgads. Il divisur dals custs po esser per exempel la grondezza dal chantun pertutgà u il dumber dals utilisaders. Concernent la clav da repartiziun vesair era il chapitel «Repartiziun dals custs». +. *Contribuziun*: Sche l'autoritad federala integrescha mo persunal en in project existent. + +Fundamentalmain è la varianta b (partiziun dals custs) per ordinari mo lura sensada, sch'i exista era in management dal product cuminaivel sco en la varianta b (cuminaivel). Mo tgi che po discutar mit vegn ad esser pront da purtar ils custs consecutivs da las decisiuns. + +=== Support + +En il rom da la repartiziun dals custs e da la lavur sto vegnir scleri, tgi che presta tge support. Tenor l'art. 9 EMBAG è ina pura relaschada minimala pussaivla. Questa varianta na cuntanscha eventualmain betg l'effect giavischà e na construescha per sasezza nagina communitad, en la quala l'autoritad federala ha influenza. + +[loweralpha] +. *Relaschada minimala*: Nagin support (quai vul dir che la relaschada ha lieu per ordinari senza support organisà e senza participaziun da l'autoritad federala). +. *Support tras la Confederaziun*: L'autoritad federala (u ses purschider da prestaziuns) presta in support definì. +. *Support tras terzas persunas*: L'autoritad federala u la communitad definescha ina organisaziun da support. + +L'effect da cuntanscher, p.ex. sin l'ecosistem svizzer u ina finanziaziun iniziala d'ina communitad, po manar a quai che la Confederaziun prestia support. L'extensiun dal support sto natiralmain vegnir definida. Fundamentalmain po era vegnir incassada ina taxa. Pervia dals mecanissems da la Confederaziun èn purschiders da prestaziuns u furniturs pli tgunsch en cas da purscher in support commerzial. + +Uffizis dastgan purscher tenor l'EMBAG in support cun custs (eventualmain era via purschiders da prestaziuns e terzas persunas). Per quai ston els publitgar las taxas correspundentas sin lur pagina d'internet, perquai che la basa legala necessaria exista. Il colliament al sistem da pajament po vegnir discutà cun il DFF. + +Exempels per support e taxas sa chattan en l'agiunta G. + +=== Svilup + +Era la metodica fundamentala dal svilup po influenzar il gener da la communitad. + +[loweralpha] +. *Intern*: L'utilisaziun da repositoris interns munta che terzas persunas na pon betg collavurar directamain. Pli stricta che la separaziun è, pli gronda è la lavur d'integraziun che la Confederaziun sto prestar, sch'ella vul surpigliar extensiuns da terzas persunas. Era il process da relaschada è pli custaivel. +. *Terzas persunas*: U in furnitur lavura independentamain, u il product gia cumenzà resp. manà da terzas persunas vegn sviluppà tenor reglas definidas. +. *Avert*: Il svilup da software ha lieu directamain en in repositori public. La relaschada tenor l'EMBAG è uschia amplamain garantida. Las expensas resultan durant il svilup. En quest scenari po la collavuraziun cun terzas persunas era avair lieu pli baud (e pli simplamain). + +== Cuntegns detagliads per il concept da communitad + +Quest chapitel dat indicaziuns per redigier il concept da communitad sin la basa da las decisiuns fundamentalas prendidas (tenor il chapitel 5). + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +avert / Partenari / Confederaziun:: +Cuntegns u propostas, sche las decisiuns fundamentalas èn: + +Management dal product c) Organisaziun averta + +Integraziun dals furniturs: b) Furnitur sco partenari + +Repartiziun dals custs: b) Mintgin per sasez + +_Il text survart po vegnir copià en il model ed adattà._ + +Cuminaivel / - / Mintgin per sasez:: +Cuntegns u propostas, sche las decisiuns fundamentalas èn: + +Management dal product b) Svilup cuminaivel + +Integraziun dals furniturs: a) u b) (betg relevant) + +Repartiziun dals custs: c) Princip dal chaschunader u d) Partiziun dals custs + +Cuminaivel / - / Chaschunader:: +{empty} + +Il concept da communitad duess esser in document dinamic che po vegnir adattà en concertaziun cun la communitad. Il concept duess reflectar la situaziun actuala e proponer opziuns da svilup futuras. Sche pli tard entran ulteriurs commembers en la communitad, pon l'organisaziun ed ils process vegnir elavurads vinavant e pon vegnir introducids mecanissems pli cumplexs. Ils suandants sutchapitels suondan directamain la structura proponida dal concept da communitad (vesair chapitel 4). + +Sche il management dal product sa chatta tar terzas persunas, defineschan quellas ils concepts per la communitad. + +=== Datas centralas + +Las suandantas datas centralas duessan vegnir elavuradas e publitgadas per mintga communitad, per che ils potenzials interessads possian s'annunziar per il software e per la communitad: + +* Num dal software +* Repositori +* Possessura +* Unitad d'organisaziun/uffizi responsabel +* Adressa da contact +* Licenza duvrada +* Stgalim da support +* Project existent + +Questas indicaziuns sa laschan tuttas represchentar cun publiccode.yml.footnote:[https://yml.publiccode.tools/] + +=== Finamiras + +La finamira duess cuntegnair l'intent propri u la «visiun» da l'applicaziun. Questa visiun duess era vegnir inditgada en la datoteca *README.md* en il repositori (vesair link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[glista da controlla Em002-2.2 Analisa e preparaziun OSS]). + +Al medem temp duess era vegnir descrit, tge che la communitad aspira: + +* Tgi duai entrar? +* Tgi èn ils potenzials interessads? +* Duain novs commembers vegnir tschertgads activamain? +* Tge èn las finamiras principalas persequitadas cun la publicaziun sco open source? + +=== Organisaziun e governanza + +Fundamentalmain vegn aspirà tar svilups novs che la Confederaziun saja possessura dals dretgs principals sin il code da funtauna. + +Il gener da la direcziun dal project dependa da tge organisaziun ch'ha gì la direcziun tar la Confederaziun (SAFe, HERMES). Tar la furma d'organisaziun sto adina vegnir aspirà in minimal overhead (structura existenta empè d'ina nova; societad simpla empè d'ina associaziun). + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / - / Intern:: +Perquai che la Confederaziun mantegna la controlla directa, n'èn naginas structuras d'organisaziun supplementaras necessarias. + +Il post che publitgescha (p.ex. in uffizi federal) resta possessur e surpiglia tuttas incumbensas da coordinaziun. En quest cas po il chapitel «Organisaziun» vegnir tegnì fitg curt. + +Cuminaivel / - / Intern:: +Per quest scenari vegn per ordinari recumandada l'organisaziun sco *societad simpla*. + +Per che il svilup cuminaivel e l'accordanza da la roadmap e da las pretensiuns sajan pussaivels, è recumandabel da furmar dus gremis cun mintgamai ina persuna participanta per commember da la communitad: ++ +-- +* Gremi da direcziun: definescha la strategia e la prioritisaziun. +* Gruppa spezialisada: elavura pretensiuns e cuntegns concrets sin il nivel spezialisà. Tut tenor l'extensiun po era vegnir installada ina atgna gruppa spezialisada per mintga tema. +-- ++ +Possessur dal code è l'uffizi che l'ha publitgà. ++ +Sche las structuras daventan pli cumplexas u sche dapli che tschintg utilisaders resp. commembers supplementars èn participads, po valair la paina d'examinar, sche la communitad duess vegnir organisada meglier sco associaziun. Cumparegliar las explicaziuns en la varianta directamain sutvart. + +Cuminaivel / - / Terzas persunas:: +Recumandada vegn l'organisaziun sco *associaziun*. + +U i vegn fundada ina associaziun spezialmain per l'applicaziun, u l'applicaziun vegn transferida ad ina associaziun existenta. Ina associaziun vegn recumandada, perquai ch'uschiglio daventa la repartiziun dals custs cumplexa e perquai che las incumbensas da coordinaziun cumportan probablamain avunda lavur per engaschar ina gestiun a temp parzial per l'associaziun. ++ +Ils dretgs sin il code vegnan lura transferids a l'associaziun che surpiglia il management da la communitad e las ordinaziuns tar ils furniturs. + +Cuminaivel / Incumbensà / Intern:: +Recumandada vegn l'organisaziun sco *associaziun*. U i vegn fundada ina associaziun spezialmain per l'applicaziun, u l'applicaziun vegn transferida ad ina associaziun existenta. Ina associaziun vegn recumandada, perquai ch'uschiglio daventa la repartiziun dals custs cumplexa e perquai che las incumbensas da coordinaziun cumportan probablamain avunda lavur per engaschar ina gestiun a temp parzial per l'associaziun. ++ +Ils dretgs sin il code vegnan lura transferids a l'associaziun che surpiglia il management da la communitad e las ordinaziuns tar ils furniturs. + +Qua n'èn ils furniturs betg commembers da l'associaziun, mabain mo incumbensads. La gestiun na duess betg vegnir messa a disposiziun d'in furnitur. + +Cuminaivel / Incumbensà / Terzas persunas:: +Recumandada vegn l'organisaziun sco *associaziun*. U i vegn fundada ina associaziun spezialmain per l'applicaziun, u l'applicaziun vegn transferida ad ina associaziun existenta. Ina associaziun vegn recumandada, perquai ch'uschiglio daventa la repartiziun dals custs cumplexa e perquai che las incumbensas da coordinaziun cumportan probablamain avunda lavur per engaschar ina gestiun a temp parzial per l'associaziun. + +Ils dretgs sin il code vegnan lura transferids a l'associaziun che surpiglia il management da la communitad e las ordinaziuns tar ils furniturs. + +Ils furniturs èn commembers da l'associaziun; la gestiun po era vegnir messa a disposiziun d'in furnitur. + +avert / - / Intern:: +I n'exista *nagin basegn per ina descripziun detagliada d'ina organisaziun*, perquai ch'ella è concepida conscientamain avertamain. Impurtant è dentant da fixar, tgi che recepescha ed elavura las dumondas externas (responsabladad). Ultra da quai sto vegnir determinà, sche ed en tge dimensiun che persunas externas pon vegnir integradas: ++ +-- +* Nagina integraziun directa: Externs pon mo inoltrar propostas e contribuziuns (sco pull requests). +* Integraziun sco contributors: Externs che prestan savens e bunas contribuziuns vegnan integrads directamain. +* Surdada ad externs pussaivla: Sche suenter la publicaziun contribueschan externs dapli al svilup vinavant che l'organisaziun che publitgescha, po l'applicaziun era vegnir transferida ad els. +-- ++ +L'organisaziun che publitgescha resta possessura. Questa varianta correspunda a l'organisaziun da projects open source «classics»; vesair per ulteriuras infurmaziuns per exempel https://opensource.guide/leadership-and-governance/. + +avert / Incumbensà / Intern:: +I n'exista *nagin basegn per ina descripziun detagliada d'ina organisaziun*, perquai ch'ella è concepida conscientamain avertamain. Impurtant è dentant da fixar, tgi che recepescha ed elavura las dumondas externas (responsabladad). Ultra da quai sto vegnir determinà, sche ed en tge dimensiun che persunas externas pon vegnir integradas: ++ +-- +* Nagina integraziun directa: Externs pon mo inoltrar propostas e contribuziuns (sco pull requests). +* Integraziun sco contributors: Externs che prestan savens e bunas contribuziuns vegnan integrads directamain. +* Surdada ad externs pussaivla: Sche suenter la publicaziun contribueschan externs dapli al svilup vinavant che l'organisaziun che publitgescha, po l'applicaziun era vegnir transferida ad els. +-- ++ +L'organisaziun che publitgescha resta possessura. + +Questa varianta correspunda a l'organisaziun da projects open source «classics»; vesair per ulteriuras infurmaziuns per exempel https://opensource.guide/leadership-and-governance/. + +Il furnitur duess mo surpigliar incumbensas da coordinaziun puramain tecnicas (code review, giudicaziun). + +Terzas persunas / Partenari / Intern:: +I n'exista *nagin basegn per ina descripziun detagliada d'ina organisaziun*, perquai ch'ella è concepida conscientamain avertamain. Impurtant è dentant da fixar, tgi che recepescha ed elavura las dumondas externas (responsabladad). Ultra da quai sto vegnir determinà, sche ed en tge dimensiun che persunas externas pon vegnir integradas: ++ +-- +* Nagina integraziun directa: Externs pon mo inoltrar propostas e contribuziuns (sco pull requests). +* Integraziun sco contributors: Externs che prestan savens e bunas contribuziuns vegnan integrads directamain. +* Surdada ad externs pussaivla: Sche suenter la publicaziun contribueschan externs dapli al svilup vinavant che l'organisaziun che publitgescha, po l'applicaziun era vegnir transferida ad els. +-- ++ +L'organisaziun che publitgescha resta possessura. Questa varianta correspunda a l'organisaziun da projects open source «classics»; vesair per ulteriuras infurmaziuns per exempel https://opensource.guide/leadership-and-governance/. + +Concernent la governanza pon era vegnir consultads _[BITKOM2023]_ chapitel 4.1, _[IZqCab2023]_ u https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md#governance-models. + +Exempels da statuts d'associaziun sa chattan en l'agiunta E. + +Indicaziun: Perquai che la relaschada sto esser garantida tenor l'art. 9 EMBAG, sto l'administraziun federala garantir che la publicaziun na possia betg vegnir revocada spontanamain (vesair la «directiva Open Source en l'acquist – cumpra da software tenor l'art. 9 EMBAG» _[BBL-WL]_, cifra V.2). + +=== Roadmap e process da midada + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / Incumbensà / -:: +L'autoritad federala definescha la roadmap e decida, tge midadas che vegnan realisadas. Per quai vegnan duvrads ils process standard da l'uffizi XY. + +Confederaziun / Partenari / -:: +L'autoritad federala definescha la roadmap en collavuraziun cun la firma XY. Ella decida, tge midadas che vegnan realisadas. Per quai vegnan duvrads ils process standard da l'uffizi XY. + +Cuminaivel / - / Intern:: +Il process per sviluppar la roadmap e per approvar midadas sto vegnir fixà dals commembers da la societad u da l'associaziun. Tut tenor la structura dals commembers (dumber, relaziun da grondezza etc.) pon auters process esser adequats. + +Ils process ston dentant cuntegnair mesiras per schliar conflicts e per chattar maioritads. + +Cuminaivel / - / Terzas persunas:: +Il process per sviluppar la roadmap e per approvar midadas sto vegnir fixà dals commembers da la societad u da l'associaziun. Tut tenor la structura dals commembers (dumber, relaziun da grondezza etc.) pon auters process esser adequats. ++ +Ils process ston dentant cuntegnair mesiras per schliar conflicts e per chattar maioritads. ++ +Cun il supplement ch'era ina clav da repartiziun dals custs sto vegnir fixada. Da reflectar è ultra da quai, co ch'i sto vegnir tractà cun la partiziun dals custs per adattaments che n'èn betg giavischads dals commembers pertutgads. En spezial en associaziuns cun commembers da grondezza differenta pon naschair situaziuns, en las qualas in grond commember (p.ex. l'autoritad federala) porta ina part considerabla dals custs per ina extensiun senza trair in profit da quai. + +avert / - / -:: +_Exempel, betg adattà per tuttas situaziuns_ + +I n'exista nagin basegn da crear ina roadmap; l'applicaziun adempla actualmain ils basegns. ++ +Davart midadas vegn decidì en ina discussiun averta ed in consens vegn aspirà. La decisiun finala sa chatta tar la possessura dal code (Confederaziun svizra). + +=== Process da svilup + +Sche il svilup avert vegn applitgà, sto quai vegnir definì qua. Impurtants èn la repartiziun da las incumbensas e la menziun da posts centrals en il concept da communitad. Er, co che la segirezza dals cuntegns dal repositori vegn garantida. + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / - / -:: +Ils dretgs da committer (access da scriver al code) sa chattan tar las persunas/ils posts/ils furniturs tschernids da la Confederaziun. Suenter la scadenza dal contract vegnan ils dretgs respectivs retratgs. ++ +Ils purschiders da prestaziuns ed ils furniturs èn responsabels per exequir il process tecnic da code review per contribuziuns externas ch'èn vegnidas acceptadas dal puntg da vista spezialisà da la Confederaziun. Els èn responsabels per la qualitad tecnica. Ils furniturs vegnan recumpensads per questa lavur da la Confederaziun. + +Cuminaivel / Incumbensà / Intern:: +Fundamentalmain survegnan tut ils posts incumbensads d'in commember da la communitad l'access da scriver al code (dretgs da committer). Suenter la scadenza dal contract vegnan ils dretgs respectivs retratgs. ++ +Sche code midà pertutga secturs centrals da l'applicaziun, ston tuttas midadas vegnir examinadas d'in post incumbensà spezialmain per quai da la communitad. Quest post è responsabel per la qualitad tecnica da l'applicaziun. El è ultra da quai cumpetent per examinar midadas ch'èn vegnidas acceptadas dal puntg da vista spezialisà da la communitad. + +Cuminaivel / Partenari / Terzas persunas:: +Ils dretgs da committer (access da scriver al code) sa chattan tar ils commembers da la communitad. Questas persunas s'organiseschan sezzas e portan cuminaivlamain la responsabladad per la qualitad dal code. ++ +Sch'in commember da la communitad incumbensescha in furnitur extern per in adattament u ina extensiun, vegn l'adattament examinà d'in commember da la communitad. El vegn recumpensà per quai dal mandant. ++ +Midadas al center da l'applicaziun ston vegnir examinadas d'in segund commember da la communitad. ++ +Ils furniturs ch'èn commembers da la communitad èn ultra da quai responsabels per examinar contribuziuns externas e nov code tecnic ch'è vegnì acceptà dal puntg da vista spezialisà da l'associaziun. + +avert / - / -:: +Al cumenzament sa chattan ils dretgs da committer tar ils sviluppaders u tar lur patruns. Dretgs da committer vegnan concedids a tut ils sviluppaders che contribueschan activamain al project durant plirs mais e che mussan ina cumpetenza sociala adequata. ++ +Ils singuls sviluppaders mantegnan fundamentalmain lur dretgs da committer, era sch'els midan il patrun u sche la Confederaziun tscherna in auter furnitur. Dretgs da committer extinguan mo, sch'els vegnan dads davent voluntarmain u sche la maioritad dals auters committers decida lur retratga. ++ +La Confederaziun ha il dretg da numnar singuls sviluppaders da las interpresas ch'ella incumbensescha sco committers. Ella n'ha betg il dretg da retrair ad insatgi ils dretgs da committer senza motiv. ++ +Code reviews vegnan fatgas dad almain ina persuna ch'è activa sco committer. Ils committers s'organiseschan sezs. ++ +La Confederaziun s'oblighescha da recumpensar la lavur da review, uschenavant che quai è finanzialmain pussaivel per ella. + +=== Partiziun dals custs e furniturs + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / Incumbensà / Intern:: +Ils furniturs vegnan tschernids periodicamain via concurs OMC u ina procedura libra (tut tenor l'extensiun da las prestaziuns da mantenziun). + +Confederaziun / Partenari / -:: +*Impurtant:* Examinar anticipadamain, sche quai è permess dal puntg da vista dal dretg d'acquist en il cas concret. ++ +Nus vegnin a cumplettar la documentaziun davart quest punct. La Confederaziun tscherna il furnitur XXX sco partenari strategic ed aspira ina collavuraziun a lunga vista. + +Cuminaivel / Incumbensà / Intern:: +Mintga commember da la communitad incumbensescha independentamain in u plirs furniturs da software cun la realisaziun dals adattaments e da las extensiuns ch'el dovra. Per adattaments giavischads da plirs commembers vegn la partiziun dals custs convegnida en il cas singul. Il commember cun la pli gronda part dals custs è responsabel per la tscherna e l'incumbensa dal furnitur. (Reglamentaziuns per la mantenziun dal software) + +Cuminaivel / Incumbensà / Terzas persunas:: +L'associaziun tscherna ils furniturs da software periodicamain centralmain via concurs OMC u proceduras libras (tut tenor l'extensiun da las prestaziuns da mantenziun). Ils custs vegnan attribuids als commembers tenor ina clav: (da fixar: tenor populaziun, utilisaders etc.) + +Cuminaivel / Partenari / Intern:: +Mintga commember da la communitad incumbensescha independentamain in u plirs furniturs da software cun la realisaziun dals adattaments e da las extensiuns ch'el dovra. Per adattaments giavischads da plirs commembers vegn la partiziun dals custs convegnida en il cas singul. Il commember cun la pli gronda part dals custs è responsabel per la tscherna e l'incumbensa dal furnitur. ++ +_(Reglamentaziuns per la mantenziun dal software)_ Sche necessari cumplettà tras ina contribuziun dals furniturs participads. Exempel: _Mintga interpresa da svilup da software ch'è commembra da la communitad s'oblighescha dad investir mintg'onn almain XY dis da lavur sin agens custs en il svilup vinavant, l'actualisaziun tecnologica u il marketing da l'applicaziun._ + +Cuminaivel / Partenari / Terzas persunas:: +L'associaziun tscherna ils furniturs da software periodicamain centralmain via concurs OMC u proceduras libras (tut tenor l'extensiun da las prestaziuns da mantenziun). Ils custs vegnan attribuids als commembers tenor ina clav: (da fixar: tenor populaziun, utilisaders etc.) Sche necessari cumplettà tras il supplement: _Mintga interpresa da svilup da software ch'è commembra da la communitad s'oblighescha dad investir mintg'onn almain XY dis da lavur sin agens custs en il svilup vinavant, l'actualisaziun tecnologica u il marketing da l'applicaziun._ + +Terzas persunas / Incumbensà / -:: +Ils furniturs vegnan tschernids periodicamain via concurs OMC u ina procedura libra (tut tenor l'extensiun da las prestaziuns da mantenziun). Cun il supplement: _Las meglieraziuns contribuidas da furniturs potenzials e las activitads en la communitad vegnan resguardadas sco factur en la valitaziun._ ++ +Midadas giavischadas dad externs na vegnan betg finanziadas da la Confederaziun, mabain ston vegnir dadas en incumbensa e pajadas dad els sezs. + +Terzas persunas / Partenari / -:: +Ils furniturs vegnan tschernids periodicamain via concurs OMC u ina procedura libra (tut tenor l'extensiun da las prestaziuns da mantenziun). Cun il supplement: _Las meglieraziuns contribuidas da furniturs potenzials e las activitads en la communitad vegnan resguardadas sco factur en la valitaziun. Midadas giavischadas dad externs na vegnan betg finanziadas da la Confederaziun, mabain ston vegnir dadas en incumbensa e pajadas dad els sezs._ + +=== Marketing + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / Incumbensà / -:: +La Confederaziun na commercialisescha betg activamain l'applicaziun, ma la publitgescha sin plattafurmas da software open source. La publicaziun da l'applicaziun vegn communitgada en gremis spezialisads. Sch'i s'annunzian interessads, examinain nus, sch'ina communitad cuminaivla duai vegnir construida u sch'i duai vegnir lavurà vinavant cun lur versiun dal software. + +Cuminaivel / Partenari / -:: +Supplementarmain: + +Furniturs dastgan commercialisar l'applicaziun e tschertgar ulteriurs interessads. La Confederaziun dastga vegnir numnada sco referenza. Nus prendain conscientamain en cumpra ch'i possian naschair versiuns divergentas dal software. + +Cuminaivel / Incumbensà / Intern:: +L'applicaziun vegn commercialisada dals commembers u da l'associaziun. + +Cuminaivel / Partenari / Intern:: +L'applicaziun vegn commercialisada dals furniturs. + +Cuminaivel / - / Terzas persunas:: +L'applicaziun vegn commercialisada da l'associaziun, da la societad simpla e da lur commembers. + +avert / - / -:: +L'applicaziun dastga vegnir commercialisada da furniturs, u i po vegnir renunzià ad in marketing explicit. ++ +Alternativa senza marketing explicit: La Confederaziun na commercialisescha betg activamain l'applicaziun, ma la publitgescha sin plattafurmas da software open source. En gremis spezialisads rendain nus attent ch'avain publitgà l'applicaziun e ch'ina collavuraziun è bainvegnida. Nus mussain il software als interessads ed empruvain da ls integrar en noss process per concepir la roadmap. + +=== Tractament da contribuziuns externas + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Confederaziun / Incumbensà / -:: +Contribuziuns e dumondas externas ston era vegnir elavuradas, sche la Confederaziun resta la suletta ch'ha da decider davart il software (ordaifer tar ina relaschada minimala, nua ch'in fork è inevitabel). Nus proponin il suandant proceder: ++ +*Tractament da sbagls annunziads* + +Nus empruvain da reproducir sbagls annunziads da persunas externas e dumandain sche necessari. Sche la reproducziun reussescha, dat la Confederaziun en incumbensa la reparaziun dals sbagls. Sche il sbagl na sa lascha betg verifitgar u sche la lavur per il reparar è dischproporziunadamain gronda, ans stgisain nus tar la persuna che ha annunzià e dumandain, sch'ella pudess inoltrar ina pull request per il reparar. ++ +*Tractament da dumondas* + +Nus respundain mintga dumonda entrada. Sch'ina dumonda na sa lascha betg sclerir cun ina lavur adequata e sch'in ulteriur investiment da temp para inefficient, ans stgisain nus cun inditgar las resursas limitadas ed offrin da metter la persuna che dumonda en contact cun in furnitur per ina cussegliaziun vinavant. ++ +*Tractament da pull requests* + +Nus examinain mintga pull request accuratamain. Per evitar ina lavur nunnecessaria da vart da la persuna che contribuescha, rendain nus immediatamain attent, sche insatge cuntradi a nossa roadmap u sch'igl è dubitus, sche nus acceptain la contribuziun. La Confederaziun decida independentamain e tenor criteris spezialisads, tge contribuziuns ch'ella accepta. Correcturas da sbagls ch'han surpassà il process da review vegnan adina acceptadas. ++ +*Tractament da forks* + +Nus sustegnain forks da nossa applicaziun. Tgi ch'introducescha l'applicaziun duess crear in agen fork. Nus examinain ils forks resultants almain ina giada l'onn e surpigliain extensiuns bunas ed adattadas. + +Cuminaivel / - / -:: +Extern designescha contribuziuns da ordaifer la communitad definida (commembers da l'associaziun). Divergenzas da survart: + +*Tractament da forks* + +Nus vulain impedir forks (da lunga durada) da l'applicaziun. Interessads duessan empè da quai entrar directamain en la communitad. Entaifer la communitad empruvain nus da garantir che tut ils commembers utiliseschian la versiun principala. + +Avert / - / -:: +La construcziun d'ina communitad che funcziuna e d'ina cultura averta è impurtanta per nus. ++ +*Tractament da sbagls annunziads* + +Nus empruvain da reproducir e da reparar sbagls annunziads. Nus premettain la collavuraziun activa da las persunas che annunzian. Sche pussaivel duessan ellas crear directamain ina pull request cun ina correctura dal sbagl. ++ +*Tractament da dumondas* + +Nus tractain mintga dumonda entaifer maximalmain in'emna. Dumondas da contribuents activs vegnan tractadas cun prioritad e profundamain. Nus empruvain d'integrar auters commembers en l'elavuraziun da dumondas. ++ +*Tractament da pull requests* + +Nus vulain survegnir uschè bleras pull requests da buna qualitad sco pussaivel. Nus integrain tut ils contribuents activs en las reviews ed en la giudicaziun tecnica e spezialisada da pull requests. Tar contribuziuns contestadas empruvain nus da vegnir ad ina decisiun via ina votaziun informala. ++ +*Tractament da forks* + +Nus empruvain da render forks nunnecessaris tras in management da communitad activ ed avert. Sch'i nascha tuttina forks, ils examinain nus activamain ed empruvain da surpigliar las extensiuns e las meglieraziuns sviluppadas là. En tals cas pretendain nus activamain pull requests. + +En general è da tegnair en scrit che contribuziuns pon ir dal sustegn dad auters utilisaders fin a la surpigliada da la responsabladad per parts entiras d'in project (vesair _[BITKOM2023]_ chapitel 4.2). + +=== Manaschi da l'applicaziun + +_Management dal product / Furnitur sco / Svilup -- Proposta_ + +Cuminaivel / - / -:: +In manaschi central po vegnir purschì opziunalmain supplementarmain da l'associaziun centrala, en il senn da Software as a Service (SaaS). I sto vegnir examinà, sche quai è giavischà. + +- / Partenari / -:: +I sto vegnir fixà, sche il furnitur duai era manar il software. + +- / Direcziun / -:: +I sto vegnir tegnì en scrit che il furnitur è responsabel per il manaschi. + +Stgalims da support e contacts da support duessan vegnir fixads era en quest chapitel. + +== Infurmaziuns impurtantas per managers da communitad + +=== I dovra temp + +La construcziun da communitads è insatge che duess vegnir planisà a lunga vista. Persistenza e cuntinuitad èn duas caracteristicas impurtantas per ina communitad cun success. + +=== Ulteriuras suggestiuns per la construcziun d'ina communitad + +Ulteriuras suggestiuns per in bun management da communitad sa chattan sut https://opensource.guide/code-of-conduct/ e https://opensource.guide/best-practices/. + +=== Communicaziun + +La publicaziun da software e da documentaziun avra a l'administraziun federala in nov chanal da communicaziun. Sche quai na capita betg cun quità e professiunalmain, po la reputaziun publica da la Confederaziun patir. + +Communitads OSS en l'administraziun federala sa chattan concernent la communicaziun en in champ da tensiun: Da l'ina vart valan las *prescripziuns generalas per la communicaziun*, da l'autra vart duai la communitad pussibilitar ina *collavuraziun formala ed informala simpla* sur cunfins organisatorics, preferiblamain senza controllas da qualitad e relaschadas formalas. + +L'utilisaziun da repositoris publics ed eventualmain d'issue-trackings e wikis publics munta che expressiuns da singuls collaboraturs dal project èn visiblas senza filter per il public. Quai pretenda dals collaboraturs dal project in'apparientscha professiunala e l'observaziun da standards da qualitad per publicaziuns en tals conturns. + +En projects OSS vegn quai normalmain reglà via il *Code of Conduct*. Il codex da cumportament da l'administraziun federalafootnote:[https://www.epa.admin.ch/dam/epa/de/dokumente/aktuell/medienservice/120_verhaltenskodex_d.pdf.download.pdf/120_verhaltenskodex_d.pdf] è tegnì fitg en general, ma il princip central è applitgabel qua: «Ils collaboraturs ademplan lur incumbensas en moda responsabla, integra e loyala. Era en la vita privata fan els adatg da betg donnegiar la reputaziun, la credibilitad e l'image da la Confederaziun.» + +=== Svilup avert + +Sche il svilup da software è planisà da l'entschatta en in repositori avert, ha la relaschada lieu automaticamain. Las glistas da controlla relevantas tenor las instrucziuns link:em002-2.pdf[Em002-2] ston vegnir emplenidas al cumenzament, ed ils process da svilup dal purschider da prestaziuns resp. dal furnitur ston permetter quai. L'avantatg è che la communitad po vegnir construida da l'entschatta. Pliras organisaziuns pon ultra da quai collavurar al svilup. + +Repositoris serrads èn ina furma intermediara, ma vegnan duvrads per auters partenaris en ina collavuraziun. + +=== Administraziun dals utilisaders + +Il project (u l'organisaziun purtanta) fixescha, sche ils sviluppaders ed auters collaboraturs dal project lavuran al project sut agen num u anonimamain. Sche las persunas na lavuran betg anonimamain e sch'ellas disponan gia da logins sin las plattafurmas, è quai il pli simpel d'utilisar quels (saja quai professiunal u privat). + +La plattafurma duess fundamentalmain permetter l'integraziun da terzas persunas, perquai che uschiglio na pon nagins sviluppaders ordaifer la Confederaziun collavurar. + +Cun bandunar il project ston ils dretgs correspundents sin il project vegnir stizzads. Per quai è il management dal product responsabel. + +=== Reuniun da communitads + +Nua ch'igl è pussaivel duess il dumber da communitads vegnir tegnì pitschen. Quai munta: + +* Sch'i exista gia ina communitad, en la quala è previsa ina structura sumeglianta per problems sumeglionts cun las medemas persunas, duess vegnir duvrada ina suletta communitad. +* Plirs projects che èn en connex e che s'adresseschan a la medema gruppa da destinaziun pon vegnir reunids en ina communitad. +* I na duessan betg vegnir creadas nunnecessariamain structuras da communitad fundamentalmain autras, nua ch'i existan gia talas. + +=== Tractament da contribuziuns da terzas persunas + +La contribuziun da software ad auters projects vegn tractada en il chapitel 3.3. Ils medems princips valan al revers. + +Impurtants èn ils suandants puncts: + +* I sto vegnir duvrà in Contributor Licence Agreement adattà per garantir che il code da funtauna appartegnia suenter a la Confederaziun (vesair era link:em002-3.pdf[Em002-3 Guida da licenzas OSS], chapitel davart ils Contributor Licence Agreements). Quel sto vegnir suttascrit dal possessur da la contribuziun. +* Confermaziuns ston vegnir archivadas. +* Contribuziuns ston vegnir examinadas avant l'integraziun en la basa dal code. +* Endataziuns duessan vegnir respundidas a temp (issues, requests, pull requests) e vegnir tractadas uschè constructivamain sco pussaivel. +* Tut ils chanals e las reglamentaziuns da governanza duessan vegnir inditgads en il concept da communitad, sin la pagina d'internet ed en il repositori. + +=== Annunzias relevantas per la segirezza + +Ultra da las annunzias da sbagls usitadas sto vegnir previs – nua che il gener dal project pretenda quai – che debilitads relevantas per la segirezza possian vegnir annunziadas confidenzialmain, sco quai ch'è per exempel il cas tar in program da bug bounty. + +Sco exempel pon servir ils documents da trustbroker.swiss: + +* https://github.com/trustbroker-swiss/trustbroker.swiss/blob/main/Security-and-Vulnerability-Disclosure.md + +=== Evitar forks + +Schebain che forks èn en il mund open source natirals, è la reintegraziun da code da funtauna, funcziuns etc. da forks tut auter che simpla. I po valair la paina da s'adressar a las persunas u organisaziuns che considereschan in fork e d'empruvar da las mantegnair en il project principal. Ina cumpensaziun tranter interess concurrents è savens necessaria en tals cas. + +=== Repartiziun dals custs + +Igl è sensa da convegnir clavs da repartiziun generalas tranter ils partenaris principals. Quellas pon vegnir adattadas mintga paucs onns u en cas d'ina midada fundamentala da la situaziun. Per ina lavur efficienta al software duessan ils gronds partenaris surpigliar tendenzialmain parts in pau pli grondas che quai ch'els stuessan propriamain (sche necessari era la coordinaziun totala). L'organisaziun duai lavurar e betg sa dispitar davart las finanzas. Sche la collavuraziun s'extenda sur plirs projects (per exempel las soluziuns da branscha en il sectur da las viafiers da scartament normal), duess vegnir duvrada per tut ils projects ina clav da repartiziun unitara. Dal puntg da vista da las autoritads federalas è quai ina meglieraziun, sche ils custs na ston betg vegnir purtads sulets. + +Criteris pussaivels per clavs da repartiziun: + +* Stimaziun da la repartiziun dal profit (p.ex. tranter autoritad federala ed in furnitur che spera ulteriura clientella) +* Dumber dals abitants/utilisaders (p.ex. tranter uffizis, vischnancas, citads) +* Forza finanziala (p.ex. chantuns) +* Product intern brut (p.ex. tranter chantuns) +* Tgi che vul dapli controlla + +Per evitar discussiuns na duess la clav da repartiziun betg vegnir colliada simplamain cun il budget annual. Ina clausula en il senn dal princip dal chaschunader po pussibilitar per singuls partenaris adattaziuns pli spertas, sch'els èn pronts da pajar supplementarmain. + +La clav da repartiziun duess era valair per ils custs generals, la mantenziun/il support ed in minimum da svilup vinavant. Questas parts duessan sche pussaivel vegnir schliadas a lunga vista. + +Da resguardar è che tar la finanziaziun da terzas persunas vulan questas partidas tipicamain dapli cundecisiun. Il management da la communitad sto esser preparà per quai. + +=== Prestaziuns cumplementaras tenor l'art. 9 al. 5 e 6 EMBAG + +Las autoritads federalas pon (sezzas, via purschiders da prestaziuns u furniturs) prestar prestaziuns cumplementaras, en spezial per l'integraziun, la mantenziun, la garanzia da la segirezza da las infurmaziuns ed il support. + +La restricziun è ch'ellas duain servir a las incumbensas da las autoritads e pudair vegnir prestadas cun ina lavur proporziunada. + +Da quai resulta che l'autoritad federala na po betg esser l'interpresa da svilup per terzas persunas. Ella repara sbagls, po tractar aspects relevants per la segirezza, po prestar in pau support ed agid d'integraziun (tut activitads che servan a la construcziun d'ina communitad). Novs svilups e funcziuns supplementaras per terzas persunas duessan s'orientar en emprima lingia a l'intent da lavur normal da l'autoritad. Natiralmain po esser che la messa a disposiziun dal software saja part da l'incumbensa; en quest cas pon svilups avair lieu da tut temp. I vegn ultra da quai tegnì en scrit che il svilup da software n'è betg l'incumbensa centrala da l'autoritad federala. + +Quai munta: Sche funcziuns vegnan sviluppadas en il fund exclusivamain per terzas persunas, ston ellas vegnir integradas en partenadi u via il furnitur. + +Per evitar problems dal dretg d'acquist sto vegnir fatg adatg tar l'acquist da software e da prestaziuns che funcziuns possian vegnir messas a disposiziun a terzas persunas (eventualmain mo a terzas persunas statalas) tras furniturs. + +La fixaziun da taxas è gia vegnida tangida en il chapitel «Support». L'EMBAG è gia la basa legala per talas taxas. Quellas ston vegnir communitgadas sin la pagina d'internet da la respectiva autoritad federala. Exempels èn inditgads en l'agiunta G. + +L'art. 9 al. 6 tegna en scrit ch'i na duai normalmain betg vegnir fatg concurrenza a l'economia privata. Quai munta che las taxas na duessan betg vegnir fixadas memia bass e duessan almain cuvrir ils custs. En cas da dubi èn tariffas oraras pli tgunsch da fixar memia aut che memia bass. + +En general vegn recumandà da lavurar cun ina fin trais differentas tariffas oraras standard. + +Sch'in departament federal vul fixar excepziuns a l'al. 6, na dastga quai betg far concurrenza a l'economia privata. Sut tschertas circumstanzas è quai il pli simpel da fixar las taxas e da las augmentar, sch'i nascha resistenza dad interpresas privatas che pon effectivamain purscher la prestaziun. + +=== Suveranitad digitala + +Uschè ditg che la Confederaziun n'ha nagin agen repositori, vegn recumandà per garantir la suveranitad digitala da far regularmain copias da repositoris publics. + +Da resguardar è che betg mo il code da funtauna, mabain era ulteriuras infurmaziuns sco issue-tracking, wiki, configuraziuns etc. vegnan copiadas. + +Ultra da quai sto vegnir schliada l'administraziun dals utilisaders per garantir la controlla dal code da funtauna publitgà. La finamira surordinada è da garantir in svilup independent da la respectiva plattafurma e da pussibilitar a la communitad ina midada.footnote:[Vesair era https://www.bfh.ch/de/aktuell/news/2024/neue-studie-digitale-souveraenitaet/] + +== Agiunta + +=== Midadas envers la versiun precedenta + +* Chapitel 1 «L'essenzial en curt» agiuntà +* Intent da la communitad agiuntà en il chapitel 3 +* Chapitels 3.1 fin 3.3 davart la collavuraziun agiuntads +* Nov chapitel 7.7 Tractament da contribuziuns da terzas persunas +* Tegnì en scrit che furniturs na duessan betg publitgar cumplettamain independentamain (tenor _[BBL-WL]_, V.2) +* Publicode.yml menziunà +* Accordanza cun il nov link:em002-7.pdf[Em002-7] +* Ulteriuras midadas e meglieraziuns redacziunalas + +=== Referenzas + +Vesair _Em002 Directivas strategicas per software open source en l'administraziun federala_. + +=== Abreviaziuns + +Vesair link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] ed link:em002-6.pdf[Em002-6 FAQ davart OSS]. + +=== Exempels da concepts da communitad existents + +En il senn d'ina collecziun da best practices suondan sutvart concepts da communitad e documents cumparegliabels ch'èn gia vegnids elavurads. Quai n'èn betg necessariamain mo concepts d'autoritads federalas, mabain era dad autras organisaziuns. + +* GERES Community (http://geres-community.ch) + +Classificaziun: + +* Management dal product a) Svilup cuminaivel +* Furnitur pli tgunsch a) Incumbensà +* Repartiziun dals custs: b) Partiziun dals custs + +Indicaziun: Il register communal GERES n'è betg open source, ma blers aspects da l'organisaziun pon era esser relevants per applicaziuns open source. Documents: Statuts (publics) ed urden da gestiun (sin dumonda). + +* https://www.igovportal.ch[iGov Portal] + +#Quest chapitel cuntegna actualmain concepts dal chantun Berna e vegn cumplettà, uschespert che exempels da la Confederaziun èn disponibels.# + +=== Exempels da collavuraziuns + +Ils suandants exempels mussan, co che collavuraziuns èn vegnidas structuradas. + +=== Collavuraziun: ZenDiS en Germania + +ZenDiSfootnote:[https://www.zendis.de/en[Pagina d'internet ZenDiS: Co-creating Digital Sovereignty]] è ina organisaziun che ha per finamira da reducir la dependenza en l'administraziun publica (primarmain en Germania) tras la promoziun da software open source. + +[mermaid,align="center",alt="Finamiras ed access per rinforzar la suveranitad digitala (ZenDiS)"] +.... +block-beta + columns 12 + H1["Finamiras"]:12 + G1["I. Pussaivladad da midar furnitur"]:4 G2["II. Abilitad da concepir"]:4 G3["III. Influenza sin ils furniturs"]:4 + H2["Access da schliaziun"]:12 + B1["1. Analisa e direcziun
prevesentas da las dependenzas"]:3 B3["3. Modularitad independenta
dal furnitur, standards (averts)
ed interfatschas informaticas"]:3 B5["5. Cundefiniziun cooperativa
da soluziuns informaticas"]:3 B7["7. Prescripziuns giuridicas"]:3 + B2["2. Acquist u svilup da
soluziuns informaticas
alternativas (p.ex. OSS)"]:3 B4["4. Construcziun da cumpetenzas
digitalas e da savida
spezialisada"]:3 B6["6. Chapientscha e
proceder cuminaivels"]:3 B8["8. Direcziun politica"]:3 + classDef highlight fill:#dae8fc,stroke:#000000,color:#000000 + class B2 highlight +.... + +Illustraziun 1: Finamiras ed access per rinforzar la suveranitad digitala (ZenDiS) + +ZenDiS collavura per quai cun partenaris strategics. + +Ina collavuraziun tranter l'administraziun federala e ZenDiS na duess perquai bunamain betg esser pussaivla senza restricziuns, ed ina coordinaziun na fiss betg lianta. Quai po sa midar cun il temp. + +Concretamain stuess l'administraziun federala construir ina atgna organisaziun per la Svizra e sa coordinar informalmain cun ZenDiS. Quai pudess eventualmain capitar via eOperations, cun quai che eOperations vegn pir activa, sch'in basegn concret vegn annunzià ed in budget vegn mess a disposiziun. Ina motivaziun per ina tala organisaziun parallela sa laschass chattar en il context dal cybergovern u da l'EMBAG. + +Indicaziun: ZenDiS suttastat al dretg d'acquist da l'UE resp. da la Germania. I existan differenzas considerablas envers la Svizra. ZenDiS na sa lascha perquai betg reproducir in a in en Svizra, ed ina collavuraziun cun ZenDiS n'è betg simpla. + +=== Collavuraziun: Open Trip Planner (OTP) + +Open Trip Plannerfootnote:[https://www.opentripplanner.org/[OpenTripPlanner]] è ina applicaziun open source per la planisaziun da viadis. Ella è organisada sco project da la Software Freedom Conservancy a New York. Singuls sviluppaders èn engaschads tar interpresas da traffic e furniturs. Remartgabel è ch'in actur dal maun public – concretamain ENTURfootnote:[https://entur.no/] – ha surpiglià in dals rols manants. ENTUR sviluppa primarmain per l'agen basegn, ma ha era in focus da cooperaziun, en spezial per ils pajais nordics. ENTUR è organisada sco interpresa en la proprietad dal Ministeri norvegais dal traffic e da la communicaziun. Sco il pli grond actur surpiglia ENTUR era ina part considerabla dals custs da coordinaziun. Mintgin po inoltrar giavischs da funcziuns; quels vegnan discutads en sesidas da coordinaziun e sviluppads, sche insatgi ils finanziescha. La finanziaziun ha lieu primarmain per funcziun tras la resp. las partidas interessadas. En il fund porta mintga partida ses agens custs. Prestaziuns da support stuessan en Svizra ultra da quai vegnir messas a concurs separadamain. + +=== Nova collavuraziun lantschada da la Confederaziun: Swiss Trust Broker + +Il Trust Brokerfootnote:[https://github.com/trustbroker-swiss/trustbroker.swiss[GitHub - trustbroker-swiss/trustbroker.swiss: Documentation of the trustbroker.swiss service]] è in software da la Confederaziun per eIAM ch'è disponibel sco open source. Il svilup ha lieu tras la Confederaziun. Plirs chantuns han decidì d'il duvrar u directamain sco SaaS u cun agnas instanzas. Perquai ch'el è disponibel sut la licenza AGPL, van extensiuns fatgas puspè a bun a la Confederaziun. Pervia da sia natira critica per la segirezza ha il svilup per l'administraziun federala lieu exclusivamain tras la Confederaziun. Autras organisaziuns pon inoltrar pretensiuns che vegnan realisadas, sche il team dal project las considerescha sco adequatas. + +=== Nova collavuraziun lantschada dals chantuns: inosca + +Via inoscafootnote:[https://inosca.ch/] han plirs chantuns construì ina communitad da svilup per permissiuns electronicas ch'ha sia origin en il project eBau.footnote:[https://github.com/inosca/ebau] eBau cumpiglia era Caluma,footnote:[https://github.com/projectcaluma] in framework per l'elavuraziun cuminaivla – in exempel per ina cumponenta ch'è vegnida extratga d'ina soluziun pli vasta e sviluppada ad in framework independent ed amplamain applitgabel. Quel po era vegnir duvrà en auters projects, era sche singulas parts suttastattan a cundiziuns d'excepziun, uschia che pussaivlamain blers auters posts pon profitar dal code. + +La communitad sa scuntra almain ina giada al mais (opziunalmain duas giadas) per barattar temas tecnics e per planisar la roadmap cuminaivla. Tut ils participants pon inducir temas. Sch'in tema vegn considerà sco relevant per la communitad, s'annunzian ils chantuns interessads e s'organiseschan en ina gruppa da lavur. Ils resultats fluescha cuntinuadamain enavos a la communitad. inosca lavura tenor in princip fundamental: Tgi che concepescha, finanziescha. Quai vul dir che tut ils chantuns participads ad ina gruppa da lavur sa dividan ils custs da la nova funcziun. La funcziun vegn messa a concurs ed ils custs vegnan repartids en la communitad tenor ina formula da partiziun dals custs predefinida. Uschespert ch'ina funcziun è terminada ed introducida, stat ella immediatamain a disposiziun libramain a tut ils auters chantuns. + +La communitad ha supplementarmain decidì da metter da vart ina modesta summa annuala fixa per ils custs administrativs dal manaschi da la communitad. Quest budget vegn attribuì mintg'onn a las partidas che surpiglian in rol organisatoric. + +=== SNOWPACK da la WSL – contribuziuns directas da sviluppaders + +SNOWPACKfootnote:[https://snow-models.gitlab-pages.wsl.ch/snowpack-web/] è in project open source sviluppà da la WSL per modellar la furmaziun da la cuverta da naiv. I sa tracta d'in model fitg spezialisà, e la communitad è vegnida integrada correspundentamain en la communitad spezialisada existenta. Singuls issues èn gia vegnids notads sco contribuziuns pussaivlas. Il model da lavur è qua che mintga partida porta ses agens custs e contribuescha funcziuns. Directivas davart il coding style ed il process da release èn documentadas en quest connex era. + +=== Suggestiuns per statuts d'associaziun + +Ils statuts duessan vegnir tegnids uschè simpels sco pussaivel. + +Ils suandants statuts pon servir sco suggestiun. + +* 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 + +#Ulteriurs exempels da statuts vegnan agiuntads, uschespert ch'els èn disponibels.# + +=== Exempels per support e taxas + +* Taxas per prestaziuns statisticas: https://www.fedlex.admin.ch/eli/cc/2003/326/de[https://www.fedlex.admin.ch/eli/cc/2003/326/de] +* Taxas dal PFPD: https://www.edoeb.admin.ch/edoeb/de/home/datenschutz/grundlagen/dsfa.html +* Prestaziuns gratuitas da l'IPI per curs en il sectur da la proprietad intellectuala (betg software, ma sco exempel): https://www.ige.ch/de/dienstleistungen/ip-academy/allgemeine-informationen/preise + +Exempels vegnan agiuntads, uschespert ch'els èn disponibels. +endif::[] diff --git a/docs/em002-5.adoc b/docs/em002-5.adoc new file mode 100644 index 0000000..dfc7f47 --- /dev/null +++ b/docs/em002-5.adoc @@ -0,0 +1,1676 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-5 EMOTA and OSS Factsheet +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-5 Merkblatt EMBAG und OSS +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-5 Aide-mémoire LMETA et OSS +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-5 Promemoria LMeCA e OSS +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-5 Fegl d'infurmaziun EMBAG ed OSS +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +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 {url-repo}/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/four-cs/four-cs-cases.en.svg[The four Cs divided into case a) and case b),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.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.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.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.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.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.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.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. + +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 + +include::partials/document-map.en.adoc[] + +For procurement, the FOBL additionally provides the General Terms and Conditions, the tender registration, the tender kick-off slides and the procurement project templates. + +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 {url-repo}/tree/main/docs[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. + +// The only block title on a table in the document set, and it stays. 4d1056c +// avoided them because auto-numbering would have renumbered the tables whose +// numbers Em002-7's prose cites; Em002-5 has one table, no hand-written number +// and no prose in any of the five languages that cites one. The block title is +// a real -- the table's accessible name -- and open-govpress supplies +// both the number and the localised word for "Table", so unlike the captions in +// Em002-2, Em002-3 and Em002-7 there is nothing here to keep in step by hand. +.OSS tools and resources by target group +[.landscape] +[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 for the Em002 documents, CCPP and FOBL for the last three rows +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 {url-repo}/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/four-cs/four-cs-cases.de.svg[Die 4 C unterteilt in Fall a) und Fall b),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 + +include::partials/document-map.de.adoc[] + +Für die Beschaffung stellt das BBL zusätzlich die Allgemeinen Geschäftsbedingungen, die Ausschreibungsregistrierung, die Kick-off-Folien für Ausschreibungen und die Vorlagen für Beschaffungsprojekte bereit. + +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 {url-repo}/tree/main/docs[auf Englisch 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. + +// Siehe den englischen Block für die Begründung dieses Blocktitels. +.OSS-Hilfsmittel nach Zielgruppe +[.landscape] +[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 +| +| + +|Wegleitung 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 für die Em002-Dokumente, KBB und BBL für die letzten drei Zeilen +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 {url-repo}/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/four-cs/four-cs-cases.fr.svg[Les 4 C répartis en cas a) et cas b),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 + +include::partials/document-map.fr.adoc[] + +Pour les achats, l'OFCL met en outre à disposition les conditions générales, l'enregistrement des appels d'offres, les diapositives de lancement des appels d'offres et les modèles de projets d'acquisition. + +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 {url-repo}/tree/main/docs[publiés en anglais 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. + +// Voir le bloc anglais pour la justification de ce titre de bloc. +.Outils et ressources OSS par groupe cible +[.landscape] +[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 pour les documents Em002, CCMP et OFCL pour les trois dernières lignes +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 {url-repo}/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/four-cs/four-cs-cases.it.svg[Le 4 C suddivise in caso a) e caso b),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 + +include::partials/document-map.it.adoc[] + +Per gli acquisti l'UFCL mette inoltre a disposizione le condizioni generali, la registrazione dei bandi di concorso, le diapositive di avvio dei bandi di concorso e i modelli per i progetti d'acquisto. + +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 {url-repo}/tree/main/docs[pubblicati in inglese 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. + +// Cfr. il blocco inglese per la motivazione di questo titolo di blocco. +.Strumenti e risorse OSS per gruppo target +[.landscape] +[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/TDT per i documenti Em002, CCAP e UFCL per le ultime tre righe +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 {url-repo}/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/four-cs/four-cs-cases.rm.svg[Ils 4 C repartids en cas a) e cas b),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 dat 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 + +include::partials/document-map.rm.adoc[] + +Per l'acquist metta l'UFCL ultra da quai a disposiziun las cundiziuns generalas, la registraziun da las publicaziuns da concurrenza, ils fegls da partenza per publicaziuns da concurrenza ed ils models per projects d'acquist. + +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 {url-repo}/tree/main/docs[publitgads en englais 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. + +// Vesair il bloc englais per la motivaziun da quest titel da bloc. +.Meds e resursas OSS tenor gruppa da destinaziun +[.landscape] +[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/TDT per ils documents Em002, CCA ed UFCL per las ultimas trais lingias +endif::[] diff --git a/docs/em002-6.adoc b/docs/em002-6.adoc new file mode 100644 index 0000000..0a83510 --- /dev/null +++ b/docs/em002-6.adoc @@ -0,0 +1,2650 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-6 FAQ on OSS and Art. 9 EMOTA +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-6 FAQ zu OSS und Art. 9 EMBAG +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-6 FAQ sur les OSS et l'art. 9 LMETA +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-6 FAQ su OSS e art. 9 LMeCA +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-6 FAQ davart OSS e l'art. 9 EMBAG +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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 {url-repo}/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 + +== Terms and definitions + +=== Open source software + +[qanda.unnumbered] +What is meant by open source software?:: +This is defined in link:em002-1.pdf[Em002-1 Practical Guidelines for Open Source Software in the Federal Administration] + +=== Software and licences + +[qanda.unnumbered] +What is meant by software?:: +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]. + +What is meant by licences?:: +Here we are referring to software licences. Further information can be found in link:em002-3.pdf[Em002-3 OSS Licensing Guidelines]. + +Should custom-built AI models be considered as software and thus subject to the legal requirements of Art. 9 EMOTA? What about the training data?:: +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:[https://cnai.swiss/[CNAI] and also Art. 10 EMOTA] + +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?:: +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 + +[qanda.unnumbered] +What is the legal basis for the publication of OSS?:: +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. ++ +More information can be found in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. + +What is meant by security-relevant reasons?:: +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]. + +What are third-party rights?:: +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]. + +Is it possible for exceptions to be time-limited?:: +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. + +What legal consequences should be considered in case of a violation of Art. 9 EMOTA?:: +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. +-- + +Can liability claims be asserted in the case of damage caused by OSS?:: +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). + +From which date must software be published?:: +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.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. ++ +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). + +Is it possible to demand retroactive publication for software developed before 1 January 2024?:: +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:[https://en.wikipedia.org/wiki/Version_control[Version control -- Wikipedia]]), a release of the entire software should be considered. Otherwise, the source code of the new functionalities would at least have to be released. + +On what basis would a third party have to request the release of source code?:: +A third party would have to submit a request under the FoIA to the competent authority. + +== Roles and responsibilities + +=== Role of the Federal Chancellery + +[qanda.unnumbered] +Who makes the basic implementation tools available?:: +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. + +Is the Federal Chancellery responsible for granting exemptions (e.g. for security-relevant reasons)?:: +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 + +[qanda.unnumbered] +Who is responsible for operational implementation of OSS releases?:: +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 + +[qanda.unnumbered] +How should a federal authority's in-house developments be published?:: +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 + +[qanda.unnumbered] +Under what conditions may personal data, such as that of developers, be published as part of OSS?:: +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 + +[qanda.unnumbered] +Where can I find the documentation for OSS procurement?:: +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'. ++ +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 + +[qanda.unnumbered] +Is there central guidance on how OSS is handled in the Federal Administration?:: +Yes, the DTI Sector 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 + +How should a federal authority's in-house developments that were created in collaborations be published? How should existing rights be handled?:: +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.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]. + +Do changes have to be published?:: +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.pdf[Em002-2 Instructions for Publishing Open Source Software] provides information on the process. + +When is the publication 'sufficient' according to EMOTA?:: +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.pdf[Em002-2 Instructions for Publishing Open Source Software]. + +In the future, will service procurers be telling service providers how the software should be published and how to ensure quality?:: +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 + +[qanda.unnumbered] +Under which open source licence should software be developed?:: +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.pdf[Em002-3 OSS Licensing Guidelines]. + +=== Quality criteria for OSS + +[qanda.unnumbered] +Does open source software have to meet certain quality criteria?:: +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]. + +What are the requirements planned for quality gates?:: +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. + +How are development guidelines regulated?:: +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]. + +Does OSS have to be published in a specific location?:: +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 and corresponding internal rules in place. ++ +Further recommendations are given in link:em002-2.pdf[Em002-2 Instructions for Publishing Open Source Software]. + +=== Documentation + +[qanda.unnumbered] +What are the documentation requirements for OSS publication?:: +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 + +[qanda.unnumbered] +Can and should an administrative unit contribute code to an 'upstream' project and does it thereby meet the requirements of Art. 9 EMOTA?:: +* 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.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.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.pdf[Em002-7] Section 9 will help. + +=== Support + +[qanda.unnumbered] +Is the federal authority required to provide support for published software?:: +No, but it can if it so wishes. ++ +According to Art. 9 paras 5 and 6 EMOTA, it may also charge fees for support. + +How should an authority proceed if it wishes to charge for support?:: +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 + +=== Guidance + +[qanda.unnumbered] +Is there any central guidance on working with open source software in the Federal Administration?:: +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.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 + +[qanda.unnumbered] +Do the tools also include checklists for releasing open source software?:: +Yes, the DTI Sector of the Federal Chancellery provides the following checklists for free use: ++ +-- +* 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. +-- + +=== Security matters + +[qanda.unnumbered] +Are there special OSS security risks?:: +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 + +Does publishing source code increase the risk of a malicious copy of an app? (e.g. a phishing or fake app):: +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). +-- + +Does it make sense for requisitioners within the Federal Administration to join forces to procure OSS?:: +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 + +[qanda.unnumbered] +Is the Confederation allowed to use licences in the original language English?:: +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 + +[qanda.unnumbered] +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):: +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 + +[qanda.unnumbered] +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?:: +Yes, this is unproblematic. See the information provided in the guidelines link:em002-3.pdf[Em002-3]. + +=== Licence provisions + +[qanda.unnumbered] +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.):: +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 + +[qanda.unnumbered] +How do the Freedom of Information Act (FoIA) and EMOTA relate to each other?:: +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 + +[qanda.unnumbered] +Can developers' personal data be published without further consideration? What data protection aspects need to be considered?:: +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 (as 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 + +[qanda.unnumbered] +Does it matter whether OSS is used commercially or non-commercially?:: +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]). + +Are there restrictions on which organisations are permitted for communities?:: +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.pdf[Em002-4 OSS Community Guidelines], Section 3.1 + +How does ISO Standard 5230 relate to the guidelines?:: +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.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.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.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.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.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* + +* 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 + +[horizontal] +include::partials/abbreviations.en.adoc[tags=abbr-em002-6] + +=== 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]. + +include::partials/glossary.en.adoc[tags=gloss-em002-6] +endif::[] + +ifeval::["{lang}" == "de"] +NOTE: Dieses Dokument ist ein Entwurf, der laufend weiterentwickelt wird, und Teil der Hilfsmittel, welche die Bundesverwaltung bei der Veröffentlichung von Open-Source-Code unterstützen. Weitere Informationen finden Sie im {url-repo}/tree/main[README]. + +== Ausgangslage und Zweck + +=== Ausgangslage und Zweck der FAQ + +Im Zusammenhang mit den Hilfsmitteln zur Veröffentlichung von OSS tauchen regelmässig Fragen auf. Die nachfolgende Zusammenstellung beantwortet die häufigsten Fragen und soll das Verständnis für einzelne Themen und Aspekte verbessern. + +=== Aufbau und Gliederung + +Die FAQ sind nach Themen gegliedert: + +[start=2] +. Begriffe und Definitionen +. Rollen und Verantwortlichkeiten +. Prozess +. Hilfsmittel +. Rechtliche Fragen +. Allgemeines + +== Begriffe und Definitionen + +=== Open-Source-Software + +[qanda.unnumbered] +Was wird unter Open-Source-Software verstanden?:: +Dies wird in link:em002-1.pdf[Em002-1 Praxisleitfaden Open-Source-Software in der Bundesverwaltung] definiert. + +=== Software und Lizenzen + +[qanda.unnumbered] +Was wird unter Software verstanden?:: +Dies wird in link:em002-1.pdf[Em002-1 Praxisleitfaden Open-Source-Software in der Bundesverwaltung] definiert. Zu den Lizenzen siehe link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen]. + +Was wird unter Lizenzen verstanden?:: +Gemeint sind hier Softwarelizenzen. Weitere Informationen finden sich in link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen]. + +Sind selbst entwickelte KI-Modelle als Software zu betrachten und damit den rechtlichen Anforderungen von Art. 9 EMBAG unterstellt? Wie verhält es sich mit den Trainingsdaten?:: +Open Source bezeichnet Software, deren Quellcode unter minimalen Bedingungen frei zugänglich und veränderbar ist. Dazu zählen auch selbst trainierte KI-Modelle (einschliesslich Algorithmus, Trainingsverfahren und Code). ++ +KI-Modelle werden auf der Grundlage von Daten trainiert, allenfalls von Open (Government) Data. Als Open Data werden Datensätze bezeichnet, die frei genutzt, geteilt und weiterverarbeitet werden dürfen. KI-Modelle, deren Trainingsdaten auf Open (Government) Data beruhen, gelten als Software im Sinne des EMBAG und müssen daher ebenfalls veröffentlicht werden. ++ +Enthalten die Trainingsdaten jedoch (besonders schützenswerte) Personendaten oder klassifizierte Informationen, kann aus sicherheitsrelevanten Gründen auf eine Veröffentlichung verzichtet werden. Bei der Freigabe eines KI-Modells als Open Source müssen die Trainingsdaten nicht zwingend mitveröffentlicht werden; dies entspricht jedoch dem Open-Source-Gedanken und wird von der Open-Source-Community ausdrücklich empfohlen. Für weitere Informationen zur KI verweisen wir auf das Kompetenznetzwerk Künstliche Intelligenz (CNAI).footnote:[https://cnai.swiss/[CNAI] sowie Art. 10 EMBAG] + +Müssen Werkzeuge mit generativen KI-Fähigkeiten (z. B. GitHub Copilot) vor dem Einsatz geprüft werden, damit keine Immaterialgüterrechte Dritter oder des Bundes verletzt werden?:: +Inhalte, die ein KI-Modell selbst erzeugt, sind nicht urheberrechtlich geschützt, weil ihnen keine schöpferische Tätigkeit zugrunde liegt. KI-generierte Inhalte, die auf urheberrechtlich geschützte Werke Dritter zurückgreifen, können jedoch die Rechte dieser Dritten verletzen. Da KI-Ausgaben zudem notorisch unzuverlässig sind, sollten sie nur nach sorgfältiger Einzelfallprüfung verwendet werden. ++ +Ausserdem können sich die Betreiber von KI-Systemen in ihren Nutzungsbedingungen vorbehalten, Eingaben zum Training des Systems zu verwenden. Das kann wiederum dazu führen, dass Eingaben oder Teile davon Dritten angezeigt werden. Wo dies nicht ausgeschlossen werden kann, ist sicherzustellen, dass Eingaben keine Rechte des Bundes oder Dritter verletzen. ++ +Es wird empfohlen, den Einsatz von KI-Werkzeugen einzeln zu prüfen und freizugeben. Nicht freigegebene Werkzeuge dürfen nicht eingesetzt werden; Mitarbeitende können jedoch die Freigabe eines Werkzeugs beantragen. Oft ist es sinnvoll, solche Fragen vertraglich mit dem Anbieter zu regeln; manche Anbieter bieten auch besondere Abonnemente an, mit denen sie Rechte Dritter wahren, z. B. DeepL. + +=== Rechtsgrundlage im EMBAG + +[qanda.unnumbered] +Was ist die Rechtsgrundlage für die Veröffentlichung von OSS?:: +Nach Art. 9 EMBAGfootnote:[SR 172.019] müssen Bundesbehörden der zentralen Bundesverwaltung den Quellcode von Software offenlegen, die sie entwickeln oder entwickeln lassen. Jede Person darf die Software gebührenfrei nutzen, weiterentwickeln oder verändern. ++ +Von der Veröffentlichung des Quellcodes kann nur wegen Rechten Dritter oder aus sicherheitsrelevanten Gründen abgesehen werden. ++ +Weitere Informationen finden sich in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software]. + +Was sind sicherheitsrelevante Gründe?:: +Die nach Art. 9 EMBAG zulässigen sicherheitsrelevanten Gründe und der Umgang damit werden in Kapitel 3.2 von link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] definiert. + +Was sind Rechte Dritter?:: +Rechte Dritter nach Art. 9 EMBAG und der Umgang damit werden in Kapitel 3.3 von link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] definiert. + +Können Ausnahmen zeitlich befristet sein?:: +Die Gründe für eine Ausnahme nach Art. 9 EMBAG (Rechte Dritter und sicherheitsrelevante Gründe) können mit der Zeit wegfallen. ++ +Ist dies der Fall, muss der Quellcode der Software freigegeben werden. + +Welche rechtlichen Folgen sind bei einer Verletzung von Art. 9 EMBAG zu beachten?:: +Es gibt zwei Arten von Verletzungen: ++ +-- +. Rechte Dritter werden verletzt. +. Eine Bundesbehörde verweigert die Veröffentlichung von OSS (z. B. unter Berufung auf nicht stichhaltige sicherheitsrelevante Gründe). + +Antwort zu 1: + +Regelmässig liegt eine Vertragsverletzung vor, und es können Schadenersatzansprüche nach Obligationenrecht geltend gemacht werden. + +Antwort zu 2: + +Dies hat keine unmittelbare Folge. Will eine Drittperson den Quellcode einer Bundesbehörde nutzen können, muss sie bei der zuständigen Behörde ein Gesuch nach dem Öffentlichkeitsgesetz (BGÖ; SR 152.3) stellen. + +Besteht ein grosses Interesse, kann es sinnvoll sein, eine Veröffentlichung im beidseitigen Interesse zu prüfen. Eine Pflicht zur rückwirkenden Veröffentlichung besteht nicht, freiwillig ist dies aber möglich. +-- + +Können bei einem durch OSS verursachten Schaden Haftungsansprüche geltend gemacht werden?:: +Grundsätzlich sollte die Haftung in den Verträgen ausgeschlossen werden. Für grobe Fahrlässigkeit oder schuldhaftes Verhalten kann die Haftung jedoch nicht ausgeschlossen werden. In solchen Fällen könnte eine Bundesbehörde nach dem Verantwortlichkeitsgesetz (VG; SR 170.32) haftbar werden. + +Ab welchem Datum muss Software veröffentlicht werden?:: +Nach Art. 9 Abs. 1 EMBAG muss Software veröffentlicht werden, die nach dem 1. Januar 2024 entwickelt wird oder wurde. ++ +Bei Software, die vor dem 1. Januar 2024 entwickelt wurde, sollte eine Freigabe geprüft werden, wenn grössere Änderungen anstehen. ++ +Besteht ein erhebliches Interesse von Dritten, kann bestehende Software auch freiwillig freigegeben werden (allenfalls mit Kostenbeteiligung). In diesem Fall sollte auch eine Community (siehe link:em002-4.pdf[Em002-4]) geprüft werden. ++ +Bei kleineren Skripten ist eine Veröffentlichung meist nicht die beste Option. Es kann Repositorien für Werkzeuge geben, die dann gemeinsam den Freigabeprozess durchlaufen. ++ +Für Verwaltungseinheiten der dezentralen Bundesverwaltung, die dem EMBAG unterstehen, gilt die Veröffentlichungspflicht seit dem 1. Mai 2025. Ausnahmen von der Veröffentlichungspflicht bestehen für ohne Bundesmittel entwickelte Software und für Forschungssoftware (Art. 3 Abs. 1 VEMBAG). + +Kann für Software, die vor dem 1. Januar 2024 entwickelt wurde, eine rückwirkende Veröffentlichung verlangt werden?:: +Das Gesetz sieht keine rückwirkende Veröffentlichung vor. ++ +Zudem können Verträge, die vor dem 1. Januar 2024 abgeschlossen wurden, Rechte Dritter enthalten, die einer Veröffentlichung entgegenstehen. ++ +Steht eine neue Hauptversion an (Major nach Semantic Versioningfootnote:[https://de.wikipedia.org/wiki/Versionsverwaltung[Versionsverwaltung -- Wikipedia]]), sollte eine Freigabe der gesamten Software geprüft werden. Andernfalls müsste zumindest der Quellcode der neuen Funktionalitäten freigegeben werden. + +Auf welcher Grundlage müsste eine Drittperson die Freigabe von Quellcode verlangen?:: +Eine Drittperson müsste bei der zuständigen Behörde ein Gesuch nach dem BGÖ stellen. + +== Rollen und Verantwortlichkeiten + +=== Rolle der Bundeskanzlei + +[qanda.unnumbered] +Wer stellt die grundlegenden Hilfsmittel zur Umsetzung bereit?:: +Der Bereich DTI der Bundeskanzlei stellt den Bundesbehörden Hilfsmittel als Dokumentensammlung zu Em002 zur Verfügung. Dazu gehören die strategischen Vorgaben und weitere Praxisleitfäden einschliesslich FAQ sowie Checklisten zur Sicherstellung einer rechtskonformen Umsetzung. ++ +Die OSS-Hilfsmittel werden durch DTI aktualisiert. + +Ist die Bundeskanzlei für die Bewilligung von Ausnahmen (z. B. aus sicherheitsrelevanten Gründen) zuständig?:: +Es gibt keine zentrale Stelle, die über Ausnahmen von der Veröffentlichungspflicht nach Art. 9 EMBAG entscheidet. Jede Bundesbehörde ist für ihre rechtskonforme Umsetzung selbst verantwortlich. ++ +Die Departemente können Regelungen erlassen. ++ +Die Checkliste zur generellen Ausnahme nach Art. 9 EMBAG [BBL-CL] des BBL sollte ausgefüllt werden. + +=== Rolle der Verwaltungseinheiten + +[qanda.unnumbered] +Wer ist für die operative Umsetzung von OSS-Freigaben zuständig?:: +Jede Bundesbehörde (z. B. Amt, Verwaltungseinheit), die Software entwickelt oder entwickeln lässt, ist eigenverantwortlich für den gesamten Veröffentlichungsprozess zuständig. ++ +Die Departemente können in ihrem Zuständigkeitsbereich verbindliche Regelungen und Kontrollmechanismen festlegen, z. B. um Reputationsschäden zu vermeiden. ++ +Es wird empfohlen, pro Bundesamt eine für OSS verantwortliche Person zu bezeichnen, z. B. IT-Verantwortliche (IM), Enterprise Architect, ISBO oder DSBO, um einheitliche und effiziente Prozesse sicherzustellen. Ist dies nicht festgelegt, ist grundsätzlich die Amtsleitung für die rechtskonforme Umsetzung verantwortlich. ++ +Diese Person könnte auch für die Bewilligung von Ausnahmen von der Veröffentlichungspflicht beigezogen werden. + +=== Zusammenarbeit mit Drittanbietern + +[qanda.unnumbered] +Wie sind Eigenentwicklungen einer Bundesbehörde zu veröffentlichen?:: +Das Urheberrecht entsteht bei den jeweiligen natürlichen Personen, die den Quellcode entwickelt haben, wird aber in der Regel über den Arbeitsvertrag auf die Arbeitgeberin übertragen. In Verträgen mit externen Dienstleistern ist es wichtig, Neuentwicklungen klar abzugrenzen und die vertragliche Abtretung bzw. Übertragung des Urheberrechts zu vereinbaren. Bei gemeinsamen Eigenentwicklungen müssen sich die Beteiligten schliesslich auf die Open-Source-Lizenz für den Quellcode einigen, unter der die Software als eigenständiges Open-Source-Projekt veröffentlicht wird. Die Veröffentlichung unter einer Open-Source-Lizenz bedeutet keinen Verzicht auf das Urheberrecht: Dieses verbleibt bei den jeweiligen Rechteinhabern. Nur gestützt auf ihr Urheberrecht können sie sich rechtlich gegen Lizenzverletzungen wehren oder parallel zu den OSS-Lizenzen weitergehende Lizenzen erteilen. + +=== Bekanntgabe von Personendaten + +[qanda.unnumbered] +Unter welchen Voraussetzungen dürfen Personendaten, etwa von Entwicklerinnen und Entwicklern, im Rahmen von OSS veröffentlicht werden?:: +Dafür gibt es keine allgemeine Regel. Der Entscheid liegt beim Projekt. ++ +In jedem Fall sind die anwendbaren Datenschutzbestimmungen einzuhalten. Nach Artikel 36 Abs. 1 DSG dürfen Bundesorgane Personendaten nur bekannt geben, wenn dafür eine gesetzliche Grundlage besteht. ++ +Artikel 36 Abs. 2 DSG nennt unter anderem folgende Ausnahmen: ++ +(b) Die betroffene Person hat in die Bekanntgabe eingewilligt. ++ +(e) Die betroffene Person hat ihre Daten allgemein zugänglich gemacht und eine Bearbeitung nicht ausdrücklich untersagt. ++ +In den meisten Fällen empfiehlt es sich, die Einwilligung der betroffenen Personen vorgängig einzuholen, da diese in der Regel selbst ein Interesse daran haben, dass ihre Arbeit öffentlich sichtbar ist. Wird die Einwilligung nicht erteilt oder sprechen andere Gründe gegen eine Veröffentlichung, sollte der Quellcode ohne Personendaten veröffentlicht werden, unter alleinigem Verweis auf die betreffende Bundesbehörde. ++ +Diese Einwilligung sollte bei Lieferanten und Mitarbeitenden im Rahmen der Beschaffungs- und Anstellungsprozesse eingeholt werden. + +=== Beschaffung + +[qanda.unnumbered] +Wo finde ich die Unterlagen zur OSS-Beschaffung?:: +Mit der Version 2.0 wurde das Hilfsmittel link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software] bereitgestellt. ++ +Das Kompetenzzentrum Beschaffungswesen Bund (KBB) hat ein neues Merkblatt Softwarebeschaffung und Art. 9 EMBAG [KBB-MB] sowie zwei Dokumente «Musterkriterien – EMBAG-Beschaffung und Open Source.docx» und «Mustervertragstexte – Softwareentwicklung.docx» veröffentlicht. ++ +Weitere Hilfsmittel finden sich auf der Lern- und Vorlagenplattform des öffentlichen Beschaffungswesens (www.perimap.admin.ch). ++ +Weitere Unterstützung bietet das BBL-Intranet (nur im Bundesnetz zugänglich) mit der Weisung Open Source in der Beschaffung [BBL-WL] und der Checkliste zur generellen Ausnahme nach Art. 9 EMBAG [BBL-CL]. ++ +Die entsprechenden Informationen finden sich auf den Intranetseiten des BBL (nur innerhalb der Bundesverwaltung verfügbar). ++ +Links: BBL-Werkzeugkasten IT-Beschaffung + +== Prozess + +=== Anleitung + +[qanda.unnumbered] +Gibt es eine zentrale Anleitung, wie in der Bundesverwaltung mit OSS umzugehen ist?:: +Ja, der Bereich DTI der Bundeskanzlei stellt dafür umfassende Unterlagen bereit. ++ +Zu beachten ist, dass diese Hilfsmittel eine IKT-Empfehlung und keine verbindliche Vorgabe darstellen. ++ +Link zu den OSS-Hilfsmitteln + +Wie sind Eigenentwicklungen einer Bundesbehörde zu veröffentlichen, die in Zusammenarbeiten entstanden sind? Wie ist mit bestehenden Rechten umzugehen?:: +Bei der Softwareentwicklung [.underline]#entsteht das Urheberrecht bei den jeweiligen natürlichen Personen#, die den Quellcode entwickelt haben. ++ +Steht die entwickelnde Person in einem Arbeitsverhältnis, gehören die Entwicklungen der Arbeitgeberin (Art. 332 OR). ++ +Bei Verträgen mit externen Dienstleistern ist es deshalb wichtig, Neuentwicklungen klar abzugrenzen und die vertragliche Abtretung bzw. Übertragung des Urheberrechts zu vereinbaren. Bei gemeinsamen Eigenentwicklungen müssen sich die Beteiligten schliesslich auf die Open-Source-Lizenz für den Quellcode einigen, unter der die Software als eigenständiges Open-Source-Projekt veröffentlicht wird. ++ +Die Veröffentlichung unter einer Open-Source-Lizenz bedeutet keinen Verzicht auf das Urheberrecht: Dieses verbleibt bei den jeweiligen Rechteinhabern. ++ +Nur gestützt auf ihr Urheberrecht können sie sich rechtlich gegen Lizenzverletzungen wehren oder parallel zu den OSS-Lizenzen weitergehende Lizenzen erteilen. ++ +Die [.underline]#Originalrechte# sollten deshalb bei Neu- oder Weiterentwicklungen nach Möglichkeit immer beim Bund liegen. Für weitere Beteiligte sind [.underline]#Contributor Licence Agreements# (CLA) oder ein Developer Certificate of Origin (DCO) einzusetzen. Anleitungen dazu finden sich in link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen], link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]. + +Müssen Änderungen veröffentlicht werden?:: +Nach Art. 9 EMBAG: ja, wenn sie nach dem 1. Januar 2024 entwickelt wurden. ++ +Dies sollte jedoch so geschehen, dass daraus auch ein Nutzen entsteht. Das Dokument link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] informiert über den Prozess. + +Wann ist die Veröffentlichung nach EMBAG «ausreichend»?:: +Art. 9 EMBAG ist hier nicht spezifisch, und es besteht ein grosser Spielraum. Der Quellcode muss öffentlich zugänglich sein. ++ +Die Anforderungen des Gesetzes sind beispielsweise bereits erfüllt, wenn der Quellcode als Zip-Datei auf einer Website veröffentlicht wird. ++ +Um einen Nutzen zu erzielen, auch durch die Veröffentlichung von Dokumentation usw., sollte dies in einem Code-Repositorium nach Best Practices geschehen. Informationen dazu finden sich in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software]. + +Werden die Leistungsbezüger künftig den Leistungserbringern vorgeben, wie die Software zu veröffentlichen und die Qualität sicherzustellen ist?:: +Für Leistungserbringer wie für Leistungsbezüger gelten die Regeln der jeweiligen Bundesbehörde. ++ +Es ist jedoch sinnvoll, die entsprechenden Hilfsmittel an geeigneten Stellen in die bestehenden Prozesse und Quality Gates einzubauen. ++ +Der Leistungserbringer kann hier aufgrund seiner Entwicklungserfahrung Vorschläge für seine Leistungsbezüger machen und dies einheitlich handhaben (so wie auch der Entwicklungsprozess einheitlich gehandhabt wird). + +=== Lizenzwahl + +[qanda.unnumbered] +Unter welcher Open-Source-Lizenz soll Software entwickelt werden?:: +Es bestehen keine strikten Vorgaben zur Lizenzwahl, solange die Lizenzbedingungen der in der zu entwickelnden Software verwendeten Softwarekomponenten eingehalten werden. ++ +Bei vollständigen Neuentwicklungen sollte ein Lizenztyp gewählt werden, der eine breite und nachhaltige Basis für Weiterentwicklungen ermöglicht. ++ +Dafür ist wichtig, dass die betreffende Lizenz in der relevanten Entwickler-Community breit akzeptiert ist. ++ +*Empfohlen wird deshalb die Verwendung von AGPL (mit Copyleft) und MIT.* ++ +Diese beiden Lizenzen stellen gewissermassen die beiden Extreme des Lizenzspektrums dar. ++ +Die AGPL mit sehr starkem Copyleft setzt den Grundsatz «Public Money – Public Code» dauerhaft durch. Bei Weiterentwicklungen, namentlich proprietären Lösungen, schwächt sich dies in Richtung LGPL ab. ++ +MIT ist demgegenüber eine sehr liberale Lizenz, bei der fast alles möglich ist. ++ +Die beiden Lizenzen decken das gesamte Spektrum ab. Wird bei permissiven Lizenzen besonderer Wert darauf gelegt, den Bund nicht zu nennen, ist BSD-3 gegenüber MIT vorzuziehen. ++ +Für eine detailliertere Lizenzwahl verweisen wir auf link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen]. + +=== Qualitätskriterien für OSS + +[qanda.unnumbered] +Muss Open-Source-Software bestimmte Qualitätskriterien erfüllen?:: +Grundsätzlich gelten alle Qualitätskriterien, die auch für jede andere Software gelten. Open Source macht vor allem alles transparenter. Zur Einhaltung der Lizenz, der Kriterien für eine «gute» Freigabe und allfälliger Community-Regeln sind einige zusätzliche Punkte nötig. Diese sind in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] und link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] aufgeführt. + +Welche Anforderungen sind für Quality Gates vorgesehen?:: +Es sind keine zentralen Vorgaben vorgesehen. Massgebend sind die Regeln der Bundesbehörde (Verwaltungseinheit), welche die Software entwickelt. ++ +Abgesehen von den allgemeinen Anforderungen bestehen keine besonderen Anforderungen an die OSS-Qualität. HERMES wird jedoch im Hinblick auf Art. 9 EMBAG aktualisiert. ++ +Die Veröffentlichung ist der Auftritt der Bundesverwaltung in der Öffentlichkeit. Geschieht dies nicht sorgfältig und professionell, kann das öffentliche Ansehen einer Bundesbehörde rasch leiden. + +Wie werden Entwicklungsrichtlinien geregelt?:: +Abgesehen von den allgemeinen Anforderungen in den Hilfsmitteln bestehen keine besonderen Vorgaben zur Entwicklung von Open-Source-Software. Hinweise finden sich in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] und link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]. + +Muss OSS an einem bestimmten Ort veröffentlicht werden?:: +Der Bund betreibt derzeit kein eigenes zentrales Repositorium. Die Bundesbehörden sind daher in ihrer Veröffentlichung grundsätzlich frei. Da viele Bundesbehörden bereits GitHub nutzen, ist diese Plattform derzeit die bevorzugte Wahl. Es besteht zudem ein zentrales GitHub-Konto (swiss), das genutzt werden kann. ++ +GitHub – swiss/index: eine Übersicht über die aktuellen Repository-Organisationen. ++ +Dies gilt insbesondere, wenn eine Bundesbehörde noch kein GitHub-Konto («Organisation») hat oder keine andere Plattform wie GitLab oder BitBucket nutzt. ++ +Bitte wenden Sie sich an die zuständige Stelle im DTI (opensource@bk.admin.ch), um zu prüfen, ob eine Veröffentlichung über das zentrale GitHub-Konto (swiss) sinnvoll und möglich ist. ++ +Bundesbehörden sollten in jedem Fall eine lokale Kopie des Codes vorhalten. Ebenso empfiehlt es sich, dass jede Bundesbehörde über eine entsprechende Strategie und entsprechende interne Regelungen verfügt. ++ +Weitere Empfehlungen finden sich in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software]. + +=== Dokumentation + +[qanda.unnumbered] +Welche Dokumentationsanforderungen bestehen für die Veröffentlichung von OSS?:: +Die vom Bereich DTI der Bundeskanzlei bereitgestellten Hilfsmittel informieren über die rechtlichen Anforderungen; siehe OSS-Hilfsmittel. ++ +Es wird empfohlen, die OSS-Checklisten auszufüllen und in jeder Bundesbehörde (Verwaltungseinheit) zentral abzulegen. + +=== Beiträge der Bundesverwaltung an Projekte + +[qanda.unnumbered] +Kann und soll eine Verwaltungseinheit Code an ein «Upstream»-Projekt beitragen, und erfüllt sie damit die Anforderungen von Art. 9 EMBAG?:: +* Sind die Projekte Open Source, ist Art. 9 EMBAG erfüllt. Die Projekte müssen jedoch auch Open Source bleiben. Ist dies nicht der Fall, muss der Code erneut veröffentlicht werden. +* Upstream-Beiträge haben den Vorteil, dass der Unterhalt im Upstream-Projekt stattfindet und der Nutzen für die Community maximiert wird. ++ +Es bestehen folgende Nachteile: weniger Kontrolle und Einfluss; unter Umständen muss ein CLA oder ein DCO unterzeichnet werden (siehe link:em002-4.pdf[Em002-4] Kapitel 3.3). Die Beiträge erscheinen zudem nicht im publiccode.yml und in den Verzeichnissen des Bundes. Ein ganz anderer Vorteil ist, dass sich die Entwicklerinnen und Entwickler mit solchen Beiträgen weiter im Ökosystem entwickeln. +* Solange Risiken und Aufwand überschaubar bleiben (Inhalt des CLA, Sammlung des Codes), sind Upstream-Beiträge zu begrüssen. +* Für den Beitrag gilt dann die Lizenz des Upstream-Projekts. Dies entspricht dem Vorgehen in link:em002-3.pdf[Em002-3]. +* *Forks von Upstream-Projekten sind zu vermeiden:* Der gesamte Unterhalts- und Aktualisierungsaufwand fällt dann bei der Bundesbehörde an. Ein ungenügend gepflegter Fork stellt zudem ein Sicherheitsrisiko dar. Für die Community entsteht kaum ein Nutzen. +* Beiträge an Upstream-Projekte sollten grundsätzlich positiv beurteilt und von den Projektleitenden der Bundesbehörden aktiv thematisiert werden. +* Gehört das Upstream-Projekt der Bundesverwaltung und geht es um Beiträge Dritter, hilft link:em002-7.pdf[Em002-7] Kapitel 9 weiter. + +=== Support + +[qanda.unnumbered] +Muss die Bundesbehörde Support für veröffentlichte Software leisten?:: +Nein, sie kann dies aber, wenn sie will. ++ +Nach Art. 9 Abs. 5 und 6 EMBAG darf sie für den Support auch Gebühren erheben. + +Wie geht eine Behörde vor, wenn sie Support verrechnen will?:: +Aus Ressourcengründen ist dies nicht Teil des aktuellen Projekts zur Bereitstellung von Hilfsmitteln. Bei Bedarf könnte dies in einer späteren Etappe in die Hilfsmittel aufgenommen werden. Vorerst regelt jede Bundesbehörde dies selbst. (Siehe auch link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]) + +== Hilfsmittel + +=== Anleitung + +[qanda.unnumbered] +Gibt es eine zentrale Anleitung zum Umgang mit Open-Source-Software in der Bundesverwaltung?:: +Ja, der Bereich DTI der Bundeskanzlei stellt dafür im Rahmen von link:em002.pdf[Em002 Strategische Vorgaben für Open-Source-Software in der Bundesverwaltung] umfassende Unterlagen bereit. ++ +OSS wird allgemein in link:em002-1.pdf[Em002-1 Praxisleitfaden Open-Source-Software in der Bundesverwaltung] behandelt. Die Freigabe nach Art. 9 EMBAG wird in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] behandelt. + +=== Checklisten + +[qanda.unnumbered] +Umfassen die Hilfsmittel auch Checklisten für die Freigabe von Open-Source-Software?:: +Ja, der Bereich DTI der Bundeskanzlei stellt folgende Checklisten zur freien Verwendung bereit: ++ +-- +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] + +Siehe zudem die *Checkliste zur generellen Ausnahme nach Art. 9 EMBAG* [BBL-CL] des BBL. +-- + +=== Sicherheitsfragen + +[qanda.unnumbered] +Gibt es besondere OSS-Sicherheitsrisiken?:: +In diesem Zusammenhang werden beispielsweise Supply-Chain-Angriffe, Zero-Day-Schwachstellen und Typosquatting-Angriffe genannt. ++ +Solche Sicherheitsfragen sind bei OSS und deren Beschaffung, aber auch generell bei der Entwicklung von Software und bei der Beschaffung kommerzieller Software zu berücksichtigen. Sie können sich allenfalls etwas verstärken, wenn das eingesetzte OSS-Projekt bei der Einbindung von Bibliotheken und Containern unsorgfältig war. ++ +Mittelfristig braucht es eine allgemeine Strategie zur Minderung dieser Risiken (über das NCSC/BACS). Bei Bedarf sind sichere Quellen für Container und Bibliotheken bereitzustellen. ++ +Generell müssen alle Verantwortlichen im IT-Umfeld diese möglichen Angriffsvektoren kennen. Mögliche Versuche sind: ++ +* Supply-Chain-Angriffe: `XZ_Utils_backdoor` (https://en.wikipedia.org/wiki/XZ_Utils_backdoor), Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/) +* Zero-Day-Schwachstellen: Log4Shell (https://www.ibm.com/de-de/think/topics/log4j) +* Typosquatting: https://en.wikipedia.org/wiki/Typosquatting + +Erhöht die Veröffentlichung des Quellcodes das Risiko einer bösartigen Kopie einer App? (z. B. einer Phishing- oder Fake-App):: +Nein. Das Zurückhalten von Quellcode bietet keinen wirksamen Schutz vor Fake-Apps und ist zudem nicht mit Artikel 9 EMBAG vereinbar, der das Open-Source-Prinzip für die Bundesverwaltung festlegt. ++ +Das Risiko, dass eine Drittperson eine optisch identische App baut, um Daten abzugreifen, besteht unabhängig davon, ob der Quellcode veröffentlicht ist. Da die Designsysteme des Bundes öffentlich verfügbar sind, kann das Erscheinungsbild einer App auch ohne Zugriff auf den Quellcode nachgebaut werden. Apps lassen sich zudem dekompilieren, um Elemente wie Logos aus der veröffentlichten Version zu extrahieren. ++ +Sicherheit und Vertrauen werden deshalb nicht durch Geheimhaltung, sondern durch Verifikation und kryptografische Sicherheit gewährleistet: ++ +-- +* *Digitale Signaturen:* Offizielle Apps müssen kryptografisch signiert sein; damit ist technisch sichergestellt, dass eine App ein unverändertes Original des Bundes ist. Das Betriebssystem des Smartphones überprüft diese Signatur. +* *App-Store-Verifikation:* Die App Stores von Apple und Google bieten Verfahren an, um Herausgeber als offizielle staatliche Stellen zu verifizieren. Google kennzeichnet beispielsweise Apps der Bundeskanzlei (BK) ausdrücklich als Behörden-Apps, was den Nutzerinnen und Nutzern Vertrauen in deren Echtheit gibt. +* *Reproducible Builds:* Durch unabhängige, reproduzierbare Builds lässt sich technisch nachweisen, dass der veröffentlichte Quellcode genau der im Store verfügbaren App entspricht. + +Eine generelle Ausnahme aus sicherheitsrelevanten Gründen nach Artikel 9 EMBAG ist bei Apps deshalb nicht anwendbar. + +[.underline]#Empfehlung:# + +Statt Quellcode zurückzuhalten, sollte der Fokus auf den App-Store-Prozessen und der Überwachung liegen. Offizielle Kanäle sind aktuell zu halten, und Fake-Apps sind umgehend zur Entfernung durch die Plattformbetreiber (Apple und Google) zu melden. +-- + +Ist es sinnvoll, dass sich Bedarfsstellen innerhalb der Bundesverwaltung für die Beschaffung von OSS zusammenschliessen?:: +Ja, unbedingt. Dies kann direkt und formlos zwischen Verwaltungseinheiten geschehen. ++ +Das Problem ist eher, dass die Verwaltungseinheiten wenig über den Bedarf der anderen wissen. ++ +Eine Lösung könnte sein, dass Verwaltungseinheiten eine «Most Wanted»-Liste von OSS-Werkzeugen (oder Bibliotheken) führen, die entwickelt oder bereitgestellt werden sollen, und diese Liste teilen. ++ +Eine solche zentral geführte Liste könnte auch helfen, den Bedarf an OSS-Komponenten besser zu analysieren und den Reifegrad der Verwaltungseinheit besser einzuschätzen. Letztlich wäre ein Artifact-Repository sinnvoll. ++ +Die Führung einer solchen Liste wäre dann Aufgabe eines OSPO, sofern ein solches eingeführt wird. Bestenfalls könnte dies auch über Digitale Öffentliche Dienste Schweiz für die gesamte Föderalstruktur erfolgen. + +== Rechtliche Fragen + +=== Verwendung des Englischen + +[qanda.unnumbered] +Darf der Bund Lizenzen in der Originalsprache Englisch verwenden?:: +Nach Art. 9 Abs. 4 EMBAG sollen wo möglich und sinnvoll international etablierte Lizenztexte verwendet werden. ++ +Auf deutschsprachigen OSS-Lizenzen zu beharren, würde den Zweck von Art. 9 Abs. 4 EMBAG weitgehend zunichtemachen, da es nur sehr wenige international etablierte Lizenztexte gibt, bei denen eine Fassung in einer der Amtssprachen der Schweiz (Deutsch, Französisch und Italienisch nach Art. 70 Abs. 1 BV) als für die Auslegung massgebend anerkannt ist. ++ +Diese Situation entspricht derjenigen englischsprachiger Studiengänge an Hochschulen wie der ETH, wo Englisch als Unterrichtssprache zulässig ist – unter den drei Voraussetzungen von Artikel 36 der Bundesverfassung (St. Galler Kommentar zur Bundesverfassung, 4. Aufl. 2023, Art. 70 N 29; es müssen also eine gesetzliche Grundlage, ein öffentliches Interesse und Verhältnismässigkeit gegeben sein, damit Englisch zulässig ist). ++ +Vor diesem Hintergrund ist Art. 9 Abs. 4 EMBAG so auszulegen, dass er die gesetzliche Grundlage für die Verwendung englischsprachiger Lizenzen bildet, da internationale Lizenzen überwiegend auf Englisch verfasst sind. Die Bestimmung muss sich daher auf diese beziehen. ++ +Das öffentliche Interesse an Art. 9 EMBAG liegt unter anderem im Austausch mit den jeweiligen Entwickler-Communitys.footnote:[BBl 2022 804, S. 66] In der Informatikbranche sind diese Communitys typischerweise international und verwenden Englisch als Arbeitssprache. Eine Beschränkung auf deutschsprachige Lizenzen würde die Zusammenarbeit mit internationalen Communitys zumindest erschweren, wenn nicht verunmöglichen, weil so lizenzierte Software international kaum genutzt würde. Dies stünde auch im Widerspruch zum Zweck von Artikel 9 EMBAG. ++ +Zudem gelten international etablierte OSS-Lizenzen definitionsgemäss weltweit. Der Gesetzgeber wollte offensichtlich die internationale Nutzung der freigegebenen Software ermöglichen. Eine Beschränkung von OSS-Freigaben auf deutschsprachige Lizenzen würde die internationale Nutzbarkeit der freigegebenen Software stark einschränken. ++ +Hinzu kommt, dass Englisch als Standardsprache im kommerziellen Umfeld der Informatikbranche fest etabliert ist, wozu auch OSS-Freigaben gehören. Die Verwendung englischsprachiger Lizenzen stellt daher eine zumutbare und verhältnismässige Einschränkung der Rechte der Vertragspartner dar. Englischsprachige Lizenzen sind zur Erreichung der angestrebten Ziele überdies geeignet und erforderlich. + +=== Haftungsausschluss + +[qanda.unnumbered] +Die meisten OSS-Lizenzen enthalten Haftungsausschlüsse. Genügt das, oder sind zusätzliche Massnahmen nötig? Wie verhält es sich bei fehlerhafter Software? (unter Einbezug des Verantwortlichkeitsgesetzes):: +Die anwendbaren Lizenzen schliessen die Haftung für leichte Fahrlässigkeit aus. *Für grobe Fahrlässigkeit oder Vorsatz kann die Haftung nicht ausgeschlossen werden.* Die praktischen Haftungsrisiken sind jedoch minimal. ++ +Wird veränderte Software unter einer Lizenz verbreitet, die mit der Lizenz der ursprünglichen Software unvereinbar ist (etwa unter einer MIT-Lizenz ohne Copyleft, obwohl der ursprünglich verwendete Code unter einer GPL-Lizenz mit Copyleft stand), verletzt dies die ursprüngliche Lizenz. Mangels Gutglaubensschutz im Immaterialgüterrecht können andere Nutzerinnen und Nutzer die ursprüngliche Software dadurch weder plötzlich unter der neuen Lizenz nutzen, noch entsteht eine durchsetzbare Pflicht, die neue Lizenz zu den Bedingungen der ursprünglichen Lizenz anzubieten. Einzige Folge ist die Verletzung der ursprünglichen Lizenz, was zu Schadenersatzansprüchen (Lizenzanalogie) gegen eine Bundesbehörde führen kann. ++ +Dieses Risiko lässt sich jedoch durch systematische Prüfung nach den Leitfäden beherrschen, wie dies in der Softwarebranche heute Standard ist. Konkret verlangt die Lizenzierung die Erstellung einer Stückliste aller vorbestehenden Softwarebestandteile, die in die neue Software einfliessen; diese ist bei der Lizenzierung strikt einzuhalten. ++ +Bestehen Rechte Dritter, verlangt Art. 9 Abs. 1 EMBAG ohnehin keine Veröffentlichung der Software (oder allenfalls nur der neu geschriebenen Teile; dies ist in den Leitfäden zu klären). ++ +Nach Artikel 11 des Verantwortlichkeitsgesetzes richtet sich die Haftung des Bundes nach Zivilrecht, wenn er als Zivilrechtssubjekt auftritt. Dies ist nach Art. 9 Abs. 2 EMBAG der Fall; eine zusätzliche Haftung nach dem Verantwortlichkeitsgesetz ist folglich ausgeschlossen. + +=== Permissive Software + +[qanda.unnumbered] +Wenn Software auf einer Bibliothek bzw. Programmkomponente unter einer permissiven Lizenz beruht: Kann die Hauptsoftware (ohne die Bibliothek) unter einer nicht permissiven Lizenz veröffentlicht werden?:: +Ja, das ist unproblematisch. Siehe die Angaben im Leitfaden link:em002-3.pdf[Em002-3]. + +=== Lizenzbestimmungen + +[qanda.unnumbered] +Kann Software von mehreren Ämtern genutzt werden? Welche Lizenzbestimmungen gelten innerhalb der Bundesverwaltung? Gilt die Bundesverwaltung als Konzern? (Dies betrifft unveränderte Open-Source-Software von Dritten.):: +Die Verbreitung von Software unter permissiven Lizenzen ist in der Regel unproblematisch. ++ +Bei Copyleft-Lizenzen stellt sich jedoch die Frage, ob die Verbreitung innerhalb der zentralen oder dezentralen Bundesverwaltung Copyleft-Pflichten auslöst und damit die Vertraulichkeit der Eigenentwicklungen des Bundes gefährdet. Bei der Weitergabe an Institutionen der dezentralen Bundesverwaltung mit eigener Rechtspersönlichkeit ist dies tatsächlich der Fall, innerhalb der zentralen Bundesverwaltung dagegen nicht, da alle Departemente unter derselben Rechtspersönlichkeit handeln. ++ +Konzerngesellschaften sind rechtlich selbstständig, stehen aber unter der wirtschaftlichen Kontrolle der Muttergesellschaft. Die Rechtsliteratur betrachtet die Weitergabe von Copyleft-lizenziertem Code an eine Konzerngesellschaft als Auslöser von Copyleft-Pflichten. Da Konzerngesellschaften bei der Softwareentwicklung häufig Open-Source-Software erhalten, benötigen sie ein eigenes Nutzungsrecht; die Weitergabe an eine Konzerngesellschaft löst somit Copyleft-Pflichten aus. ++ +Demgegenüber löst die Weitergabe innerhalb der zentralen Bundesverwaltung keine Copyleft-Pflichten aus. Für die dezentrale Bundesverwaltung mit eigenen Rechtspersönlichkeiten gilt das Obenstehende: Die Weitergabe löst Copyleft-Pflichten aus, und die Software muss im Quellcode zu denselben Lizenzbedingungen wie die ursprüngliche Software angeboten werden. Eine Weisung, die Software nicht an Dritte weiterzugeben, würde die Lizenz verletzen und könnte auch gegen Art. 9 EMBAG verstossen. + +=== Verhältnis zwischen BGÖ und EMBAG + +[qanda.unnumbered] +In welchem Verhältnis stehen das Öffentlichkeitsgesetz (BGÖ) und das EMBAG zueinander?:: +Nach Art. 6 BGÖ sind amtliche Dokumente herauszugeben. Als amtliches Dokument gilt nach Art. 5 Abs. 1 BGÖ jede Information, die auf einem beliebigen Informationsträger aufgezeichnet ist, sich im Besitz einer Behörde befindet und die Erfüllung einer öffentlichen Aufgabe betrifft. OSS fällt grundsätzlich unter das BGÖ. Das BGÖ kommt zur Anwendung, wenn eine Person von einem Departement oder Amt Quellcode zur eigenen Nutzung verlangt. Das Amt muss der betreffenden Person den Quellcode offenlegen, sofern keine Ausnahmen nach Artikel 7 BGÖ greifen. Verweigert das Amt die Offenlegung des Quellcodes, gilt das BGÖ-Verfahren. Anders liegt der Fall, wenn jemand verlangt, dass das Amt den Quellcode auf seiner Website veröffentlicht. Dann richtet sich das Verfahren nicht nach dem BGÖ, sondern nach dem EMBAG. Da das EMBAG selbst kein Verfahren vorsieht, muss das allgemeine Verwaltungsrecht genügen. Dieses bietet entweder die Möglichkeit einer Verfügung, eines Realakts oder einer allgemeinen Feststellungsverfügung des betreffenden Amtes. Dieser Entscheid kann anschliessend beim Bundesverwaltungsgericht angefochten werden. ++ +Während Offenlegungspflichten für von einer Bundesbehörde entwickelte Software nach dem BGÖ denkbar sind (wenn die entsprechenden Voraussetzungen erfüllt sind), ist zu beachten, dass die Offenlegung von Software nach dem BGÖ nicht automatisch eine OSS-Lizenz gewährt. Die Nutzung von nach dem BGÖ offengelegter Software beschränkt sich somit auf die vom BGÖ gesetzten Zwecke, etwa die Einsichtnahme in den Code oder dessen Ausführung zu Beobachtungszwecken. Die Offenlegung nach BGÖ umfasst jedoch keine Lizenz zur regulären Nutzung der Software oder als Grundlage für die Weiterentwicklung von Software (Einzelheiten in T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern, Zürich 2017, https://carlgrossmann.com/?ddownload=11748, N 393 ff.). ++ +Der Entscheid, Software als OSS zu lizenzieren, richtet sich auch dann weiterhin nach dem EMBAG, wenn sie unter das BGÖ fällt; ein Anspruch auf Erteilung einer Lizenz besteht nach wie vor nicht. ++ +Wichtig ist: Software, die vor dem 1. Januar 2024 entwickelt wurde, untersteht zwar nicht dem EMBAG, muss aber dennoch nach dem BGÖ herausgegeben werden. + +=== OSS und Datenschutz + +[qanda.unnumbered] +Können Personendaten von Entwicklerinnen und Entwicklern ohne Weiteres veröffentlicht werden? Welche Datenschutzaspekte sind zu beachten?:: +Aus datenschutzrechtlicher Sicht ist die Veröffentlichung von Personendaten (z. B. Namen oder E-Mail-Adressen) problematisch, sofern die Mitarbeitenden nicht vorgängig eingewilligt haben. Denn die Bekanntgabe von Personendaten kann grundsätzlich durch Pseudonymisierung oder Anonymisierung der Repository-Einträge vermieden werden, was nach dem Grundsatz der Datenminimierung und der Verhältnismässigkeit (Art. 6 Abs. 2 DSG) erforderlich wäre. ++ +Eine solche Einwilligung dürfte jedoch in der Regel leicht zu erhalten sein, da Mitarbeitende oft ein Interesse daran haben, ihre Fähigkeiten öffentlich zu zeigen (so Poledna/Schlauri/Schweizer, N 68, mit Hinweisen). Eine Einwilligung kann auch konkludent durch die Verwendung von Namen im Repositorium erfolgen, zumindest wenn keine gegenteilige Weisung der Arbeitgeberin besteht. ++ +Dennoch empfiehlt es sich, die Verantwortung des Anbieters für die Personendaten seiner Mitarbeitenden in den Verträgen zu regeln. + +== Allgemeines + +[qanda.unnumbered] +Spielt es eine Rolle, ob OSS kommerziell oder nicht kommerziell genutzt wird?:: +Open-Source-Lizenzen unterscheiden in der Regel nicht zwischen kommerzieller und nicht kommerzieller Nutzung. OSS kann daher für jeden Zweck genutzt werden, auch für kommerzielle Anwendungen. Kommerzielle Anbieter versuchen oft, OSS-Komponenten in proprietäre Produkte einzubinden. Dies ist nur zulässig, wenn die OSS-Komponenten nicht unter einer Lizenz mit Copyleft-Wirkung stehen (siehe auch link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen]). + +Bestehen Einschränkungen, welche Organisationen für Communitys zulässig sind?:: +Letztlich ist immer der Einzelfall zu betrachten: Wer steht dahinter, und welche Verpflichtungen werden eingegangen? ++ +Solange kein Geld fliesst und keine formellen Verpflichtungen eingegangen werden, ist die Lage vergleichsweise einfach und unproblematisch. ++ +Vereinsmitgliedschaften sind möglich, ebenso eine informelle Zusammenarbeit. ++ +Mitgliedschaften können an eOperations oder ähnliche Organisationen delegiert werden. ++ +Siehe auch link:em002-4.pdf[Em002-4 Leitfaden OSS-Community], Kapitel 3.1 + +Wie verhält sich die ISO-Norm 5230 zu den Leitfäden?:: +Die ISO-Norm 5230:2020 wurde bei der Erarbeitung der Leitfäden geprüft und berücksichtigt. Die folgende Liste führt die Anforderungen der Norm auf und zeigt, wie diese in den Leitfäden adressiert wurden: ++ +-- +*3.1 Programme foundation* + +* Die «link:em002.pdf[Em002 Strategische Vorgaben für Open-Source-Software in der Bundesverwaltung]» und die referenzierten Strategien bilden den Rahmen. Für die Umsetzung sind die jeweiligen Departemente und Ämter zuständig. + +*3.2 Relevant tasks defined and supported* + +* Der Leitfaden «link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS]» und die Checklisten definieren konkrete Aufgaben für die Veröffentlichung. Eine zentrale Stelle besteht in der Bundesverwaltung derzeit nicht. + +*3.3 Open source content review and approval* + +* Der Veröffentlichungsprozess wird im Hilfsmittel «link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS]» beschrieben. Dieses verweist auch auf das Bestehen einer Software Bill of Materials (SBOM). +* Das Hilfsmittel «link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzen]» informiert umfassend über die Lizenzierung. + +*3.4 Compliance artifact creation and delivery* + +* Der Veröffentlichungsprozess wird im Hilfsmittel «link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS]» beschrieben. Dieses verweist auch auf das Bestehen einer Software Bill of Materials (SBOM). +* Die Umsetzung wird nicht näher beschrieben und erfolgt in den Departementen oder Ämtern. + +*3.5 Understanding open source community engagements* + +* Das Hilfsmittel «link:em002-4.pdf[Em002-4 Leitfaden OSS-Community]» beschreibt, wie eine Community aufgebaut und gepflegt wird. Für jedes Projekt ist ein Konzept zu definieren und umzusetzen. + +*3.6 Adherence to the specification requirements* + +* Das Schlusskapitel enthält Anforderungen an Organisationen oder Projekte, die die Einhaltung der OpenChain-Anforderungen ausdrücklich bestätigen wollen. +-- ++ +Die ISO-Norm umreisst weitere Verantwortungsbereiche eines Open Source Programme Office (OSPO), die von den Leitfäden nicht abgedeckt werden. + +== Anhang + +=== Abkürzungen + +[horizontal] +include::partials/abbreviations.de.adoc[tags=abbr-em002-6] + +=== Glossar + +Weitere Begriffe finden sich in TERMDAT, der https://www.bk.admin.ch/bk/de/home/dokumentation/sprachen/termdat.html[Terminologiedatenbank] der Bundesverwaltung. + +include::partials/glossary.de.adoc[tags=gloss-em002-6] +endif::[] + +ifeval::["{lang}" == "fr"] +NOTE: Ce document est un projet en cours d'élaboration et fait partie des aides destinées à soutenir l'administration fédérale dans la publication de code open source. Pour plus d'informations, voir le {url-repo}/tree/main[README]. + +== Contexte et objectif + +=== Contexte et objectif de la FAQ + +Les aides à la publication de logiciels open source suscitent régulièrement des questions. La compilation ci-après répond aux questions les plus fréquentes et vise à améliorer la compréhension de certains thèmes et aspects. + +=== Structure et organisation + +La FAQ est organisée par thème: + +[start=2] +. Notions et définitions +. Rôles et responsabilités +. Processus +. Aides +. Questions juridiques +. Généralités + +== Notions et définitions + +=== Logiciel open source + +[qanda.unnumbered] +Qu'entend-on par logiciel open source?:: +Cette notion est définie dans link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale]. + +=== Logiciels et licences + +[qanda.unnumbered] +Qu'entend-on par logiciel?:: +Cette notion est définie dans link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale]. Pour les licences, voir link:em002-3.pdf[Em002-3 Guide des licences OSS]. + +Qu'entend-on par licences?:: +Il s'agit ici de licences de logiciels. De plus amples informations figurent dans link:em002-3.pdf[Em002-3 Guide des licences OSS]. + +Les modèles d'IA développés en interne doivent-ils être considérés comme des logiciels et donc soumis aux exigences légales de l'art. 9 LMETA? Qu'en est-il des données d'entraînement?:: +L'open source désigne les logiciels dont le code source est librement accessible et modifiable à des conditions minimales. Cela comprend également les modèles d'IA entraînés en interne (y compris l'algorithme, la procédure d'entraînement et le code). ++ +Les modèles d'IA sont entraînés à partir de données, le cas échéant des Open (Government) Data. Les Open Data désignent des jeux de données pouvant être librement utilisés, partagés et retraités. Les modèles d'IA dont les données d'entraînement reposent sur des Open (Government) Data sont considérés comme des logiciels au sens de la LMETA et doivent donc également être publiés. ++ +Toutefois, si les données d'entraînement contiennent des données personnelles (sensibles) ou des informations classifiées, il est possible de renoncer à la publication pour des motifs de sécurité. Lors de la publication d'un modèle d'IA en open source, les données d'entraînement ne doivent pas nécessairement être publiées; cela correspond cependant à l'esprit de l'open source et est vivement recommandé par la communauté open source. Pour de plus amples informations sur l'IA, nous renvoyons au Réseau de compétences en intelligence artificielle (CNAI).footnote:[https://cnai.swiss/[CNAI] ainsi que l'art. 10 LMETA] + +Les outils dotés de capacités d'IA générative (p. ex. GitHub Copilot) doivent-ils être contrôlés avant leur utilisation afin qu'aucun droit de propriété intellectuelle de tiers ou de la Confédération ne soit violé?:: +Les contenus générés par un modèle d'IA lui-même ne peuvent pas être protégés par le droit d'auteur, faute d'activité créatrice. Les contenus générés par l'IA qui s'appuient sur des œuvres protégées de tiers peuvent toutefois porter atteinte aux droits de ces tiers. De plus, les sorties des IA étant notoirement peu fiables, elles ne devraient être utilisées qu'après un examen attentif au cas par cas. ++ +Par ailleurs, les exploitants de systèmes d'IA peuvent se réserver, dans leurs conditions d'utilisation, le droit d'employer les entrées pour entraîner le système. Cela peut à son tour conduire à ce que des entrées ou des parties d'entrées soient affichées à des tiers. Lorsque cela ne peut être exclu, il faut s'assurer que les entrées ne violent pas les droits de la Confédération ou de tiers. ++ +Il est recommandé d'examiner et d'autoriser individuellement l'utilisation des outils d'IA. Les outils non autorisés ne peuvent pas être utilisés, mais les collaborateurs peuvent demander l'autorisation d'un outil. Il est souvent judicieux de régler ces questions contractuellement avec le fournisseur; certains fournisseurs proposent aussi des abonnements particuliers par lesquels ils respectent les droits de tiers, p. ex. DeepL. + +=== Base légale dans la LMETA + +[qanda.unnumbered] +Quelle est la base légale de la publication des logiciels open source?:: +Selon l'art. 9 LMETAfootnote:[RS 172.019], les autorités fédérales de l'administration fédérale centrale doivent divulguer le code source des logiciels qu'elles développent ou font développer. Toute personne peut utiliser, développer ou modifier le logiciel sans devoir acquitter d'émoluments. ++ +Il ne peut être renoncé à la publication du code source qu'en raison de droits de tiers ou pour des motifs de sécurité. ++ +De plus amples informations figurent dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +Qu'entend-on par motifs de sécurité?:: +Les motifs de sécurité admis par l'art. 9 LMETA et la manière de les traiter sont définis au chapitre 3.2 de link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +Que sont les droits de tiers?:: +Les droits de tiers au sens de l'art. 9 LMETA et la manière de les traiter sont définis au chapitre 3.3 de link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +Les exceptions peuvent-elles être limitées dans le temps?:: +Les motifs justifiant une exception au sens de l'art. 9 LMETA (droits de tiers et motifs de sécurité) peuvent disparaître avec le temps. ++ +Si tel est le cas, le code source du logiciel doit être publié. + +Quelles conséquences juridiques faut-il envisager en cas de violation de l'art. 9 LMETA?:: +Il existe deux types de violations: ++ +-- +. Des droits de tiers sont violés. +. Une autorité fédérale refuse de publier un logiciel open source (p. ex. en invoquant des motifs de sécurité non fondés). + +Réponse au point 1: + +Il s'agira régulièrement d'une violation contractuelle et des prétentions en dommages-intérêts peuvent être invoquées conformément au code des obligations. + +Réponse au point 2: + +Cela n'a pas de conséquence directe. Si un tiers souhaite pouvoir utiliser le code source d'une autorité fédérale, il doit déposer une demande fondée sur la loi sur la transparence (LTrans; RS 152.3) auprès de l'autorité compétente. + +En cas d'intérêt marqué, il peut être judicieux d'envisager une publication dans l'intérêt des deux parties. Il n'existe aucune obligation de publier rétroactivement, mais cela reste possible à titre volontaire. +-- + +Des prétentions en responsabilité peuvent-elles être invoquées en cas de dommage causé par un logiciel open source?:: +En principe, la responsabilité devrait être exclue dans les contrats. Il n'est toutefois pas possible d'exclure la responsabilité pour négligence grave ou faute. Dans de tels cas, une autorité fédérale pourrait être tenue pour responsable en vertu de la loi sur la responsabilité (LRCF; RS 170.32). + +À partir de quelle date les logiciels doivent-ils être publiés?:: +Selon l'art. 9, al. 1, LMETA, les logiciels développés après le 1^er^ janvier 2024 doivent être publiés. ++ +Pour les logiciels développés avant le 1^er^ janvier 2024, une publication devrait être examinée lorsque des modifications importantes sont prévues. ++ +En cas d'intérêt considérable de tiers, les logiciels existants peuvent également être publiés à titre volontaire (le cas échéant avec une participation aux coûts). Dans ce cas, une communauté (voir link:em002-4.pdf[Em002-4]) devrait aussi être envisagée. ++ +Pour les petits scripts, la publication n'est généralement pas la meilleure option. Il peut exister des dépôts d'outils qui passent alors ensemble par le processus de publication. ++ +Pour les unités administratives de l'administration fédérale décentralisée soumises à la LMETA, l'obligation de publier s'applique depuis le 1^er^ mai 2025. Des exceptions à l'obligation de publier existent pour les logiciels développés sans fonds fédéraux et pour les logiciels de recherche (art. 3, al. 1, OMETA). + +Peut-on exiger la publication rétroactive de logiciels développés avant le 1^er^ janvier 2024?:: +La loi ne prévoit pas de publication rétroactive. ++ +En outre, les contrats conclus avant le 1^er^ janvier 2024 peuvent contenir des droits de tiers qui s'opposent à une publication. ++ +Si une nouvelle version majeure est prévue (major selon le Semantic Versioningfootnote:[https://fr.wikipedia.org/wiki/Gestion_de_versions[Gestion de versions -- Wikipédia]]), une publication de l'ensemble du logiciel devrait être envisagée. Sinon, il faudrait au moins publier le code source des nouvelles fonctionnalités. + +Sur quelle base un tiers devrait-il demander la publication du code source?:: +Un tiers devrait déposer une demande fondée sur la LTrans auprès de l'autorité compétente. + +== Rôles et responsabilités + +=== Rôle de la Chancellerie fédérale + +[qanda.unnumbered] +Qui met à disposition les aides de base pour la mise en œuvre?:: +Le secteur TNI de la Chancellerie fédérale met à la disposition des autorités fédérales des aides sous la forme d'un ensemble de documents accompagnant Em002. Cela comprend les directives stratégiques et d'autres guides pratiques, y compris la FAQ, ainsi que des listes de contrôle destinées à garantir une mise en œuvre conforme au droit. ++ +Les aides OSS sont mises à jour par le secteur TNI. + +La Chancellerie fédérale est-elle compétente pour accorder des exceptions (p. ex. pour des motifs de sécurité)?:: +Il n'existe aucun organe central qui statue sur les exceptions à l'obligation de publier prévue à l'art. 9 LMETA. Chaque autorité fédérale est responsable de sa propre mise en œuvre conforme au droit. ++ +Les départements peuvent édicter des réglementations. ++ +La liste de contrôle relative à l'exception générale selon l'art. 9 LMETA [BBL-CL] de l'OFCL devrait être remplie. + +=== Rôle des unités administratives + +[qanda.unnumbered] +Qui est responsable de la mise en œuvre opérationnelle des publications OSS?:: +Chaque autorité fédérale (p. ex. office, unité administrative) qui développe ou fait développer des logiciels est responsable de l'ensemble du processus de publication. ++ +Les départements peuvent fixer des réglementations contraignantes et des mécanismes de contrôle dans leur domaine de compétence, p. ex. pour éviter des atteintes à la réputation. ++ +Il est recommandé de désigner, par office fédéral, une personne responsable de l'OSS, p. ex. le responsable informatique (IM), l'architecte d'entreprise, le CSI ou le CPD, afin de garantir des processus uniformes et efficaces. Si rien n'est prévu, la direction de l'office est en principe responsable d'une mise en œuvre conforme. ++ +Cette personne pourrait ensuite également être consultée pour l'octroi d'exceptions à l'obligation de publier. + +=== Collaboration avec des fournisseurs tiers + +[qanda.unnumbered] +Comment les développements internes d'une autorité fédérale doivent-ils être publiés?:: +Le droit d'auteur naît auprès des personnes physiques qui ont développé le code source, mais il est généralement transféré à l'employeur par le contrat de travail. Dans les contrats avec des prestataires externes, il est important de délimiter clairement les nouveaux développements et de convenir de la cession ou du transfert contractuel du droit d'auteur. Enfin, pour les développements internes communs, les parties concernées doivent s'accorder sur la licence open source du code source sous laquelle le logiciel est publié en tant que projet open source autonome. Publier sous une licence open source ne signifie pas renoncer au droit d'auteur: celui-ci reste auprès des titulaires respectifs. Ce n'est que sur la base de leur droit d'auteur qu'ils peuvent se défendre juridiquement contre des violations de licence ou accorder, parallèlement aux licences OSS, des licences plus étendues. + +=== Communication de données personnelles + +[qanda.unnumbered] +À quelles conditions des données personnelles, par exemple celles des développeurs, peuvent-elles être publiées dans le cadre d'un logiciel open source?:: +Il n'existe pas de règle générale à ce sujet. La décision appartient au projet. ++ +Dans tous les cas, les dispositions applicables en matière de protection des données doivent être respectées. Selon l'art. 36, al. 1, LPD, les organes fédéraux ne peuvent communiquer des données personnelles que s'ils disposent d'une base légale pour ce faire. ++ +L'art. 36, al. 2, LPD prévoit notamment les exceptions suivantes: ++ +(b) La personne concernée a consenti à la communication. ++ +(e) La personne concernée a rendu ses données accessibles à tout un chacun et ne s'est pas opposée expressément au traitement. ++ +Dans la plupart des cas, il est conseillé d'obtenir préalablement le consentement des personnes concernées, celles-ci ayant généralement elles-mêmes intérêt à ce que leur travail soit visible publiquement. Si le consentement n'est pas donné ou si d'autres motifs s'opposent à la publication, le code source devrait être publié sans données personnelles, en ne mentionnant que l'autorité fédérale concernée. ++ +Ce consentement devrait être obtenu auprès des fournisseurs et des collaborateurs dans le cadre des processus d'acquisition et d'engagement. + +=== Acquisition + +[qanda.unnumbered] +Où trouver la documentation relative à l'acquisition de logiciels open source?:: +Avec la version 2.0, l'aide link:em002-7.pdf[Em002-7 Aspects stratégiques de l'acquisition et logiciels open source] a été mise à disposition. ++ +Le Centre de compétence des marchés publics de la Confédération (CCMP) a publié un nouvel aide-mémoire intitulé Acquisition de logiciels et art. 9 LMETA [KBB-MB] ainsi que deux documents «Critères types – acquisition LMETA et open source.docx» et «Textes contractuels types – développement de logiciels.docx». ++ +D'autres ressources sont disponibles sur la plateforme d'apprentissage et de modèles des marchés publics (www.perimap.admin.ch). ++ +Une aide supplémentaire est disponible sur l'intranet de l'OFCL (accessible uniquement sur le réseau de la Confédération) avec la directive Open source dans les acquisitions [BBL-WL] et la liste de contrôle relative à l'exception générale selon l'art. 9 LMETA [BBL-CL]. ++ +Les informations correspondantes se trouvent sur les pages intranet de l'OFCL (disponibles uniquement au sein de la Confédération). ++ +Liens: boîte à outils de l'OFCL pour l'acquisition informatique + +== Processus + +=== Instructions + +[qanda.unnumbered] +Existe-t-il des instructions centrales sur la manière de traiter les logiciels open source dans l'administration fédérale?:: +Oui, le secteur TNI de la Chancellerie fédérale met à disposition une documentation complète à cet effet. ++ +Il convient de noter que ces aides constituent une recommandation TIC et non une prescription contraignante. ++ +Lien vers les aides OSS + +Comment publier les développements internes d'une autorité fédérale réalisés dans le cadre de collaborations? Comment traiter les droits existants?:: +Lors du développement de logiciels, [.underline]#le droit d'auteur naît auprès des personnes physiques# qui ont développé le code source. ++ +Si la personne qui développe est liée par un contrat de travail, les développements appartiennent à l'employeur (art. 332 CO). ++ +Dans les contrats avec des prestataires externes, il est donc important de délimiter clairement les nouveaux développements et de convenir de la cession ou du transfert contractuel du droit d'auteur. Enfin, pour les développements internes communs, les parties concernées doivent s'accorder sur la licence open source du code source sous laquelle le logiciel est publié en tant que projet open source autonome. ++ +Publier sous une licence open source ne signifie pas renoncer au droit d'auteur: celui-ci reste auprès des titulaires respectifs. ++ +Ce n'est que sur la base de leur droit d'auteur qu'ils peuvent se défendre juridiquement contre des violations de licence ou accorder, parallèlement aux licences OSS, des licences plus étendues. ++ +Les [.underline]#droits originaux# devraient donc, si possible, toujours revenir à la Confédération pour les nouveaux développements ou les développements ultérieurs. Pour les autres participants, il convient d'utiliser des [.underline]#Contributor Licence Agreements# (CLA) ou un Developer Certificate of Origin (DCO). Des instructions à ce sujet figurent dans link:em002-3.pdf[Em002-3 Guide des licences OSS], link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source] et link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +Les modifications doivent-elles être publiées?:: +Selon l'art. 9 LMETA: oui, si elles ont été développées après le 1^er^ janvier 2024. ++ +Cela devrait toutefois se faire de manière à en tirer également un bénéfice. Le document link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source] informe sur le processus. + +Quand la publication est-elle «suffisante» au sens de la LMETA?:: +L'art. 9 LMETA n'est pas précis à cet égard et laisse une grande marge de manœuvre. Le code source doit être accessible au public. ++ +Les exigences de la loi sont par exemple déjà satisfaites par la simple publication du code source sous forme de fichier zip sur un site web. ++ +Pour en tirer un bénéfice, notamment par la publication de la documentation, etc., cela devrait se faire dans un dépôt de code selon les bonnes pratiques. Des informations à ce sujet figurent dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +À l'avenir, les bénéficiaires de prestations prescriront-ils aux fournisseurs de prestations la manière de publier le logiciel et d'en assurer la qualité?:: +Les règles de chaque autorité fédérale s'appliquent aussi bien aux fournisseurs qu'aux bénéficiaires de prestations. ++ +Il est toutefois judicieux d'intégrer les aides correspondantes aux endroits appropriés dans les processus et les quality gates existants. ++ +Sur la base de son expérience de développement, le fournisseur de prestations peut faire des propositions à ses bénéficiaires de prestations et traiter cela de manière uniforme (comme le processus de développement est traité de manière uniforme). + +=== Choix de la licence + +[qanda.unnumbered] +Sous quelle licence open source un logiciel doit-il être développé?:: +Il n'existe pas de prescriptions strictes quant au choix de la licence, pour autant que les conditions de licence des composants logiciels utilisés dans le logiciel à développer soient respectées. ++ +Pour les développements entièrement nouveaux, il convient de choisir un type de licence permettant une base large et durable pour les développements ultérieurs. ++ +Il est important à cet égard que la licence concernée soit largement acceptée dans la communauté de développeurs pertinente. ++ +*L'utilisation de l'AGPL (avec copyleft) et de la MIT est donc recommandée.* ++ +Ces deux licences représentent en quelque sorte les deux extrêmes du spectre des licences. ++ +L'AGPL, avec un copyleft très fort, impose durablement le principe «public money – public code». En cas de développements ultérieurs, notamment de solutions propriétaires, cela s'atténue en direction de la LGPL. ++ +La MIT est en revanche une licence très libérale, où presque tout est possible. ++ +Ces deux licences couvrent l'ensemble du spectre. Si, pour les licences permissives, on attache une importance particulière à ne pas mentionner la Confédération, la BSD-3 est à préférer à la MIT. ++ +Pour un choix plus détaillé des licences, nous renvoyons à link:em002-3.pdf[Em002-3 Guide des licences OSS]. + +=== Critères de qualité pour les logiciels open source + +[qanda.unnumbered] +Les logiciels open source doivent-ils satisfaire à certains critères de qualité?:: +En règle générale, tous les critères de qualité applicables à n'importe quel autre logiciel s'appliquent également. L'open source rend avant tout tout plus transparent. Pour respecter la licence, les critères d'une «bonne» publication et les éventuelles règles de la communauté, quelques points supplémentaires sont nécessaires. Ils sont présentés dans link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle analyse et préparation OSS] et link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle communauté OSS]. + +Quelles exigences sont prévues pour les quality gates?:: +Aucune prescription centrale n'est prévue. Les règles de l'autorité fédérale (unité administrative) qui développe le logiciel sont déterminantes. ++ +Hormis les exigences générales, il n'existe pas d'exigences particulières concernant la qualité des logiciels open source. HERMES sera toutefois mis à jour pour tenir compte de l'art. 9 LMETA. ++ +La publication est la manière dont l'administration fédérale se présente au public. Si cela n'est pas fait avec soin et professionnalisme, l'image publique d'une autorité fédérale peut rapidement en pâtir. + +Comment les directives de développement sont-elles réglées?:: +Hormis les exigences générales figurant dans les aides, il n'existe pas de prescriptions particulières concernant le développement de logiciels open source. Des indications figurent dans link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle analyse et préparation OSS] et link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +Les logiciels open source doivent-ils être publiés à un endroit précis?:: +La Confédération n'exploite actuellement pas de dépôt central propre. Les autorités fédérales sont donc en principe libres quant au lieu de publication. Comme de nombreuses autorités fédérales utilisent déjà GitHub, cette plateforme est actuellement le choix privilégié. Il existe en outre un compte GitHub central (swiss) qui peut être utilisé. ++ +GitHub – swiss/index: un aperçu des organisations de dépôts actuelles. ++ +C'est le cas en particulier lorsqu'une autorité fédérale ne dispose pas encore d'un compte GitHub («organisation») ou n'utilise pas d'autre plateforme telle que GitLab ou BitBucket. ++ +Veuillez vous adresser à l'unité compétente du secteur TNI (opensource@bk.admin.ch) pour vérifier si une publication via le compte GitHub central (swiss) est judicieuse et possible. ++ +Les autorités fédérales devraient dans tous les cas conserver une copie locale du code. Il est également conseillé que chaque autorité fédérale dispose d'une stratégie correspondante et de règles internes correspondantes. ++ +D'autres recommandations figurent dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +=== Documentation + +[qanda.unnumbered] +Quelles exigences de documentation s'appliquent à la publication de logiciels open source?:: +Les aides mises à disposition par le secteur TNI de la Chancellerie fédérale informent sur les exigences légales; voir les aides OSS. ++ +Il est recommandé de remplir les listes de contrôle OSS et de les conserver de manière centralisée dans chaque autorité fédérale (unité administrative). + +=== Contributions de l'administration fédérale à des projets + +[qanda.unnumbered] +Une unité administrative peut-elle et doit-elle contribuer du code à un projet «upstream», et satisfait-elle ainsi aux exigences de l'art. 9 LMETA?:: +* Si les projets sont open source, l'art. 9 LMETA est satisfait. Les projets doivent toutefois aussi rester open source. À défaut, le code doit être publié à nouveau. +* Les contributions upstream ont l'avantage que la maintenance a lieu dans le projet upstream et que le bénéfice pour la communauté est maximisé. ++ +Les inconvénients suivants existent: moins de contrôle et d'influence; il faut éventuellement signer un CLA ou un DCO (voir link:em002-4.pdf[Em002-4] chapitre 3.3). Les contributions n'apparaissent en outre pas dans le publiccode.yml ni dans les répertoires de la Confédération. Un tout autre avantage est qu'avec de telles contributions, les développeurs continuent d'évoluer au sein de l'écosystème. +* Tant que les risques et la charge restent maîtrisables (contenu du CLA, collecte du code), les contributions upstream sont à saluer. +* La licence du projet upstream s'applique alors à la contribution. Cela correspond à la procédure décrite dans link:em002-3.pdf[Em002-3]. +* *Les forks de projets upstream sont à éviter:* toute la charge de maintenance et de mise à jour incombe alors à l'autorité fédérale. Un fork insuffisamment entretenu représente en outre un risque de sécurité. Le bénéfice pour la communauté est quasi nul. +* Les contributions à des projets upstream devraient en principe être appréciées positivement et activement discutées par les responsables de projet des autorités fédérales. +* Si le projet upstream appartient à l'administration fédérale et qu'il s'agit de contributions de tiers, link:em002-7.pdf[Em002-7] chapitre 9 apporte une aide. + +=== Support + +[qanda.unnumbered] +L'autorité fédérale est-elle tenue d'assurer le support des logiciels publiés?:: +Non, mais elle peut le faire si elle le souhaite. ++ +Selon l'art. 9, al. 5 et 6, LMETA, elle peut également percevoir des émoluments pour le support. + +Comment une autorité doit-elle procéder si elle souhaite facturer le support?:: +Pour des raisons de ressources, cela ne fait pas partie du projet actuel de mise à disposition d'aides. Si nécessaire, cela pourrait être intégré aux aides dans une étape ultérieure. Pour l'instant, chaque autorité fédérale règle cela elle-même. (Voir aussi link:em002-4.pdf[Em002-4 Guide des communautés OSS]) + +== Aides + +=== Instructions + +[qanda.unnumbered] +Existe-t-il des instructions centrales sur le travail avec des logiciels open source dans l'administration fédérale?:: +Oui, le secteur TNI de la Chancellerie fédérale met à disposition une documentation complète à cet effet dans le cadre de link:em002.pdf[Em002 Directives stratégiques pour les logiciels open source dans l'administration fédérale]. ++ +Les logiciels open source sont traités de manière générale dans link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale]. La publication au sens de l'art. 9 LMETA est traitée dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. + +=== Listes de contrôle + +[qanda.unnumbered] +Les aides comprennent-elles également des listes de contrôle pour la publication de logiciels open source?:: +Oui, le secteur TNI de la Chancellerie fédérale met les listes de contrôle suivantes à libre disposition: ++ +-- +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Liste de contrôle évaluation préalable OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle analyse et préparation OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Liste de contrôle validation et publication OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle communauté OSS] + +Voir également la *liste de contrôle relative à l'exception générale selon l'art. 9 LMETA* [BBL-CL] de l'OFCL. +-- + +=== Questions de sécurité + +[qanda.unnumbered] +Existe-t-il des risques de sécurité propres aux logiciels open source?:: +Dans ce contexte, on mentionne par exemple les attaques sur la chaîne d'approvisionnement, les vulnérabilités zero-day et les attaques par typosquatting. ++ +Ces questions de sécurité doivent être prises en compte pour les logiciels open source et leur acquisition, mais aussi de manière générale pour le développement de logiciels et l'acquisition de logiciels commerciaux. Elles peuvent tout au plus être quelque peu amplifiées si le projet OSS utilisé a manqué de rigueur lors de l'intégration de bibliothèques et de conteneurs. ++ +À moyen terme, une stratégie générale est nécessaire pour atténuer ces risques (via le NCSC/OFCS). Si nécessaire, des sources sûres pour les conteneurs et les bibliothèques doivent être mises à disposition. ++ +De manière générale, toutes les personnes responsables dans l'environnement informatique doivent connaître ces vecteurs d'attaque possibles. Les tentatives possibles comprennent: ++ +* Attaques sur la chaîne d'approvisionnement: `XZ_Utils_backdoor` (https://en.wikipedia.org/wiki/XZ_Utils_backdoor), Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/) +* Vulnérabilités zero-day: Log4Shell (https://www.ibm.com/de-de/think/topics/log4j) +* Typosquatting: https://en.wikipedia.org/wiki/Typosquatting + +La publication du code source augmente-t-elle le risque d'une copie malveillante d'une application? (p. ex. une application d'hameçonnage ou une fausse application):: +Non. Retenir le code source n'offre aucune protection efficace contre les fausses applications et est de surcroît incompatible avec l'art. 9 LMETA, qui établit le principe de l'open source pour l'administration fédérale. ++ +Le risque qu'un tiers crée une application visuellement identique pour collecter des données existe indépendamment de la publication du code source. Comme les systèmes de design de la Confédération sont publiquement accessibles, l'apparence d'une application peut être reproduite par un attaquant sans accès au code source. Les applications peuvent en outre être décompilées afin d'extraire des éléments tels que des logos de la version publiée. ++ +La sécurité et la confiance sont donc assurées non par l'obscurité, mais par la vérification et la sécurité cryptographique: ++ +-- +* *Signatures numériques:* les applications officielles doivent être signées cryptographiquement, ce qui garantit techniquement qu'une application est un original non modifié de la Confédération. Le système d'exploitation du smartphone vérifie cette signature. +* *Vérification par les magasins d'applications:* les magasins d'applications d'Apple et de Google proposent des procédures permettant de vérifier que les éditeurs sont des organes étatiques officiels. Google, par exemple, désigne explicitement les applications de la Chancellerie fédérale (ChF) comme des applications gouvernementales, ce qui donne aux utilisateurs confiance dans leur authenticité. +* *Builds reproductibles:* grâce à des builds indépendants et reproductibles, il est possible de démontrer techniquement que le code source publié correspond exactement à l'application disponible dans le magasin. + +Une exception générale pour des motifs de sécurité au sens de l'art. 9 LMETA n'est donc pas applicable aux applications. + +[.underline]#Recommandation:# + +Plutôt que de retenir le code source, l'accent devrait être mis sur les processus des magasins d'applications et sur la surveillance. Les canaux officiels doivent être tenus à jour et les fausses applications signalées sans délai afin d'être supprimées par les exploitants des plateformes (Apple et Google). +-- + +Est-il judicieux que les services demandeurs au sein de l'administration fédérale se regroupent pour acquérir des logiciels open source?:: +Oui, absolument. Cela peut se faire directement et de manière informelle entre unités administratives. ++ +Le problème est plutôt que les unités administratives connaissent mal les besoins des autres. ++ +Une solution pourrait consister à ce que les unités administratives tiennent une liste «most wanted» d'outils (ou de bibliothèques) open source à développer ou à mettre à disposition et qu'elles partagent cette liste. ++ +Une telle liste gérée de manière centralisée pourrait aussi aider à mieux analyser le besoin en composants open source et à mieux évaluer le degré de maturité de l'unité administrative. En fin de compte, un dépôt d'artefacts serait judicieux. ++ +La tenue d'une telle liste serait alors la tâche d'un OSPO, si un tel bureau était introduit. Au mieux, cela pourrait aussi se faire via Administration numérique suisse pour l'ensemble de la structure fédérale. + +== Questions juridiques + +=== Utilisation de l'anglais + +[qanda.unnumbered] +La Confédération peut-elle utiliser des licences dans leur langue originale, l'anglais?:: +Selon l'art. 9, al. 4, LMETA, il convient d'utiliser dans la mesure du possible et lorsque cela est judicieux des textes de licence établis au niveau international. ++ +Insister sur des licences OSS en langue allemande réduirait largement à néant le but de l'art. 9, al. 4, LMETA, car il existe très peu de textes de licence établis au niveau international pour lesquels une version dans l'une des langues officielles de la Suisse (allemand, français et italien selon l'art. 70, al. 1, Cst.) est reconnue comme déterminante pour l'interprétation. ++ +Cette situation est comparable à celle des filières en anglais dans les hautes écoles telles que l'EPFZ, où l'anglais est admis comme langue d'enseignement – sous réserve des trois conditions de l'art. 36 de la Constitution fédérale (commentaire saint-gallois de la Constitution fédérale, 4^e^ éd. 2023, art. 70 N 29; il faut donc une base légale, un intérêt public et la proportionnalité pour que l'anglais soit admis). ++ +Sur cette base, l'art. 9, al. 4, LMETA doit être interprété comme constituant la base légale de l'utilisation de licences en anglais, les licences internationales étant majoritairement rédigées en anglais. La disposition doit donc se référer à celles-ci. ++ +L'intérêt public de l'art. 9 LMETA réside notamment dans l'échange avec les communautés de développeurs concernées.footnote:[FF 2022 804, p. 66] Dans le secteur informatique, ces communautés sont typiquement internationales et utilisent l'anglais comme langue de travail. Limiter les licences à celles en langue allemande rendrait à tout le moins difficile, voire impossible, la coopération avec les communautés internationales, car un logiciel ainsi licencié ne serait guère utilisé au niveau international. Cela irait également à l'encontre du but visé par l'art. 9 LMETA. ++ +De plus, les licences OSS établies au niveau international sont par définition valables dans le monde entier. Le législateur entendait manifestement permettre l'utilisation internationale des logiciels publiés. Limiter les publications OSS aux licences en langue allemande restreindrait fortement l'utilisabilité internationale des logiciels publiés. ++ +Par ailleurs, l'anglais est solidement établi comme langue standard dans la sphère commerciale du secteur informatique, dont font également partie les publications OSS. L'utilisation de licences en anglais constitue donc une restriction raisonnable et proportionnée des droits des partenaires contractuels. De plus, les licences en anglais sont à la fois appropriées et nécessaires pour atteindre les objectifs visés. + +=== Exclusion de responsabilité + +[qanda.unnumbered] +La plupart des licences OSS contiennent des clauses d'exclusion de responsabilité. Est-ce suffisant ou des mesures supplémentaires sont-elles nécessaires? Qu'en est-il des logiciels défectueux? (en tenant compte de la loi sur la responsabilité):: +Les licences applicables excluent la responsabilité pour négligence légère. *La responsabilité ne peut être exclue pour négligence grave ou acte intentionnel.* Les risques de responsabilité pratiques sont toutefois minimes. ++ +Diffuser un logiciel modifié sous une licence incompatible avec celle du logiciel d'origine (par exemple sous une licence MIT sans copyleft alors que le code initialement utilisé était sous licence GPL avec copyleft) viole la licence d'origine. En l'absence de protection de la bonne foi en droit de la propriété intellectuelle, cela ne permet ni aux autres utilisateurs d'utiliser soudainement le logiciel d'origine sous la nouvelle licence, ni ne crée d'obligation exécutoire de proposer la nouvelle licence aux conditions de la licence d'origine. La seule conséquence est la violation de la licence d'origine, pouvant entraîner des prétentions en dommages-intérêts (analogie de licence) contre une autorité fédérale. ++ +Ce risque peut toutefois être maîtrisé par un contrôle systématique conformément aux guides, comme cela est aujourd'hui la norme dans l'industrie du logiciel. Concrètement, la mise sous licence exige l'établissement d'une nomenclature de tous les composants logiciels préexistants intégrés dans le nouveau logiciel, qui doit être strictement respectée lors de la mise sous licence. ++ +Lorsque des droits de tiers existent, l'art. 9, al. 1, LMETA n'exige de toute façon pas la publication du logiciel (ou éventuellement uniquement de ses parties nouvellement écrites; cela devrait être clarifié dans les guides). ++ +Selon l'art. 11 de la loi sur la responsabilité, la responsabilité de la Confédération relève du droit civil lorsqu'elle agit comme sujet de droit civil. C'est le cas selon l'art. 9, al. 2, LMETA; une responsabilité supplémentaire fondée sur la loi sur la responsabilité est par conséquent exclue. + +=== Logiciels permissifs + +[qanda.unnumbered] +Si un logiciel repose sur une bibliothèque ou un composant de programme publié sous une licence permissive, le logiciel principal (sans la bibliothèque) peut-il être publié sous une licence non permissive?:: +Oui, cela ne pose pas de problème. Voir les indications données dans le guide link:em002-3.pdf[Em002-3]. + +=== Dispositions de licence + +[qanda.unnumbered] +Un logiciel peut-il être utilisé par plusieurs offices? Quelles dispositions de licence s'appliquent au sein de l'administration fédérale? L'administration fédérale est-elle considérée comme un groupe de sociétés? (Cela concerne les logiciels open source de tiers non modifiés.):: +La diffusion de logiciels sous licences permissives ne pose généralement pas de problème. ++ +Avec les licences copyleft, la question se pose toutefois de savoir si la diffusion au sein de l'administration fédérale centrale ou décentralisée déclenche des obligations de copyleft et risque ainsi de compromettre la confidentialité des développements propres à la Confédération. Lors de la remise à des institutions de l'administration fédérale décentralisée dotées de leur propre personnalité juridique, c'est effectivement le cas, alors que cela ne s'applique pas au sein de l'administration fédérale centrale, tous les départements agissant sous la même personnalité juridique. ++ +Les sociétés d'un groupe sont juridiquement indépendantes mais restent sous le contrôle économique de la société mère. La doctrine juridique considère que la remise de code sous licence copyleft à une société du groupe déclenche des obligations de copyleft. Comme les sociétés d'un groupe reçoivent souvent des logiciels open source lors du développement de logiciels, elles ont besoin de leur propre droit d'utilisation; la remise à une société du groupe déclenche donc des obligations de copyleft. ++ +En revanche, la remise au sein de l'administration fédérale centrale ne déclenche pas d'obligations de copyleft. Pour l'administration fédérale décentralisée, où existent des personnalités juridiques distinctes, ce qui précède s'applique: la remise déclenche des obligations de copyleft, et le logiciel doit être proposé sous forme de code source aux mêmes conditions de licence que le logiciel d'origine. Une instruction interdisant de remettre le logiciel à des tiers violerait la licence et pourrait également contrevenir à l'art. 9 LMETA. + +=== Rapport entre la LTrans et la LMETA + +[qanda.unnumbered] +Quel est le rapport entre la loi sur la transparence (LTrans) et la LMETA?:: +Selon l'art. 6 LTrans, les documents officiels doivent être remis. Est un document officiel au sens de l'art. 5, al. 1, LTrans toute information enregistrée sur un quelconque support, qui se trouve en possession d'une autorité et qui concerne l'accomplissement d'une tâche publique. Les logiciels open source relèvent en principe de la LTrans. La LTrans s'applique lorsqu'une personne demande à un département ou à un office le code source pour son propre usage. L'office doit divulguer le code source à la personne concernée, à moins que des exceptions au sens de l'art. 7 LTrans ne s'appliquent. Si l'office refuse de divulguer le code source, la procédure LTrans s'applique. Le cas est différent lorsque quelqu'un exige que l'office publie le code source sur son site web. La procédure ne suit alors pas la LTrans mais la LMETA. Comme la LMETA ne prévoit elle-même aucune procédure, le droit administratif général doit suffire. Celui-ci offre soit la possibilité d'une décision, soit celle d'un acte matériel, soit celle d'une décision en constatation de l'office concerné. Cette décision peut ensuite être contestée devant le Tribunal administratif fédéral. ++ +Si des obligations de divulgation pour des logiciels développés par une autorité fédérale sont concevables au sens de la LTrans (lorsque les conditions correspondantes sont remplies), il convient de noter que la divulgation d'un logiciel selon la LTrans n'accorde pas automatiquement une licence OSS. L'utilisation d'un logiciel divulgué selon la LTrans se limite donc aux buts fixés par la LTrans, tels que la consultation du code ou son exécution à des fins d'observation. La divulgation selon la LTrans ne comprend toutefois pas de licence pour une utilisation régulière du logiciel ni comme base pour le développement d'autres logiciels (détails dans T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern [trad.: Conditions juridiques de l'utilisation de logiciels open source dans l'administration publique, en particulier dans le canton de Berne], Zurich 2017, https://carlgrossmann.com/?ddownload=11748, N 393 ss). ++ +La décision de mettre un logiciel sous licence OSS, même s'il relève de la LTrans, continue de suivre la LMETA; il n'existe toujours pas de droit à l'octroi d'une licence. ++ +Il est important de noter que les logiciels développés avant le 1^er^ janvier 2024, bien que non soumis à la LMETA, doivent néanmoins être remis conformément à la LTrans. + +=== OSS et protection des données + +[qanda.unnumbered] +Les données personnelles des développeurs peuvent-elles être publiées sans autre? Quels aspects de la protection des données faut-il prendre en compte?:: +Du point de vue de la protection des données, la publication de données personnelles (p. ex. noms ou adresses électroniques) est problématique si les collaborateurs n'y ont pas consenti au préalable. En effet, la communication de données personnelles peut en principe être évitée par la pseudonymisation ou l'anonymisation des entrées du dépôt, ce qui serait requis selon le principe de la minimisation des données et de la proportionnalité (art. 6, al. 2, LPD). ++ +Un tel consentement devrait toutefois être généralement facile à obtenir, les collaborateurs ayant souvent intérêt à montrer publiquement leurs compétences (ainsi Poledna/Schlauri/Schweizer, N 68, avec renvois). Le consentement peut aussi être implicite par l'utilisation des noms dans le dépôt, du moins en l'absence d'instruction contraire de l'employeur. ++ +Il est néanmoins conseillé de régler dans les contrats la responsabilité du fournisseur pour les données personnelles de ses collaborateurs. + +== Généralités + +[qanda.unnumbered] +Le fait qu'un logiciel open source soit utilisé à des fins commerciales ou non commerciales joue-t-il un rôle?:: +Les licences open source ne distinguent généralement pas entre utilisation commerciale et non commerciale. Un logiciel open source peut donc être utilisé à toutes fins, y compris pour des applications commerciales. Les fournisseurs commerciaux tentent souvent d'intégrer des composants open source dans des produits propriétaires. Cela n'est admissible que si les composants open source ne sont pas placés sous une licence à effet copyleft (voir aussi link:em002-3.pdf[Em002-3 Guide des licences OSS]). + +Existe-t-il des restrictions quant aux organisations admises pour les communautés?:: +En fin de compte, chaque cas doit toujours être examiné individuellement: qui se trouve derrière, et quels engagements sont pris? ++ +Tant qu'aucun argent ne circule et qu'aucun engagement formel n'est pris, la situation est relativement simple et sans problème. ++ +Des affiliations à des associations sont possibles, tout comme une collaboration informelle. ++ +Il est possible de déléguer des affiliations à eOperations ou à des organisations similaires. ++ +Voir aussi link:em002-4.pdf[Em002-4 Guide des communautés OSS], chapitre 3.1 + +Quel est le rapport entre la norme ISO 5230 et les guides?:: +La norme ISO 5230:2020 a été examinée et prise en compte lors de l'élaboration des guides. La liste ci-après présente les exigences de la norme et la manière dont elles ont été traitées dans les guides: ++ +-- +*3.1 Programme foundation* + +* Les «link:em002.pdf[Em002 Directives stratégiques pour les logiciels open source dans l'administration fédérale]» et les stratégies référencées constituent le cadre. La mise en œuvre incombe aux départements et offices concernés. + +*3.2 Relevant tasks defined and supported* + +* Le guide «link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]» et les listes de contrôle définissent des tâches concrètes pour la publication. Il n'existe actuellement pas d'organe central au sein de l'administration fédérale. + +*3.3 Open source content review and approval* + +* Le processus de publication est décrit dans l'aide «link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]». Celle-ci renvoie également à l'existence d'une Software Bill of Materials (SBOM). +* L'aide «link:em002-3.pdf[Em002-3 Guide des licences OSS]» informe de manière complète sur la mise sous licence. + +*3.4 Compliance artifact creation and delivery* + +* Le processus de publication est décrit dans l'aide «link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]». Celle-ci renvoie également à l'existence d'une Software Bill of Materials (SBOM). +* La mise en œuvre n'est pas décrite plus en détail et a lieu au sein des départements ou des offices. + +*3.5 Understanding open source community engagements* + +* L'aide «link:em002-4.pdf[Em002-4 Guide des communautés OSS]» décrit comment mettre en place et entretenir une communauté. Un concept doit être défini et mis en œuvre pour chaque projet. + +*3.6 Adherence to the specification requirements* + +* Le chapitre final énonce des exigences pour les organisations ou projets souhaitant confirmer explicitement le respect des exigences OpenChain. +-- ++ +La norme ISO esquisse d'autres domaines de responsabilité d'un Open Source Programme Office (OSPO) qui ne sont pas couverts par les guides. + +== Annexe + +=== Abréviations + +[horizontal] +include::partials/abbreviations.fr.adoc[tags=abbr-em002-6] + +=== Glossaire + +D'autres termes figurent dans TERMDAT, la https://www.bk.admin.ch/bk/fr/home/dokumentation/sprachen/termdat.html[banque de données terminologique] de l'administration fédérale. + +include::partials/glossary.fr.adoc[tags=gloss-em002-6] +endif::[] + +ifeval::["{lang}" == "it"] +NOTE: Il presente documento è una bozza in continua evoluzione e fa parte degli ausili destinati a sostenere l'Amministrazione federale nella pubblicazione di codice open source. Per ulteriori informazioni si veda il {url-repo}/tree/main[README]. + +== Situazione iniziale e scopo + +=== Situazione iniziale e scopo delle FAQ + +In relazione agli ausili per la pubblicazione di software open source emergono regolarmente alcune domande. La raccolta seguente risponde alle domande più frequenti e intende migliorare la comprensione di singoli temi e aspetti. + +=== Struttura e articolazione + +Le FAQ sono articolate per tema: + +[start=2] +. Concetti e definizioni +. Ruoli e responsabilità +. Processo +. Ausili +. Questioni giuridiche +. Aspetti generali + +== Concetti e definizioni + +=== Software open source + +[qanda.unnumbered] +Che cosa si intende per software open source?:: +Questo concetto è definito in link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale]. + +=== Software e licenze + +[qanda.unnumbered] +Che cosa si intende per software?:: +Questo concetto è definito in link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale]. Per le licenze si veda link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. + +Che cosa si intende per licenze?:: +Si tratta qui di licenze software. Ulteriori informazioni sono riportate in link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. + +I modelli di IA sviluppati internamente vanno considerati software e quindi sottoposti ai requisiti giuridici dell'art. 9 LMeCA? E che dire dei dati di addestramento?:: +Open source indica software il cui codice sorgente è liberamente accessibile e modificabile a condizioni minime. Vi rientrano anche i modelli di IA addestrati internamente (compresi algoritmo, procedura di addestramento e codice). ++ +I modelli di IA sono addestrati sulla base di dati, eventualmente Open (Government) Data. Per Open Data si intendono insiemi di dati che possono essere liberamente utilizzati, condivisi ed elaborati. I modelli di IA i cui dati di addestramento si basano su Open (Government) Data sono considerati software ai sensi della LMeCA e devono pertanto essere pubblicati anch'essi. ++ +Se tuttavia i dati di addestramento contengono dati personali (degni di particolare protezione) o informazioni classificate, si può rinunciare alla pubblicazione per motivi di sicurezza. Nel pubblicare un modello di IA come open source, i dati di addestramento non devono necessariamente essere pubblicati; ciò corrisponde tuttavia allo spirito dell'open source ed è vivamente raccomandato dalla comunità open source. Per ulteriori informazioni sull'IA rinviamo alla Rete di competenze per l'intelligenza artificiale (CNAI).footnote:[https://cnai.swiss/[CNAI] nonché art. 10 LMeCA] + +Gli strumenti con funzionalità di IA generativa (p. es. GitHub Copilot) devono essere verificati prima dell'impiego affinché non siano violati diritti di proprietà intellettuale di terzi o della Confederazione?:: +I contenuti generati da un modello di IA non possono essere protetti dal diritto d'autore, poiché manca un'attività creativa. I contenuti generati dall'IA che attingono a opere protette di terzi possono tuttavia violare i diritti di tali terzi. Inoltre, poiché gli output dell'IA sono notoriamente inaffidabili, dovrebbero essere utilizzati solo dopo un attento esame caso per caso. ++ +Gli operatori di sistemi di IA possono inoltre riservarsi nelle loro condizioni d'uso il diritto di utilizzare gli input per addestrare il sistema. Ciò può a sua volta comportare che gli input o parti di essi vengano mostrati a terzi. Laddove ciò non possa essere escluso, occorre garantire che gli input non violino i diritti della Confederazione o di terzi. ++ +Si raccomanda di esaminare e autorizzare singolarmente l'impiego di strumenti di IA. Gli strumenti non autorizzati non possono essere utilizzati, ma i collaboratori possono chiedere l'autorizzazione di uno strumento. Spesso è opportuno disciplinare tali questioni contrattualmente con il fornitore; alcuni fornitori offrono anche abbonamenti speciali con cui rispettano i diritti di terzi, p. es. DeepL. + +=== Base legale nella LMeCA + +[qanda.unnumbered] +Qual è la base legale per la pubblicazione di software open source?:: +Secondo l'art. 9 LMeCAfootnote:[RS 172.019] le autorità federali dell'Amministrazione federale centrale devono divulgare il codice sorgente del software che sviluppano o fanno sviluppare. Ogni persona può utilizzare, sviluppare ulteriormente o modificare il software senza dover pagare emolumenti. ++ +Si può rinunciare alla pubblicazione del codice sorgente soltanto per diritti di terzi o per motivi di sicurezza. ++ +Ulteriori informazioni sono riportate in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +Che cosa si intende per motivi di sicurezza?:: +I motivi di sicurezza ammessi dall'art. 9 LMeCA e il modo di trattarli sono definiti nel capitolo 3.2 di link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +Che cosa sono i diritti di terzi?:: +I diritti di terzi ai sensi dell'art. 9 LMeCA e il modo di trattarli sono definiti nel capitolo 3.3 di link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +Le eccezioni possono essere limitate nel tempo?:: +I motivi che giustificano un'eccezione ai sensi dell'art. 9 LMeCA (diritti di terzi e motivi di sicurezza) possono venir meno con il tempo. ++ +In tal caso il codice sorgente del software deve essere pubblicato. + +Quali conseguenze giuridiche occorre considerare in caso di violazione dell'art. 9 LMeCA?:: +Vi sono due tipi di violazioni: ++ +-- +. sono violati diritti di terzi; +. un'autorità federale rifiuta di pubblicare software open source (p. es. invocando motivi di sicurezza non fondati). + +Risposta al punto 1: + +Si tratterà regolarmente di una violazione contrattuale e potranno essere fatte valere pretese di risarcimento danni secondo il Codice delle obbligazioni. + +Risposta al punto 2: + +Ciò non ha conseguenze dirette. Se un terzo vuole poter utilizzare il codice sorgente di un'autorità federale, deve presentare all'autorità competente una domanda fondata sulla legge sulla trasparenza (LTras; RS 152.3). + +In presenza di un forte interesse può essere opportuno valutare una pubblicazione nell'interesse di entrambe le parti. Non sussiste alcun obbligo di pubblicazione retroattiva, che resta però possibile su base volontaria. +-- + +In caso di danno causato da software open source possono essere fatte valere pretese di responsabilità?:: +In linea di principio la responsabilità dovrebbe essere esclusa nei contratti. Non è tuttavia possibile escludere la responsabilità per negligenza grave o colpa. In tali casi un'autorità federale potrebbe essere chiamata a rispondere secondo la legge sulla responsabilità (LResp; RS 170.32). + +A partire da quale data il software deve essere pubblicato?:: +Secondo l'art. 9 cpv. 1 LMeCA deve essere pubblicato il software sviluppato dopo il 1° gennaio 2024. ++ +Per il software sviluppato prima del 1° gennaio 2024 la pubblicazione dovrebbe essere valutata quando sono previste modifiche rilevanti. ++ +In presenza di un interesse considerevole da parte di terzi, anche il software esistente può essere pubblicato su base volontaria (eventualmente con partecipazione ai costi). In tal caso occorre valutare anche una community (cfr. link:em002-4.pdf[Em002-4]). ++ +Per gli script di piccole dimensioni la pubblicazione non è di regola l'opzione migliore. Possono esistere repository di strumenti che passano poi insieme attraverso il processo di pubblicazione. ++ +Per le unità amministrative dell'Amministrazione federale decentralizzata sottoposte alla LMeCA l'obbligo di pubblicazione vige dal 1° maggio 2025. Sono previste eccezioni all'obbligo di pubblicazione per il software sviluppato senza fondi federali e per il software di ricerca (art. 3 cpv. 1 OMeCA). + +È possibile esigere la pubblicazione retroattiva di software sviluppato prima del 1° gennaio 2024?:: +La legge non prevede una pubblicazione retroattiva. ++ +Inoltre, i contratti conclusi prima del 1° gennaio 2024 possono contenere diritti di terzi che ostano a una pubblicazione. ++ +Se è prevista una nuova versione principale (major secondo il Semantic Versioningfootnote:[https://it.wikipedia.org/wiki/Controllo_versione[Controllo versione -- Wikipedia]]), occorre valutare la pubblicazione dell'intero software. In caso contrario dovrebbe essere pubblicato almeno il codice sorgente delle nuove funzionalità. + +Su quale base un terzo dovrebbe chiedere la pubblicazione del codice sorgente?:: +Un terzo dovrebbe presentare all'autorità competente una domanda fondata sulla LTras. + +== Ruoli e responsabilità + +=== Ruolo della Cancelleria federale + +[qanda.unnumbered] +Chi mette a disposizione gli ausili di base per l'attuazione?:: +Il settore TDT della Cancelleria federale mette a disposizione delle autorità federali ausili sotto forma di raccolta di documenti relativa a Em002. Ne fanno parte le direttive strategiche e altre guide pratiche, comprese le FAQ, nonché liste di controllo volte a garantire un'attuazione conforme al diritto. ++ +Gli ausili OSS sono aggiornati dal settore TDT. + +La Cancelleria federale è competente per la concessione di eccezioni (p. es. per motivi di sicurezza)?:: +Non esiste un organo centrale che decide sulle eccezioni all'obbligo di pubblicazione di cui all'art. 9 LMeCA. Ogni autorità federale è responsabile della propria attuazione conforme al diritto. ++ +I dipartimenti possono emanare disposizioni. ++ +La lista di controllo per l'eccezione generale secondo l'art. 9 LMeCA [BBL-CL] dell'UFCL dovrebbe essere compilata. + +=== Ruolo delle unità amministrative + +[qanda.unnumbered] +Chi è responsabile dell'attuazione operativa delle pubblicazioni OSS?:: +Ogni autorità federale (p. es. ufficio, unità amministrativa) che sviluppa o fa sviluppare software è responsabile in proprio dell'intero processo di pubblicazione. ++ +I dipartimenti possono stabilire disposizioni vincolanti e meccanismi di controllo nel loro ambito di competenza, p. es. per evitare danni reputazionali. ++ +Si raccomanda di designare per ogni ufficio federale una persona responsabile dell'OSS, p. es. il responsabile informatico (IM), l'enterprise architect, l'ISBO o il DSBO, al fine di garantire processi uniformi ed efficienti. In assenza di una designazione, la responsabilità di un'attuazione conforme spetta di regola alla direzione dell'ufficio. ++ +Tale persona potrebbe poi essere consultata anche per la concessione di eccezioni all'obbligo di pubblicazione. + +=== Collaborazione con fornitori terzi + +[qanda.unnumbered] +Come vanno pubblicati gli sviluppi interni di un'autorità federale?:: +Il diritto d'autore sorge in capo alle persone fisiche che hanno sviluppato il codice sorgente, ma di regola viene trasferito al datore di lavoro tramite il contratto di lavoro. Nei contratti con fornitori di servizi esterni è importante delimitare chiaramente i nuovi sviluppi e convenire la cessione o il trasferimento contrattuale del diritto d'autore. Infine, per gli sviluppi interni comuni le parti coinvolte devono accordarsi sulla licenza open source del codice sorgente con cui il software è pubblicato come progetto open source autonomo. La pubblicazione sotto una licenza open source non significa rinunciare al diritto d'autore: questo resta in capo ai rispettivi titolari. Solo sulla base del loro diritto d'autore essi possono difendersi giuridicamente contro violazioni di licenza o concedere, parallelamente alle licenze OSS, licenze più estese. + +=== Comunicazione di dati personali + +[qanda.unnumbered] +A quali condizioni possono essere pubblicati dati personali, ad esempio degli sviluppatori, nell'ambito di software open source?:: +Non esiste una regola generale al riguardo. La decisione spetta al progetto. ++ +In ogni caso vanno rispettate le disposizioni applicabili in materia di protezione dei dati. Secondo l'articolo 36 capoverso 1 LPD gli organi federali possono comunicare dati personali solo se dispongono di una base legale. ++ +L'articolo 36 capoverso 2 LPD prevede tra l'altro le seguenti eccezioni: ++ +(b) la persona interessata ha acconsentito alla comunicazione; ++ +(e) la persona interessata ha reso i suoi dati accessibili a chiunque e non si è opposta espressamente al trattamento. ++ +Nella maggior parte dei casi è opportuno ottenere preventivamente il consenso delle persone interessate, che di regola hanno esse stesse interesse a che il loro lavoro sia visibile pubblicamente. Se il consenso non viene dato o se altri motivi si oppongono alla pubblicazione, il codice sorgente dovrebbe essere pubblicato senza dati personali, con il solo riferimento all'autorità federale interessata. ++ +Tale consenso dovrebbe essere ottenuto da fornitori e collaboratori nell'ambito dei processi di acquisto e di assunzione. + +=== Acquisti + +[qanda.unnumbered] +Dove trovo la documentazione relativa agli acquisti di software open source?:: +Con la versione 2.0 è stato messo a disposizione l'ausilio link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e software open source]. ++ +Il Centro di competenza per gli acquisti pubblici della Confederazione (CCAP) ha pubblicato un nuovo promemoria intitolato Acquisto di software e art. 9 LMeCA [KBB-MB] nonché due documenti «Criteri tipo – acquisto LMeCA e open source.docx» e «Testi contrattuali tipo – sviluppo di software.docx». ++ +Ulteriori risorse sono disponibili sulla piattaforma di apprendimento e di modelli degli acquisti pubblici (www.perimap.admin.ch). ++ +Ulteriore sostegno è disponibile sull'intranet dell'UFCL (accessibile solo sulla rete della Confederazione) con la direttiva Open source negli acquisti [BBL-WL] e la lista di controllo per l'eccezione generale secondo l'art. 9 LMeCA [BBL-CL]. ++ +Le relative informazioni si trovano sulle pagine intranet dell'UFCL (disponibili solo all'interno della Confederazione). ++ +Link: cassetta degli attrezzi dell'UFCL per gli acquisti informatici + +== Processo + +=== Istruzioni + +[qanda.unnumbered] +Esistono istruzioni centrali su come trattare il software open source nell'Amministrazione federale?:: +Sì, il settore TDT della Cancelleria federale mette a disposizione una documentazione completa a tale scopo. ++ +Va osservato che questi ausili costituiscono una raccomandazione TIC e non una prescrizione vincolante. ++ +Link agli ausili OSS + +Come vanno pubblicati gli sviluppi interni di un'autorità federale realizzati nell'ambito di collaborazioni? Come vanno trattati i diritti esistenti?:: +Nello sviluppo di software [.underline]#il diritto d'autore sorge in capo alle persone fisiche# che hanno sviluppato il codice sorgente. ++ +Se la persona che sviluppa è legata da un rapporto di lavoro, gli sviluppi appartengono al datore di lavoro (art. 332 CO). ++ +Nei contratti con fornitori di servizi esterni è quindi importante delimitare chiaramente i nuovi sviluppi e convenire la cessione o il trasferimento contrattuale del diritto d'autore. Infine, per gli sviluppi interni comuni le parti coinvolte devono accordarsi sulla licenza open source del codice sorgente con cui il software è pubblicato come progetto open source autonomo. ++ +La pubblicazione sotto una licenza open source non significa rinunciare al diritto d'autore: questo resta in capo ai rispettivi titolari. ++ +Solo sulla base del loro diritto d'autore essi possono difendersi giuridicamente contro violazioni di licenza o concedere, parallelamente alle licenze OSS, licenze più estese. ++ +I [.underline]#diritti originari# dovrebbero pertanto, se possibile, spettare sempre alla Confederazione per i nuovi sviluppi o gli sviluppi successivi. Per gli altri partecipanti occorre utilizzare [.underline]#Contributor Licence Agreement# (CLA) o un Developer Certificate of Origin (DCO). Le relative istruzioni sono riportate in link:em002-3.pdf[Em002-3 Guida alle licenze OSS], link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source] e link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +Le modifiche devono essere pubblicate?:: +Secondo l'art. 9 LMeCA: sì, se sono state sviluppate dopo il 1° gennaio 2024. ++ +Ciò dovrebbe però avvenire in modo da generare anche un beneficio. Il documento link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source] informa sul processo. + +Quando la pubblicazione è «sufficiente» ai sensi della LMeCA?:: +L'art. 9 LMeCA non è specifico al riguardo e lascia un ampio margine di manovra. Il codice sorgente deve essere accessibile al pubblico. ++ +I requisiti della legge sono per esempio già soddisfatti con la semplice pubblicazione del codice sorgente in un file zip su un sito web. ++ +Per ottenere un beneficio, anche mediante la pubblicazione della documentazione ecc., ciò dovrebbe avvenire in un repository di codice secondo le buone pratiche. Informazioni al riguardo sono riportate in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +In futuro i beneficiari di prestazioni prescriveranno ai fornitori di prestazioni come pubblicare il software e come garantirne la qualità?:: +Sia per i fornitori sia per i beneficiari di prestazioni valgono le regole della rispettiva autorità federale. ++ +È tuttavia opportuno integrare i relativi ausili nei punti adeguati dei processi e dei quality gate esistenti. ++ +Sulla base della propria esperienza di sviluppo, il fornitore di prestazioni può formulare proposte per i suoi beneficiari di prestazioni e trattare la questione in modo uniforme (così come il processo di sviluppo è trattato in modo uniforme). + +=== Scelta della licenza + +[qanda.unnumbered] +Sotto quale licenza open source deve essere sviluppato il software?:: +Non esistono prescrizioni rigide sulla scelta della licenza, purché siano rispettate le condizioni di licenza dei componenti software utilizzati nel software da sviluppare. ++ +Per gli sviluppi completamente nuovi occorre scegliere un tipo di licenza che consenta una base ampia e sostenibile per gli sviluppi successivi. ++ +A tal fine è importante che la licenza in questione sia ampiamente accettata nella community di sviluppatori pertinente. ++ +*Si raccomanda pertanto l'impiego di AGPL (con copyleft) e MIT.* ++ +Queste due licenze rappresentano, per così dire, i due estremi dello spettro delle licenze. ++ +L'AGPL, con un copyleft molto forte, impone durevolmente il principio «public money – public code». In caso di sviluppi successivi, segnatamente di soluzioni proprietarie, ciò si attenua in direzione della LGPL. ++ +La MIT è invece una licenza molto liberale, con la quale è possibile quasi tutto. ++ +Le due licenze coprono l'intero spettro. Se, nel caso di licenze permissive, si attribuisce particolare importanza al fatto di non menzionare la Confederazione, la BSD-3 è da preferire alla MIT. ++ +Per una scelta più dettagliata delle licenze rinviamo a link:em002-3.pdf[Em002-3 Guida alle licenze OSS]. + +=== Criteri di qualità per il software open source + +[qanda.unnumbered] +Il software open source deve soddisfare determinati criteri di qualità?:: +Di regola valgono tutti i criteri di qualità applicabili a qualsiasi altro software. L'open source rende soprattutto tutto più trasparente. Per rispettare la licenza, i criteri di una «buona» pubblicazione e le eventuali regole della community sono necessari alcuni punti supplementari. Questi sono illustrati in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo analisi e preparazione OSS] e link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo community OSS]. + +Quali requisiti sono previsti per i quality gate?:: +Non sono previste prescrizioni centrali. Sono determinanti le regole dell'autorità federale (unità amministrativa) che sviluppa il software. ++ +A parte i requisiti generali non esistono requisiti particolari per la qualità del software open source. HERMES sarà tuttavia aggiornato in vista dell'art. 9 LMeCA. ++ +La pubblicazione è il modo in cui l'Amministrazione federale si presenta al pubblico. Se ciò non avviene con cura e professionalità, l'immagine pubblica di un'autorità federale può rapidamente risentirne. + +Come sono disciplinate le direttive di sviluppo?:: +A parte i requisiti generali contenuti negli ausili non esistono prescrizioni particolari sullo sviluppo di software open source. Indicazioni sono riportate in link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo analisi e preparazione OSS] e link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +Il software open source deve essere pubblicato in un luogo determinato?:: +Attualmente la Confederazione non gestisce un proprio repository centrale. Le autorità federali sono quindi in linea di principio libere nella scelta del luogo di pubblicazione. Poiché molte autorità federali utilizzano già GitHub, questa piattaforma è attualmente la scelta preferita. Esiste inoltre un account GitHub centrale (swiss) che può essere utilizzato. ++ +GitHub – swiss/index: una panoramica delle attuali organizzazioni di repository. ++ +Ciò vale in particolare quando un'autorità federale non dispone ancora di un account GitHub («organizzazione») o non utilizza un'altra piattaforma come GitLab o BitBucket. ++ +Si prega di rivolgersi all'unità competente del settore TDT (opensource@bk.admin.ch) per verificare se una pubblicazione tramite l'account GitHub centrale (swiss) sia opportuna e possibile. ++ +Le autorità federali dovrebbero in ogni caso conservare una copia locale del codice. È inoltre opportuno che ogni autorità federale disponga di una strategia corrispondente e di corrispondenti regole interne. ++ +Ulteriori raccomandazioni sono riportate in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +=== Documentazione + +[qanda.unnumbered] +Quali requisiti di documentazione valgono per la pubblicazione di software open source?:: +Gli ausili messi a disposizione dal settore TDT della Cancelleria federale informano sui requisiti giuridici; cfr. gli ausili OSS. ++ +Si raccomanda di compilare le liste di controllo OSS e di archiviarle centralmente in ogni autorità federale (unità amministrativa). + +=== Contributi dell'Amministrazione federale a progetti + +[qanda.unnumbered] +Un'unità amministrativa può e deve contribuire con codice a un progetto «upstream» e soddisfa in tal modo i requisiti dell'art. 9 LMeCA?:: +* Se i progetti sono open source, l'art. 9 LMeCA è soddisfatto. I progetti devono però anche rimanere open source. In caso contrario il codice deve essere pubblicato nuovamente. +* I contributi upstream hanno il vantaggio che la manutenzione avviene nel progetto upstream e che il beneficio per la community è massimizzato. ++ +Esistono i seguenti svantaggi: minore controllo e influenza; può essere necessario firmare un CLA o un DCO (cfr. link:em002-4.pdf[Em002-4] capitolo 3.3). I contributi non compaiono inoltre nel publiccode.yml né negli elenchi della Confederazione. Un vantaggio del tutto diverso è che con tali contributi gli sviluppatori continuano a crescere all'interno dell'ecosistema. +* Finché i rischi e l'onere restano gestibili (contenuto del CLA, raccolta del codice), i contributi upstream sono da accogliere favorevolmente. +* Al contributo si applica allora la licenza del progetto upstream. Ciò corrisponde alla procedura descritta in link:em002-3.pdf[Em002-3]. +* *I fork di progetti upstream sono da evitare:* l'intero onere di manutenzione e aggiornamento ricade allora sull'autorità federale. Un fork curato in modo insufficiente rappresenta inoltre un rischio per la sicurezza. Per la community il beneficio è pressoché nullo. +* I contributi a progetti upstream dovrebbero essere in linea di principio valutati positivamente e discussi attivamente dai responsabili di progetto delle autorità federali. +* Se il progetto upstream appartiene all'Amministrazione federale e si tratta di contributi di terzi, link:em002-7.pdf[Em002-7] capitolo 9 fornisce ulteriori indicazioni. + +=== Supporto + +[qanda.unnumbered] +L'autorità federale è tenuta a fornire supporto per il software pubblicato?:: +No, ma può farlo se lo desidera. ++ +Secondo l'art. 9 cpv. 5 e 6 LMeCA può anche riscuotere emolumenti per il supporto. + +Come deve procedere un'autorità che intende fatturare il supporto?:: +Per motivi di risorse ciò non fa parte dell'attuale progetto di messa a disposizione di ausili. Se necessario, questo aspetto potrebbe essere integrato negli ausili in una tappa successiva. Per ora ogni autorità federale lo disciplina autonomamente. (Cfr. anche link:em002-4.pdf[Em002-4 Guida alle community OSS]) + +== Ausili + +=== Istruzioni + +[qanda.unnumbered] +Esistono istruzioni centrali sull'impiego di software open source nell'Amministrazione federale?:: +Sì, il settore TDT della Cancelleria federale mette a disposizione una documentazione completa nell'ambito di link:em002.pdf[Em002 Direttive strategiche per il software open source nell'Amministrazione federale]. ++ +Il software open source è trattato in generale in link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale]. La pubblicazione ai sensi dell'art. 9 LMeCA è trattata in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. + +=== Liste di controllo + +[qanda.unnumbered] +Gli ausili comprendono anche liste di controllo per la pubblicazione di software open source?:: +Sì, il settore TDT della Cancelleria federale mette a libera disposizione le seguenti liste di controllo: ++ +-- +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Lista di controllo valutazione preliminare OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo analisi e preparazione OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Lista di controllo rilascio e pubblicazione OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo community OSS] + +Si veda inoltre la *lista di controllo per l'eccezione generale secondo l'art. 9 LMeCA* [BBL-CL] dell'UFCL. +-- + +=== Questioni di sicurezza + +[qanda.unnumbered] +Esistono rischi di sicurezza specifici del software open source?:: +In questo contesto si citano ad esempio gli attacchi alla catena di fornitura, le vulnerabilità zero-day e gli attacchi di typosquatting. ++ +Tali questioni di sicurezza devono essere considerate per il software open source e i relativi acquisti, ma anche in generale per lo sviluppo di software e per l'acquisto di software commerciale. Al più possono risultare leggermente amplificate se il progetto OSS impiegato è stato poco accurato nell'integrazione di librerie e container. ++ +A medio termine è necessaria una strategia generale per attenuare questi rischi (tramite l'NCSC/UFCS). Se necessario devono essere messe a disposizione fonti sicure per container e librerie. ++ +In generale tutti i responsabili in ambito informatico devono conoscere questi possibili vettori d'attacco. Possibili tentativi sono: ++ +* Attacchi alla catena di fornitura: `XZ_Utils_backdoor` (https://en.wikipedia.org/wiki/XZ_Utils_backdoor), Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/) +* Vulnerabilità zero-day: Log4Shell (https://www.ibm.com/de-de/think/topics/log4j) +* Typosquatting: https://en.wikipedia.org/wiki/Typosquatting + +La pubblicazione del codice sorgente aumenta il rischio di una copia malevola di un'app? (p. es. un'app di phishing o un'app falsa):: +No. Trattenere il codice sorgente non offre alcuna protezione efficace contro le app false ed è inoltre incompatibile con l'articolo 9 LMeCA, che sancisce il principio dell'open source per l'Amministrazione federale. ++ +Il rischio che un terzo realizzi un'app visivamente identica per raccogliere dati sussiste indipendentemente dalla pubblicazione del codice sorgente. Poiché i sistemi di design della Confederazione sono pubblicamente disponibili, l'aspetto di un'app può essere riprodotto da un aggressore senza accesso al codice sorgente. Le app possono inoltre essere decompilate per estrarre elementi come i loghi dalla versione pubblicata. ++ +Sicurezza e fiducia sono pertanto garantite non dalla segretezza, bensì dalla verifica e dalla sicurezza crittografica: ++ +-- +* *Firme digitali:* le app ufficiali devono essere firmate crittograficamente; ciò garantisce tecnicamente che un'app sia un originale non modificato della Confederazione. Il sistema operativo dello smartphone verifica questa firma. +* *Verifica negli app store:* gli app store di Apple e Google offrono procedure per verificare che gli editori siano organi statali ufficiali. Google, ad esempio, contrassegna esplicitamente le app della Cancelleria federale (CaF) come app governative, dando agli utenti fiducia nella loro autenticità. +* *Build riproducibili:* mediante build indipendenti e riproducibili è possibile dimostrare tecnicamente che il codice sorgente pubblicato corrisponde esattamente all'app disponibile nello store. + +Un'eccezione generale per motivi di sicurezza ai sensi dell'articolo 9 LMeCA non è pertanto applicabile alle app. + +[.underline]#Raccomandazione:# + +Anziché trattenere il codice sorgente, l'attenzione dovrebbe concentrarsi sui processi degli app store e sul monitoraggio. I canali ufficiali devono essere mantenuti aggiornati e le app false segnalate tempestivamente affinché siano rimosse dai gestori delle piattaforme (Apple e Google). +-- + +È opportuno che i servizi richiedenti all'interno dell'Amministrazione federale si uniscano per acquistare software open source?:: +Sì, senz'altro. Ciò può avvenire direttamente e in modo informale tra unità amministrative. ++ +Il problema è piuttosto che le unità amministrative conoscono poco le esigenze reciproche. ++ +Una soluzione potrebbe consistere nel fatto che le unità amministrative tengano un elenco «most wanted» di strumenti (o librerie) open source da sviluppare o mettere a disposizione e condividano tale elenco. ++ +Un elenco gestito centralmente potrebbe anche aiutare ad analizzare meglio il fabbisogno di componenti open source e a valutare meglio il grado di maturità dell'unità amministrativa. In definitiva sarebbe opportuno un artifact repository. ++ +La tenuta di un simile elenco sarebbe poi compito di un OSPO, qualora ne venisse introdotto uno. Nel migliore dei casi ciò potrebbe avvenire anche tramite Amministrazione digitale svizzera per l'intera struttura federale. + +== Questioni giuridiche + +=== Impiego dell'inglese + +[qanda.unnumbered] +La Confederazione può utilizzare licenze nella lingua originale inglese?:: +Secondo l'art. 9 cpv. 4 LMeCA occorre utilizzare, ove possibile e opportuno, testi di licenza affermati a livello internazionale. ++ +Insistere su licenze OSS in lingua tedesca vanificherebbe in larga misura lo scopo dell'art. 9 cpv. 4 LMeCA, poiché esistono pochissimi testi di licenza affermati a livello internazionale per i quali una versione in una delle lingue ufficiali della Svizzera (tedesco, francese e italiano secondo l'art. 70 cpv. 1 Cost.) sia riconosciuta come determinante per l'interpretazione. ++ +Questa situazione è analoga a quella dei corsi di studio in lingua inglese presso scuole universitarie come il PF di Zurigo, dove l'inglese è ammesso come lingua d'insegnamento – fatte salve le tre condizioni dell'articolo 36 della Costituzione federale (Commentario di San Gallo alla Costituzione federale, 4a ed. 2023, art. 70 N 29; devono cioè sussistere una base legale, un interesse pubblico e la proporzionalità affinché l'inglese sia ammesso). ++ +Su questa base l'art. 9 cpv. 4 LMeCA va interpretato nel senso che costituisce la base legale per l'impiego di licenze in lingua inglese, poiché le licenze internazionali sono redatte prevalentemente in inglese. La disposizione deve pertanto riferirsi a queste. ++ +L'interesse pubblico di cui all'art. 9 LMeCA risiede tra l'altro nello scambio con le rispettive community di sviluppatori.footnote:[FF 2022 804, pag. 66] Nel settore informatico tali community sono tipicamente internazionali e utilizzano l'inglese come lingua di lavoro. Limitare le licenze a quelle in lingua tedesca renderebbe quantomeno difficile, se non impossibile, la cooperazione con le community internazionali, poiché un software così licenziato non sarebbe praticamente utilizzato a livello internazionale. Ciò contrasterebbe anche con lo scopo dell'articolo 9 LMeCA. ++ +Inoltre, le licenze OSS affermate a livello internazionale sono per definizione valide in tutto il mondo. Il legislatore intendeva evidentemente rendere possibile l'utilizzo internazionale del software pubblicato. Limitare le pubblicazioni OSS a licenze in lingua tedesca restringerebbe fortemente l'utilizzabilità internazionale del software pubblicato. ++ +A ciò si aggiunge che l'inglese è saldamente affermato come lingua standard nella sfera commerciale del settore informatico, di cui fanno parte anche le pubblicazioni OSS. L'impiego di licenze in lingua inglese rappresenta pertanto una limitazione ragionevole e proporzionata dei diritti dei partner contrattuali. Le licenze in lingua inglese sono inoltre idonee e necessarie per raggiungere gli obiettivi perseguiti. + +=== Esclusione della responsabilità + +[qanda.unnumbered] +La maggior parte delle licenze OSS contiene clausole di esclusione della responsabilità. È sufficiente o sono necessarie misure supplementari? Come ci si comporta in caso di software difettoso? (tenendo conto della legge sulla responsabilità):: +Le licenze applicabili escludono la responsabilità per negligenza lieve. *La responsabilità non può essere esclusa per negligenza grave o dolo.* I rischi pratici di responsabilità sono tuttavia minimi. ++ +Distribuire software modificato sotto una licenza incompatibile con quella del software originario (ad esempio sotto licenza MIT senza copyleft laddove il codice originariamente utilizzato era sotto licenza GPL con copyleft) viola la licenza originaria. In assenza di tutela della buona fede nel diritto della proprietà intellettuale, ciò non consente né agli altri utenti di utilizzare improvvisamente il software originario sotto la nuova licenza, né fa sorgere un obbligo azionabile di offrire la nuova licenza alle condizioni della licenza originaria. L'unica conseguenza è la violazione della licenza originaria, che può comportare pretese di risarcimento danni (analogia di licenza) nei confronti di un'autorità federale. ++ +Questo rischio può tuttavia essere gestito mediante una verifica sistematica secondo le guide, come è oggi prassi standard nell'industria del software. Concretamente la concessione di licenze richiede la creazione di una distinta di tutti i componenti software preesistenti confluiti nel nuovo software, che deve essere rigorosamente rispettata al momento della concessione delle licenze. ++ +Laddove esistano diritti di terzi, l'art. 9 cpv. 1 LMeCA non richiede comunque la pubblicazione del software (o eventualmente solo delle sue parti di nuova scrittura; ciò andrebbe chiarito nelle guide). ++ +Secondo l'articolo 11 della legge sulla responsabilità, la responsabilità della Confederazione è retta dal diritto civile quando essa agisce come soggetto di diritto civile. Questo è il caso secondo l'art. 9 cpv. 2 LMeCA; una responsabilità supplementare secondo la legge sulla responsabilità è di conseguenza esclusa. + +=== Software permissivo + +[qanda.unnumbered] +Se un software si basa su una libreria o su un componente di programma pubblicato sotto una licenza permissiva, il software principale (senza la libreria) può essere pubblicato sotto una licenza non permissiva?:: +Sì, ciò non pone problemi. Si vedano le indicazioni contenute nella guida link:em002-3.pdf[Em002-3]. + +=== Disposizioni di licenza + +[qanda.unnumbered] +Un software può essere utilizzato da più uffici? Quali disposizioni di licenza valgono all'interno dell'Amministrazione federale? L'Amministrazione federale è considerata un gruppo di società? (Ciò riguarda il software open source di terzi non modificato.):: +La distribuzione di software sotto licenze permissive è di regola priva di problemi. ++ +Con le licenze copyleft si pone tuttavia la questione se la distribuzione all'interno dell'Amministrazione federale centrale o decentralizzata faccia scattare obblighi di copyleft e rischi così di compromettere la riservatezza degli sviluppi propri della Confederazione. Nella consegna a istituzioni dell'Amministrazione federale decentralizzata dotate di propria personalità giuridica ciò è effettivamente il caso, mentre non vale all'interno dell'Amministrazione federale centrale, poiché tutti i dipartimenti agiscono sotto la stessa personalità giuridica. ++ +Le società di un gruppo sono giuridicamente indipendenti ma restano sotto il controllo economico della società madre. La dottrina giuridica considera la consegna di codice licenziato con copyleft a una società del gruppo come fatto che fa scattare obblighi di copyleft. Poiché le società di un gruppo ricevono spesso software open source nello sviluppo di software, esse necessitano di un proprio diritto d'uso; la consegna a una società del gruppo fa quindi scattare obblighi di copyleft. ++ +Per contro, la consegna all'interno dell'Amministrazione federale centrale non fa scattare obblighi di copyleft. Per l'Amministrazione federale decentralizzata, dove esistono personalità giuridiche distinte, vale quanto sopra: la consegna fa scattare obblighi di copyleft e il software deve essere offerto in forma di codice sorgente alle stesse condizioni di licenza del software originario. Un'istruzione di non consegnare il software a terzi violerebbe la licenza e potrebbe contravvenire anche all'art. 9 LMeCA. + +=== Rapporto tra LTras e LMeCA + +[qanda.unnumbered] +In quale rapporto stanno la legge sulla trasparenza (LTras) e la LMeCA?:: +Secondo l'art. 6 LTras i documenti ufficiali devono essere consegnati. È documento ufficiale ai sensi dell'art. 5 cpv. 1 LTras ogni informazione registrata su un supporto qualsiasi, che si trova in possesso di un'autorità e concerne l'adempimento di un compito pubblico. Il software open source rientra in linea di principio nella LTras. La LTras si applica quando una persona chiede a un dipartimento o a un ufficio il codice sorgente per uso proprio. L'ufficio deve divulgare il codice sorgente alla persona interessata, salvo che si applichino le eccezioni di cui all'articolo 7 LTras. Se l'ufficio rifiuta di divulgare il codice sorgente, si applica la procedura LTras. Diverso è il caso in cui qualcuno esiga che l'ufficio pubblichi il codice sorgente sul proprio sito web. In tal caso la procedura non segue la LTras bensì la LMeCA. Poiché la LMeCA non prevede essa stessa una procedura, deve bastare il diritto amministrativo generale. Questo offre la possibilità di una decisione, di un atto materiale o di una decisione di accertamento generale dell'ufficio interessato. Tale decisione può poi essere impugnata dinanzi al Tribunale amministrativo federale. ++ +Se da un lato sono ipotizzabili obblighi di divulgazione per software sviluppato da un'autorità federale ai sensi della LTras (qualora siano soddisfatte le relative condizioni), va osservato che la divulgazione di software secondo la LTras non concede automaticamente una licenza OSS. L'utilizzo di software divulgato secondo la LTras si limita pertanto agli scopi fissati dalla LTras, come la consultazione del codice o la sua esecuzione a fini di osservazione. La divulgazione secondo la LTras non comprende tuttavia una licenza per l'utilizzo regolare del software o come base per lo sviluppo di ulteriore software (dettagli in T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern [trad.: Presupposti giuridici dell'utilizzo di software open source nell'amministrazione pubblica, in particolare nel Cantone di Berna], Zurigo 2017, https://carlgrossmann.com/?ddownload=11748, N 393 segg.). ++ +La decisione di licenziare un software come OSS, anche se esso rientra nella LTras, continua a seguire la LMeCA; non sussiste tuttora alcun diritto al rilascio di una licenza. ++ +È importante notare che il software sviluppato prima del 1° gennaio 2024, pur non essendo sottoposto alla LMeCA, deve comunque essere consegnato secondo la LTras. + +=== OSS e protezione dei dati + +[qanda.unnumbered] +I dati personali degli sviluppatori possono essere pubblicati senz'altro? Quali aspetti della protezione dei dati vanno considerati?:: +Dal punto di vista della protezione dei dati la pubblicazione di dati personali (p. es. nomi o indirizzi e-mail) è problematica se i collaboratori non vi hanno preventivamente acconsentito. La comunicazione di dati personali può infatti essere evitata in linea di principio mediante la pseudonimizzazione o l'anonimizzazione delle voci del repository, il che sarebbe richiesto dal principio della minimizzazione dei dati e della proporzionalità (art. 6 cpv. 2 LPD). ++ +Tale consenso dovrebbe tuttavia essere di regola facile da ottenere, poiché i collaboratori hanno spesso interesse a mostrare pubblicamente le proprie capacità (così Poledna/Schlauri/Schweizer, N 68, con rinvii). Il consenso può anche essere implicito attraverso l'uso dei nomi nel repository, quantomeno in assenza di un'istruzione contraria del datore di lavoro. ++ +Ciononostante è opportuno disciplinare nei contratti la responsabilità del fornitore per i dati personali dei suoi collaboratori. + +== Aspetti generali + +[qanda.unnumbered] +È rilevante che il software open source sia utilizzato a scopo commerciale o non commerciale?:: +Le licenze open source di regola non distinguono tra utilizzo commerciale e non commerciale. Il software open source può quindi essere utilizzato per qualsiasi scopo, comprese le applicazioni commerciali. I fornitori commerciali cercano spesso di integrare componenti open source in prodotti proprietari. Ciò è ammesso solo se i componenti open source non sono soggetti a una licenza con effetto copyleft (cfr. anche link:em002-3.pdf[Em002-3 Guida alle licenze OSS]). + +Esistono restrizioni sulle organizzazioni ammesse per le community?:: +In definitiva occorre sempre esaminare il singolo caso: chi c'è dietro e quali impegni vengono assunti? ++ +Finché non circola denaro e non vengono assunti impegni formali, la situazione è relativamente semplice e priva di problemi. ++ +Sono possibili affiliazioni ad associazioni, così come una collaborazione informale. ++ +È possibile delegare le affiliazioni a eOperations o a organizzazioni analoghe. ++ +Cfr. anche link:em002-4.pdf[Em002-4 Guida alle community OSS], capitolo 3.1 + +In che rapporto sta la norma ISO 5230 con le guide?:: +La norma ISO 5230:2020 è stata esaminata e considerata nell'elaborazione delle guide. L'elenco seguente riporta i requisiti della norma e il modo in cui sono stati affrontati nelle guide: ++ +-- +*3.1 Programme foundation* + +* Le «link:em002.pdf[Em002 Direttive strategiche per il software open source nell'Amministrazione federale]» e le strategie richiamate costituiscono il quadro di riferimento. L'attuazione compete ai rispettivi dipartimenti e uffici. + +*3.2 Relevant tasks defined and supported* + +* La guida «link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]» e le liste di controllo definiscono compiti concreti per la pubblicazione. Attualmente non esiste un organo centrale nell'Amministrazione federale. + +*3.3 Open source content review and approval* + +* Il processo di pubblicazione è descritto nell'ausilio «link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]». Esso rinvia anche all'esistenza di una Software Bill of Materials (SBOM). +* L'ausilio «link:em002-3.pdf[Em002-3 Guida alle licenze OSS]» informa in modo completo sulla concessione di licenze. + +*3.4 Compliance artifact creation and delivery* + +* Il processo di pubblicazione è descritto nell'ausilio «link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]». Esso rinvia anche all'esistenza di una Software Bill of Materials (SBOM). +* L'attuazione non è descritta più in dettaglio e avviene nei dipartimenti o negli uffici. + +*3.5 Understanding open source community engagements* + +* L'ausilio «link:em002-4.pdf[Em002-4 Guida alle community OSS]» descrive come costituire e curare una community. Per ogni progetto occorre definire e attuare un concetto. + +*3.6 Adherence to the specification requirements* + +* Il capitolo finale enuncia requisiti per le organizzazioni o i progetti che intendono confermare esplicitamente il rispetto dei requisiti OpenChain. +-- ++ +La norma ISO delinea ulteriori ambiti di responsabilità di un Open Source Programme Office (OSPO) che non sono coperti dalle guide. + +== Allegato + +=== Abbreviazioni + +[horizontal] +include::partials/abbreviations.it.adoc[tags=abbr-em002-6] + +=== Glossario + +Ulteriori termini sono reperibili in TERMDAT, la https://www.bk.admin.ch/bk/it/home/dokumentation/sprachen/termdat.html[banca dati terminologica] dell'Amministrazione federale. + +include::partials/glossary.it.adoc[tags=gloss-em002-6] +endif::[] + +ifeval::["{lang}" == "rm"] +NOTE: 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 {url-repo}/tree/main[README]. + +== Situaziun da partenza e intent + +=== Situaziun da partenza ed intent da las FAQ + +En connex cun ils meds per la publicaziun da software open source cumparan regularmain dumondas. La collecziun suandanta responda las dumondas las pli frequentas e duai meglierar la chapientscha per singuls temas ed aspects. + +=== Structura e classificaziun + +Las FAQ èn structuradas tenor temas: + +[start=2] +. Noziuns e definiziuns +. Rols e responsabladads +. Process +. Meds +. Dumondas giuridicas +. Generalitads + +== Noziuns e definiziuns + +=== Software open source + +[qanda.unnumbered] +Tge vegn chapì sut software open source?:: +Quai vegn definì en link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala]. + +=== Software e licenzas + +[qanda.unnumbered] +Tge vegn chapì sut software?:: +Quai vegn definì en link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala]. Concernent las licenzas vesair link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. + +Tge vegn chapì sut licenzas?:: +Qua èn manegiadas licenzas da software. Ulteriuras infurmaziuns sa chattan en link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. + +Ston models d'IA sviluppads sezs vegnir considerads sco software ed uschia suttamess a las pretensiuns giuridicas da l'art. 9 EMBAG? E tge vala per las datas d'instrucziun?:: +Open source designescha software, dal qual il code da funtauna è liberamain accessibel e midabel sut cundiziuns minimalas. Da quai fan era part models d'IA instruids sezs (inclus algoritmus, procedura d'instrucziun e code). ++ +Models d'IA vegnan instruids sin la basa da datas, eventualmain da Open (Government) Data. Sco Open Data vegnan designadas collecziuns da datas che dastgan vegnir duvradas, cundivididas ed elavuradas libramain. Models d'IA, da las quals las datas d'instrucziun sa basan sin Open (Government) Data, valan sco software en il senn da la EMBAG e ston perquai era vegnir publitgads. ++ +Sche las datas d'instrucziun cuntegnan dentant datas persunalas (spezialmain degnas da protecziun) u infurmaziuns classifitgadas, po vegnir renunzià a la publicaziun per motivs relevants per la segirezza. Tar la relaschada d'in model d'IA sco open source na ston las datas d'instrucziun betg vegnir publitgadas obligatoriamain; quai correspunda dentant a l'idea open source e vegn recumandà expressivamain da la communitad open source. Per ulteriuras infurmaziuns davart l'IA renviain nus a la rait da cumpetenza per l'intelligenza artifiziala (CNAI).footnote:[https://cnai.swiss/[CNAI] sco era art. 10 EMBAG] + +Ston utensilis cun abilitads d'IA generativa (p.ex. GitHub Copilot) vegnir examinads avant l'utilisaziun, per che nagins dretgs immaterials da terzas persunas u da la Confederaziun na vegnian violads?:: +Cuntegns ch'in model d'IA producescha sez na pon betg vegnir protegids dal dretg d'autur, perquai che manca in'activitad creativa. Cuntegns generads da l'IA che sa basan sin ovras protegidas da terzas persunas pon dentant violar ils dretgs da questas terzas persunas. Perquai ch'ils resultats da l'IA èn ultra da quai notoriamain malsegirs, duessan els vegnir duvrads mo suenter in'examinaziun quità en mintga cas singul. ++ +Ultra da quai pon ils gestiunaris da sistems d'IA sa resalvar en lur cundiziuns d'utilisaziun da duvrar las endataziuns per instruir il sistem. Quai po puspè manar a quai ch'endataziuns u parts da quellas vegnian mussadas a terzas persunas. Nua che quai na po betg vegnir exclus, sto vegnir garantì che las endataziuns na violeschian nagins dretgs da la Confederaziun u da terzas persunas. ++ +I vegn recumandà d'examinar e d'approvar l'utilisaziun d'utensilis d'IA singularmain. Utensilis betg approvads na dastgan betg vegnir duvrads; ils collaboraturs pon dentant dumandar l'approvaziun d'in utensil. Savens è sensa da reglar talas dumondas contractualmain cun il furnitur; tscherts furniturs porschan era abunaments spezials, cun ils quals els respectan ils dretgs da terzas persunas, p.ex. DeepL. + +=== Basa legala en la EMBAG + +[qanda.unnumbered] +Tge è la basa legala per la publicaziun da software open source?:: +Tenor l'art. 9 EMBAGfootnote:[CS 172.019] ston las autoritads federalas da l'administraziun federala centrala publitgar il code da funtauna dal software ch'ellas sviluppan u fan sviluppar. Mintga persuna dastga duvrar, sviluppar vinavant u midar il software senza pajar taxas. ++ +Da la publicaziun dal code da funtauna po mo vegnir desistì pervia da dretgs da terzas persunas u per motivs relevants per la segirezza. ++ +Ulteriuras infurmaziuns sa chattan en link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +Tge èn motivs relevants per la segirezza?:: +Ils motivs relevants per la segirezza permess tenor l'art. 9 EMBAG ed il tractament cun quels vegnan definids en il chapitel 3.2 da link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +Tge èn dretgs da terzas persunas?:: +Dretgs da terzas persunas tenor l'art. 9 EMBAG ed il tractament cun quels vegnan definids en il chapitel 3.3 da link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +Pon excepziuns vegnir limitadas en il temp?:: +Ils motivs per in'excepziun tenor l'art. 9 EMBAG (dretgs da terzas persunas e motivs relevants per la segirezza) pon crudar davent cun il temp. ++ +Sch'i è uschia, sto il code da funtauna dal software vegnir relaschà. + +Tge consequenzas giuridicas ston vegnir resguardadas en cas d'ina violaziun da l'art. 9 EMBAG?:: +I dat dus geners da violaziuns: ++ +-- +. Dretgs da terzas persunas vegnan violads. +. Ina autoritad federala refusa da publitgar software open source (p.ex. cun motivs relevants per la segirezza betg fundads). + +Resposta a 1: + +Regularmain sa tracta quai d'ina violaziun dal contract, e pretensiuns da indemnisaziun pon vegnir fatgas valair tenor il Dretg d'obligaziuns. + +Resposta a 2: + +Quai n'ha nagina consequenza directa. Sch'ina terza persuna vul pudair duvrar il code da funtauna d'ina autoritad federala, sto ella inoltrar in giavisch tenor la Lescha davart la transparenza (LTrans; CS 152.3) tar l'autoritad cumpetenta. + +Sch'i exista in grond interess, po esser sensa dad examinar ina publicaziun en l'interess da omaduas partidas. Ina obligaziun da publitgar retroactivamain n'exista betg, voluntarmain è quai dentant pussaivel. +-- + +Pon vegnir fatgas valair pretensiuns da responsabladad en cas d'in donn chaschunà da software open source?:: +Fundamentalmain duess la responsabladad vegnir excludida en ils contracts. Per negligientscha grava u cumportament culpaivel na po la responsabladad dentant betg vegnir excludida. En tals cas pudess ina autoritad federala vegnir fatga responsabla tenor la Lescha davart la responsabladad (LResp; CS 170.32). + +A partir da tge data sto software vegnir publitgà?:: +Tenor l'art. 9 al. 1 EMBAG sto vegnir publitgà il software ch'è vegnì sviluppà suenter il 1. da schaner 2024. ++ +Tar software sviluppà avant il 1. da schaner 2024 duess ina relaschada vegnir examinada, sche pli grondas midadas stattan avant maun. ++ +Sch'i exista in interess considerabel da terzas persunas, po era software existent vegnir relaschà voluntarmain (eventualmain cun ina participaziun als custs). En quest cas duess era vegnir examinada ina communitad (vesair link:em002-4.pdf[Em002-4]). ++ +Tar scripts pli pitschens n'è la publicaziun per ordinari betg la megldra opziun. I pon exister repositoris per utensilis che passan lura ensemen tras il process da relaschada. ++ +Per unitads administrativas da l'administraziun federala decentralisada che suttastattan a la EMBAG vala l'obligaziun da publitgar dapi il 1. da matg 2025. Excepziuns da l'obligaziun da publitgar existan per software sviluppà senza meds da la Confederaziun e per software da retschertga (art. 3 al. 1 OEMBAG). + +Po vegnir pretendida ina publicaziun retroactiva per software sviluppà avant il 1. da schaner 2024?:: +La lescha na prevesa nagina publicaziun retroactiva. ++ +Ultra da quai pon contracts serrads avant il 1. da schaner 2024 cuntegnair dretgs da terzas persunas che s'opponan ad ina publicaziun. ++ +Sch'ina nova versiun principala stat avant maun (major tenor Semantic Versioningfootnote:[https://en.wikipedia.org/wiki/Version_control[Version control -- Wikipedia]]), duess vegnir examinada ina relaschada da l'entir software. Uschiglio stuess almain il code da funtauna da las novas funcziunalitads vegnir relaschà. + +Sin tge basa stuess ina terza persuna pretender la relaschada dal code da funtauna?:: +Ina terza persuna stuess inoltrar in giavisch tenor la LTrans tar l'autoritad cumpetenta. + +== Rols e responsabladads + +=== Rol da la Chanzlia federala + +[qanda.unnumbered] +Tgi metta a disposiziun ils meds fundamentals per la realisaziun?:: +Il sectur TDT da la Chanzlia federala metta a disposiziun da las autoritads federalas meds sco collecziun da documents tar Em002. Da quai fan part las directivas strategicas ed ulteriuras guidas praticas, inclus las FAQ, sco era glistas da controlla per garantir ina realisaziun conforma al dretg. ++ +Ils meds OSS vegnan actualisads dal sectur TDT. + +È la Chanzlia federala cumpetenta per conceder excepziuns (p.ex. per motivs relevants per la segirezza)?:: +I n'exista nagin post central che decida davart excepziuns da l'obligaziun da publitgar tenor l'art. 9 EMBAG. Mintga autoritad federala è sezza responsabla per sia realisaziun conforma al dretg. ++ +Ils departaments pon relaschar reglamentaziuns. ++ +La glista da controlla per l'excepziun generala tenor l'art. 9 EMBAG [BBL-CL] da l'UFCL duess vegnir emplenida. + +=== Rol da las unitads administrativas + +[qanda.unnumbered] +Tgi è cumpetent per la realisaziun operativa da relaschadas OSS?:: +Mintga autoritad federala (p.ex. uffizi, unitad administrativa) che sviluppa u fa sviluppar software è responsabla sezza per l'entir process da publicaziun. ++ +Ils departaments pon fixar reglamentaziuns liantas e mecanissems da controlla en lur sectur da cumpetenza, p.ex. per evitar donns da reputaziun. ++ +I vegn recumandà da designar per mintga uffizi federal ina persuna responsabla per OSS, p.ex. il respunsabel d'informatica (IM), l'enterprise architect, l'ISBO u il DSBO, per garantir process unitars ed efficients. Sche quai n'è betg fixà, è fundamentalmain la direcziun da l'uffizi responsabla per ina realisaziun conforma al dretg. ++ +Questa persuna pudess lura era vegnir consultada per conceder excepziuns da l'obligaziun da publitgar. + +=== Collavuraziun cun furniturs terzs + +[qanda.unnumbered] +Co ston svilups agens d'ina autoritad federala vegnir publitgads?:: +Il dretg d'autur nascha tar las persunas natiralas respectivas ch'han sviluppà il code da funtauna, vegn dentant per ordinari transferì a la patruna via il contract da lavur. En contracts cun purschiders da prestaziuns externs è impurtant da delimitar cleramain novs svilups e da convegnir la cessiun resp. la transferiziun contractuala dal dretg d'autur. Tar svilups agens cuminaivels ston ils participads a la fin s'accordar davart la licenza open source per il code da funtauna, sut la quala il software vegn publitgà sco project open source independent. La publicaziun sut ina licenza open source na munta betg ina renunzia al dretg d'autur: quel resta tar ils possessurs dals dretgs respectivs. Mo sin la basa da lur dretg d'autur pon els sa defender giuridicamain cunter violaziuns da la licenza u conceder parallelamain a las licenzas OSS licenzas pli vastas. + +=== Communicaziun da datas persunalas + +[qanda.unnumbered] +Sut tge premissas dastgan datas persunalas, per exempel da sviluppaders, vegnir publitgadas en il rom da software open source?:: +I n'exista nagina regla generala per quai. La decisiun sa chatta tar il project. ++ +En mintga cas ston las disposiziuns applitgablas davart la protecziun da datas vegnir observadas. Tenor l'artitgel 36 al. 1 LPD dastgan ils organs federals mo communitgar datas persunalas, sch'els disponan d'ina basa legala per quai. ++ +L'artitgel 36 al. 2 LPD numna tranter auter las suandantas excepziuns: ++ +(b) La persuna pertutgada ha consentì a la communicaziun. ++ +(e) La persuna pertutgada ha rendì accessiblas sias datas a tuts e n'ha betg scumandà expressivamain l'elavuraziun. ++ +En ils pli blers cas è recumandabel da retrair anticipadamain il consentiment da las persunas pertutgadas, perquai che quellas han per ordinari sezzas in interess che lur lavur saja visibla publicamain. Sche il consentiment na vegn betg dà u sch'auters motivs discurran cunter ina publicaziun, duess il code da funtauna vegnir publitgà senza datas persunalas, cun renviar mo a l'autoritad federala pertutgada. ++ +Quest consentiment duess vegnir retratg tar ils furniturs ed ils collaboraturs en il rom dals process d'acquist e d'engaschament. + +=== Acquist + +[qanda.unnumbered] +Nua chatt jau la documentaziun per l'acquist da software open source?:: +Cun la versiun 2.0 è vegnì mess a disposiziun il med link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist e dal software open source]. ++ +Il Center da cumpetenza per l'acquist public da la Confederaziun (CCA) ha publitgà in nov fegl d'infurmaziun cun il titel Acquist da software ed art. 9 EMBAG [KBB-MB] sco era dus documents «Criteris model – acquist EMBAG ed open source.docx» e «Texts contractuals model – svilup da software.docx». ++ +Ulteriurs meds sa chattan sin la plattafurma d'emprender e da models da l'acquist public (www.perimap.admin.ch). ++ +Ulteriur sustegn porscha l'intranet da l'UFCL (accessibel mo en la rait da la Confederaziun) cun la directiva Open source en l'acquist [BBL-WL] e la glista da controlla per l'excepziun generala tenor l'art. 9 EMBAG [BBL-CL]. ++ +Las infurmaziuns correspundentas sa chattan sin las paginas d'intranet da l'UFCL (disponiblas mo entaifer la Confederaziun). ++ +Colliaziuns: chascha d'utensils da l'UFCL per l'acquist d'informatica + +== Process + +=== Instrucziun + +[qanda.unnumbered] +Exista ina instrucziun centrala, co ch'i sto vegnir tractà cun OSS en l'administraziun federala?:: +Gea, il sectur TDT da la Chanzlia federala metta a disposiziun documents cumplessivs per quai. ++ +Da resguardar è che quests meds èn ina recumandaziun TIC e betg ina prescripziun lianta. ++ +Colliaziun als meds OSS + +Co ston svilups agens d'ina autoritad federala vegnir publitgads ch'èn naschids en collavuraziuns? Co sto vegnir tractà cun dretgs existents?:: +Tar il svilup da software [.underline]#nascha il dretg d'autur tar las persunas natiralas respectivas# ch'han sviluppà il code da funtauna. ++ +Sche la persuna che sviluppa è en in rapport da lavur, appartegnan ils svilups a la patruna (art. 332 DO). ++ +Tar contracts cun purschiders da prestaziuns externs è perquai impurtant da delimitar cleramain novs svilups e da convegnir la cessiun resp. la transferiziun contractuala dal dretg d'autur. Tar svilups agens cuminaivels ston ils participads a la fin s'accordar davart la licenza open source per il code da funtauna, sut la quala il software vegn publitgà sco project open source independent. ++ +La publicaziun sut ina licenza open source na munta betg ina renunzia al dretg d'autur: quel resta tar ils possessurs dals dretgs respectivs. ++ +Mo sin la basa da lur dretg d'autur pon els sa defender giuridicamain cunter violaziuns da la licenza u conceder parallelamain a las licenzas OSS licenzas pli vastas. ++ +Ils [.underline]#dretgs originals# duessan perquai tar novs svilups u svilups vinavant adina sa chattar sche pussaivel tar la Confederaziun. Per ulteriurs participants duessan vegnir duvrads [.underline]#Contributor Licence Agreements# (CLA) u in Developer Certificate of Origin (DCO). Instrucziuns per quai sa chattan en link:em002-3.pdf[Em002-3 Guida da licenzas OSS], link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source] e link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +Ston midadas vegnir publitgadas?:: +Tenor l'art. 9 EMBAG: gea, sch'ellas èn vegnidas sviluppadas suenter il 1. da schaner 2024. ++ +Quai duess dentant capitar uschia ch'i naschia era in profit. Il document link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source] infurmescha davart il process. + +Cura è la publicaziun «suffizienta» tenor la EMBAG?:: +L'art. 9 EMBAG n'è betg specific en quest reguard, ed i exista in grond spazi da moviment. Il code da funtauna sto esser accessibel publicamain. ++ +Las pretensiuns da la lescha èn per exempel gia ademplidas, sche il code da funtauna vegn publitgà sco datoteca zip sin ina pagina d'internet. ++ +Per cuntanscher in profit, era tras la publicaziun da la documentaziun etc., duess quai capitar en in repositori da code tenor las megliras praticas. Infurmaziuns davart quai sa chattan en link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +Vegnan ils retratgs da prestaziuns en l'avegnir a prescriver als purschiders da prestaziuns, co che il software sto vegnir publitgà e co che la qualitad sto vegnir garantida?:: +Tant per ils purschiders da prestaziuns sco era per ils retratgs da prestaziuns valan las reglas da la respectiva autoritad federala. ++ +I è dentant sensa d'integrar ils meds correspundents en ils lieus adattads dals process existents e dals quality gates. ++ +Sin la basa da sia experientscha da svilup po il purschider da prestaziuns far propostas per ses retratgs da prestaziuns e tractar quai unitarmain (uschia sco era il process da svilup vegn tractà unitarmain). + +=== Tscherna da la licenza + +[qanda.unnumbered] +Sut tge licenza open source duai software vegnir sviluppà?:: +I n'existan naginas prescripziuns strictas concernent la tscherna da la licenza, uschè ditg che las cundiziuns da licenza da las cumponentas da software duvradas en il software da sviluppar vegnan observadas. ++ +Tar svilups cumplettamain novs duess vegnir tschernì in tip da licenza che pussibilitescha ina basa vasta e persistenta per svilups vinavant. ++ +Per quai è impurtant che la licenza correspundenta saja acceptada vastamain en la communitad da sviluppaders relevanta. ++ +*Recumandada vegn perquai l'utilisaziun da l'AGPL (cun copyleft) e da la MIT.* ++ +Questas duas licenzas represchentan en tscherta moda ils dus extrems dal spectrum da las licenzas. ++ +L'AGPL cun in copyleft fitg ferm realisescha permanentamain il princip «public money – public code». Tar svilups vinavant, numnadamain soluziuns proprietaras, sa flaivlescha quai en direcziun da la LGPL. ++ +La MIT è percunter ina licenza fitg liberala, cun la quala è bunamain tut pussaivel. ++ +Las duas licenzas cuvran l'entir spectrum. Sch'i vegn dà spezialmain paisa tar licenzas permissivas a betg numnar la Confederaziun, è la BSD-3 da preferir a la MIT. ++ +Per ina tscherna pli detagliada da las licenzas renviain nus a link:em002-3.pdf[Em002-3 Guida da licenzas OSS]. + +=== Criteris da qualitad per OSS + +[qanda.unnumbered] +Sto software open source ademplir tscherts criteris da qualitad?:: +Per ordinari valan tut ils criteris da qualitad che valan era per mintg'auter software. Open source renda avant tut tut pli transparent. Per observar la licenza, ils criteris per ina «buna» relaschada ed eventualas reglas da la communitad èn necessaris insaquants puncts supplementars. Quels èn inditgads en link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla analisa e preparaziun OSS] ed en link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla communitad OSS]. + +Tge pretensiuns èn previsas per ils quality gates?:: +I n'èn previsas naginas prescripziuns centralas. Decisivas èn las reglas da l'autoritad federala (unitad administrativa) che sviluppa il software. ++ +Ultra da las pretensiuns generalas n'existan naginas pretensiuns spezialas concernent la qualitad da l'OSS. HERMES vegn dentant actualisà en vista a l'art. 9 EMBAG. ++ +La publicaziun è la cumparsa da l'administraziun federala en il public. Sche quai na capita betg quità e professiunalmain, po la reputaziun publica d'ina autoritad federala spert patir. + +Co vegnan reglads ils princips da svilup?:: +Ultra da las pretensiuns generalas en ils meds n'existan naginas prescripziuns spezialas concernent il svilup da software open source. Indicaziuns sa chattan en link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla analisa e preparaziun OSS] ed en link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +Sto OSS vegnir publitgà en in lieu determinà?:: +La Confederaziun na maina actualmain nagin agen repositori central. Las autoritads federalas èn perquai fundamentalmain libras en lur publicaziun. Perquai che bleras autoritads federalas utiliseschan gia GitHub, è questa plattafurma actualmain la tscherna preferida. I exista ultra da quai in conto GitHub central (swiss) che po vegnir duvrà. ++ +GitHub – swiss/index: ina survista da las organisaziuns da repositoris actualas. ++ +Quai vala en spezial, sch'ina autoritad federala n'ha anc nagin conto GitHub («organisaziun») u sch'ella n'utilisescha betg ina autra plattafurma sco GitLab u BitBucket. ++ +S'adressai p.pl. al post cumpetent en il TDT (opensource@bk.admin.ch) per examinar, sch'ina publicaziun via il conto GitHub central (swiss) è sensada e pussaivla. ++ +Autoritads federalas duessan en mintga cas tegnair ina copia locala dal code. I è era recumandabel che mintga autoritad federala dispona d'ina strategia correspundenta e da reglas internas correspundentas. ++ +Ulteriuras recumandaziuns sa chattan en link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +=== Documentaziun + +[qanda.unnumbered] +Tge pretensiuns da documentaziun existan per la publicaziun da OSS?:: +Ils meds messs a disposiziun dal sectur TDT da la Chanzlia federala infurmeschan davart las pretensiuns giuridicas; vesair ils meds OSS. ++ +I vegn recumandà d'emplenir las glistas da controlla OSS e da las archivar centralmain en mintga autoritad federala (unitad administrativa). + +=== Contribuziuns da l'administraziun federala a projects + +[qanda.unnumbered] +Po e duai ina unitad administrativa contribuir code ad in project «upstream» ed adempla ella uschia las pretensiuns da l'art. 9 EMBAG?:: +* Sch'ils projects èn open source, è l'art. 9 EMBAG ademplì. Ils projects ston dentant era restar open source. Sche quai n'è betg il cas, sto il code vegnir publitgà danovamain. +* Contribuziuns upstream han l'avantatg che la mantenziun ha lieu en il project upstream e che il profit per la communitad vegn maximà. ++ +I existan ils suandants dischavantatgs: pli pauca controlla ed influenza; eventualmain sto vegnir suttascrit in CLA u in DCO (vesair link:em002-4.pdf[Em002-4] chapitel 3.3). Las contribuziuns na cumparan ultra da quai betg en il publiccode.yml ed en ils registers da la Confederaziun. In avantatg cumplettamain auter è ch'ils sviluppaders sa sviluppan vinavant cun talas contribuziuns entaifer l'ecosistem. +* Uschè ditg ch'ils ristgs e la lavur restan survisaivels (cuntegn dal CLA, collecziun dal code), èn contribuziuns upstream da bainvegnir. +* Per la contribuziun vala lura la licenza dal project upstream. Quai correspunda al proceder en link:em002-3.pdf[Em002-3]. +* *Forks da projects upstream èn d'evitar:* L'entira lavur da mantenziun e d'actualisaziun croda lura tar l'autoritad federala. In fork tgirà nunsuffizientamain represchenta ultra da quai in ristg per la segirezza. Per la communitad na nascha bunamain nagin profit. +* Contribuziuns a projects upstream duessan fundamentalmain vegnir giuditgadas positivamain e vegnir tematisadas activamain dals manaders da project da las autoritads federalas. +* Sche il project upstream appartegna a l'administraziun federala e sch'i sa tracta da contribuziuns da terzas persunas, agida link:em002-7.pdf[Em002-7] chapitel 9 vinavant. + +=== Support + +[qanda.unnumbered] +Sto l'autoritad federala prestar support per software publitgà?:: +Na, ella po far quai dentant, sch'ella vul. ++ +Tenor l'art. 9 al. 5 e 6 EMBAG dastga ella era incassar taxas per il support. + +Co proceda ina autoritad, sch'ella vul facturar il support?:: +Per motivs da resursas n'è quai betg part dal project actual da metter a disposiziun meds. Sche necessari pudess quai vegnir integrà en ils meds en ina etappa posteriura. Per il mument regla mintga autoritad federala quai sezza. (Vesair era link:em002-4.pdf[Em002-4 Guida da communitads OSS]) + +== Meds + +=== Instrucziun + +[qanda.unnumbered] +Exista ina instrucziun centrala per il tractament cun software open source en l'administraziun federala?:: +Gea, il sectur TDT da la Chanzlia federala metta a disposiziun documents cumplessivs en il rom da link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala]. ++ +OSS vegn tractà en general en link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala]. La relaschada tenor l'art. 9 EMBAG vegn tractada en link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da software open source]. + +=== Glistas da controlla + +[qanda.unnumbered] +Cumpiglian ils meds era glistas da controlla per la relaschada da software open source?:: +Gea, il sectur TDT da la Chanzlia federala metta a disposiziun libra las suandantas glistas da controlla: ++ +-- +* link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Glista da controlla examinaziun preliminara OSS] +* link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla analisa e preparaziun OSS] +* link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Glista da controlla relaschada e publicaziun OSS] +* link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla communitad OSS] + +Vesair ultra da quai la *glista da controlla per l'excepziun generala tenor l'art. 9 EMBAG* [BBL-CL] da l'UFCL. +-- + +=== Dumondas da segirezza + +[qanda.unnumbered] +Existan ristgs da segirezza spezials tar OSS?:: +En quest connex vegnan numnads per exempel attatgas sin la chadaina da furniziun, debilitads zero-day ed attatgas da typosquatting. ++ +Talas dumondas da segirezza ston vegnir resguardadas tar OSS e tar ses acquist, ma era generalmain tar il svilup da software e tar l'acquist da software commerzial. Al pli pon ellas sa rinforzar in pau, sche il project OSS duvrà è stà pauc quità tar l'integraziun da bibliotecas e da containers. ++ +A media vista dovri ina strategia generala per reducir quests ristgs (via il NCSC/UFCS). Sche necessari ston vegnir messas a disposiziun funtaunas segiras per containers e bibliotecas. ++ +En general ston tut ils responsabels en il sectur TI enconuscher quests vectors d'attatga pussaivels. Emprovas pussaivlas èn: ++ +* Attatgas sin la chadaina da furniziun: `XZ_Utils_backdoor` (https://en.wikipedia.org/wiki/XZ_Utils_backdoor), Codecov (https://blog.gitguardian.com/codecov-supply-chain-breach/) +* Debilitads zero-day: Log4Shell (https://www.ibm.com/de-de/think/topics/log4j) +* Typosquatting: https://en.wikipedia.org/wiki/Typosquatting + +Augmenta la publicaziun dal code da funtauna il ristg d'ina copia malmalitgusa d'ina app? (p.ex. ina app da phishing u ina app faussa):: +Na. Il retegnair dal code da funtauna na porscha nagina protecziun efficazia cunter apps faussas ed è ultra da quai betg cumpatibel cun l'artitgel 9 EMBAG che fixescha il princip open source per l'administraziun federala. ++ +Il ristg ch'ina terza persuna construeschia ina app opticamain identica per rimnar datas exista independentamain dal fatg, sche il code da funtauna è publitgà. Perquai ch'ils sistems da design da la Confederaziun èn disponibels publicamain, po l'apparientscha d'ina app vegnir reproducida d'in attatgader senza access al code da funtauna. Apps sa laschan ultra da quai decumpilar per extrair elements sco logos da la versiun publitgada. ++ +Segirezza e fidanza vegnan perquai garantidas betg tras la secretezza, mabain tras la verificaziun e la segirezza criptografica: ++ +-- +* *Signaturas digitalas:* Apps uffizialas ston esser signadas criptograficamain; uschia è garantì tecnicamain ch'ina app saja in original nunmidà da la Confederaziun. Il sistem operativ dal telefonin verifitgescha questa signatura. +* *Verificaziun en ils app stores:* Ils app stores dad Apple e Google porschan proceduras per verifitgar ch'ils editurs sajan posts statals uffizials. Google designescha per exempel expressivamain las apps da la Chanzlia federala (ChF) sco apps d'autoritads, quai che dat als utilisaders fidanza en lur autenticitad. +* *Reproducible builds:* Tras builds independents e reproducibels sa lascha mussar tecnicamain che il code da funtauna publitgà correspundia exactamain a la app disponibla en il store. + +Ina excepziun generala per motivs relevants per la segirezza tenor l'artitgel 9 EMBAG n'è perquai betg applitgabla tar apps. + +[.underline]#Recumandaziun:# + +Empè da retegnair il code da funtauna duess il focus sa chattar sin ils process dals app stores e sin la surveglianza. Chanals uffizials ston vegnir tegnids actuals, ed apps faussas ston vegnir annunziadas immediatamain per vegnir allontanadas dals gestiunaris da la plattafurma (Apple e Google). +-- + +È quai sensa ch'ils posts cun basegn entaifer l'administraziun federala sa reuneschian per acquistar OSS?:: +Gea, absolutamain. Quai po capitar directamain e senza furmalitads tranter unitads administrativas. ++ +Il problem è pli tgunsch ch'las unitads administrativas na san betg bler davart il basegn da las autras. ++ +Ina soluziun pudess esser ch'unitads administrativas mainian ina glista «most wanted» dad utensilis (u bibliotecas) OSS che duessan vegnir sviluppads u messs a disposiziun e che cundividian questa glista. ++ +Ina tala glista manada centralmain pudess era gidar dad analisar meglier il basegn da cumponentas OSS e da giuditgar meglier il grad da madirezza da l'unitad administrativa. A la fin fiss in artifact repository sensà. ++ +Manar ina tala glista fiss lura l'incumbensa d'in OSPO, sch'in tal vegn introducì. Al meglier pudess quai era capitar via l'Administraziun digitala Svizra per l'entira structura federala. + +== Dumondas giuridicas + +=== Utilisaziun da l'englais + +[qanda.unnumbered] +Dastga la Confederaziun utilisar licenzas en la lingua originala englais?:: +Tenor l'art. 9 al. 4 EMBAG duessan, nua che quai è pussaivel e sensà, vegnir duvrads texts da licenza stabilids internaziunalmain. ++ +D'insister sin licenzas OSS en lingua tudestga schmaledischess amplamain l'intent da l'art. 9 al. 4 EMBAG, perquai ch'i dat mo fitg paucs texts da licenza stabilids internaziunalmain, tar ils quals ina versiun en ina da las linguas uffizialas da la Svizra (tudestg, franzos ed talian tenor l'art. 70 al. 1 CF) è renconuschida sco decisiva per l'interpretaziun. ++ +Questa situaziun correspunda a quella dals curs en lingua englaisa a scolas autas sco il PF, nua che l'englais è admess sco lingua d'instrucziun – cun resalva da las trais cundiziuns da l'artitgel 36 da la Constituziun federala (commentari da Son Gagl da la Constituziun federala, 4. ed. 2023, art. 70 N 29; i ston pia exister ina basa legala, in interess public e la proporziunalitad, per che l'englais saja admess). ++ +Sin questa basa sto l'art. 9 al. 4 EMBAG vegnir interpretà uschia ch'el furma la basa legala per l'utilisaziun da licenzas en lingua englaisa, perquai che licenzas internaziunalas èn scrittas surtut en englais. La disposiziun sto perquai sa referir a quellas. ++ +L'interess public en l'art. 9 EMBAG sa chatta tranter auter en il barat cun las communitads da sviluppaders respectivas.footnote:[FF 2022 804, p. 66] En la branscha d'informatica èn questas communitads tipicamain internaziunalas ed utiliseschan l'englais sco lingua da lavur. Ina limitaziun a licenzas en lingua tudestga rendess la collavuraziun cun communitads internaziunalas almain pli difficila, sche betg nunpussaivla, perquai che software licenzià uschia na vegniss bunamain betg duvrà internaziunalmain. Quai stess era en cuntradicziun cun l'intent da l'artitgel 9 EMBAG. ++ +Ultra da quai valan licenzas OSS stabilidas internaziunalmain per definiziun en tut il mund. Il legislatur ha evidentamain vulì pussibilitar l'utilisaziun internaziunala dal software relaschà. Ina limitaziun da relaschadas OSS a licenzas en lingua tudestga restrenschess fermamain l'utilisabladad internaziunala dal software relaschà. ++ +Ultra da quai è l'englais stabilì fermamain sco lingua standard en il sectur commerzial da la branscha d'informatica, da la quala fan era part las relaschadas OSS. L'utilisaziun da licenzas en lingua englaisa represchenta perquai ina limitaziun raschunaivla e proporziunada dals dretgs dals partenaris contractuals. Licenzas en lingua englaisa èn ultra da quai adattadas e necessarias per cuntanscher las finamiras aspiradas. + +=== Exclusiun da la responsabladad + +[qanda.unnumbered] +Las pli bleras licenzas OSS cuntegnan exclusiuns da la responsabladad. Basta quai, u dovri mesiras supplementaras? Co è la situaziun tar software defectus? (inclus il resguard da la Lescha davart la responsabladad):: +Las licenzas applitgablas excludan la responsabladad per negligientscha lifra. *Per negligientscha grava u intenziun na po la responsabladad betg vegnir excludida.* Ils ristgs practics da responsabladad èn dentant minimals. ++ +Sche software midà vegn derasà sut ina licenza ch'è incumpatibla cun la licenza dal software original (per exempel sut ina licenza MIT senza copyleft, malgrà che il code duvrà originalmain era sut ina licenza GPL cun copyleft), viola quai la licenza originala. Mancond la protecziun da la buna fai en il dretg immaterial, na pon auters utilisaders ni duvrar da subit il software original sut la nova licenza, ni nascha ina obligaziun exequibla dad offrir la nova licenza a las cundiziuns da la licenza originala. L'unica consequenza è la violaziun da la licenza originala, quai che po manar a pretensiuns da indemnisaziun (analogia da licenza) cunter ina autoritad federala. ++ +Quest ristg sa lascha dentant dominar tras in'examinaziun sistematica tenor las guidas, sco quai ch'è oz standard en la branscha da software. Concretamain pretenda la licenziaziun la creaziun d'ina glista da tut las cumponentas da software preexistentas ch'entran en il nov software; quella sto vegnir observada strictamain tar la licenziaziun. ++ +Sch'i existan dretgs da terzas persunas, na pretenda l'art. 9 al. 1 EMBAG tuttina nagina publicaziun dal software (u eventualmain mo da sias parts nov scrittas; quai duess vegnir sclerì en las guidas). ++ +Tenor l'artitgel 11 da la Lescha davart la responsabladad sa drizza la responsabladad da la Confederaziun tenor il dretg civil, sch'ella agescha sco subject dal dretg civil. Quai è il cas tenor l'art. 9 al. 2 EMBAG; ina responsabladad supplementara tenor la Lescha davart la responsabladad è consequentamain excludida. + +=== Software permissiv + +[qanda.unnumbered] +Sche software sa basa sin ina biblioteca resp. cumponenta da program publitgada sut ina licenza permissiva: po il software principal (senza la biblioteca) vegnir publitgà sut ina licenza betg permissiva?:: +Gea, quai è senza problems. Vesair las indicaziuns en la guida link:em002-3.pdf[Em002-3]. + +=== Disposiziuns da licenza + +[qanda.unnumbered] +Po software vegnir duvrà da plirs uffizis? Tge disposiziuns da licenza valan entaifer l'administraziun federala? Vala l'administraziun federala sco concern? (Quai pertutga software open source da terzas persunas betg midà.):: +La derasaziun da software sut licenzas permissivas è per ordinari senza problems. ++ +Tar licenzas copyleft sa pona dentant la dumonda, sche la derasaziun entaifer l'administraziun federala centrala u decentralisada chaschuna obligaziuns da copyleft e periclitescha uschia la confidenzialitad dals svilups agens da la Confederaziun. Tar la surdada ad instituziuns da l'administraziun federala decentralisada cun atgna persunalitad giuridica è quai effectivamain il cas, entaifer l'administraziun federala centrala percunter betg, perquai che tut ils departaments ageschan sut la medema persunalitad giuridica. ++ +Societads d'in concern èn giuridicamain independentas, ma restan sut la controlla economica da la societad mamma. La litteratura giuridica considerescha la surdada da code licenzià cun copyleft ad ina societad dal concern sco chaschunond obligaziuns da copyleft. Perquai che societads d'in concern retschaivan savens software open source tar il svilup da software, dovran ellas in agen dretg d'utilisaziun; la surdada ad ina societad dal concern chaschuna pia obligaziuns da copyleft. ++ +Percunter na chaschuna la surdada entaifer l'administraziun federala centrala naginas obligaziuns da copyleft. Per l'administraziun federala decentralisada, nua ch'existan persunalitads giuridicas separadas, vala quai survart: La surdada chaschuna obligaziuns da copyleft, ed il software sto vegnir purschì en furma da code da funtauna a las medemas cundiziuns da licenza sco il software original. Ina directiva da betg surdar il software a terzas persunas violass la licenza e pudess era cuntrafar a l'art. 9 EMBAG. + +=== Relaziun tranter la LTrans e la EMBAG + +[qanda.unnumbered] +En tge relaziun stattan la Lescha davart la transparenza (LTrans) e la EMBAG?:: +Tenor l'art. 6 LTrans ston documents uffizials vegnir surdads. Sco document uffizial vala tenor l'art. 5 al. 1 LTrans mintga infurmaziun ch'è registrada sin in purtader d'infurmaziun da tge gener ch'i saja, che sa chatta en il possess d'ina autoritad e che pertutga l'adempliment d'ina incumbensa publica. OSS croda fundamentalmain sut la LTrans. La LTrans vegn applitgada, sch'ina persuna pretenda dad in departament u dad in uffizi il code da funtauna per l'agen diever. L'uffizi sto publitgar il code da funtauna a la persuna pertutgada, nun ch'excepziuns tenor l'artitgel 7 LTrans vegnian applitgadas. Sche l'uffizi refusa da publitgar il code da funtauna, vala la procedura da la LTrans. In auter cas è, sche insatgi pretenda che l'uffizi publitgeschia il code da funtauna sin sia pagina d'internet. Lura na sa drizza la procedura betg tenor la LTrans, mabain tenor la EMBAG. Perquai che la EMBAG sezza na prevesa nagina procedura, sto il dretg administrativ general bastar. Quel porscha u la pussaivladad d'ina disposiziun, d'in act real u d'ina disposiziun da constataziun generala da l'uffizi pertutgà. Questa decisiun po lura vegnir appellada tar il Tribunal administrativ federal. ++ +Schebain ch'obligaziuns da publicaziun per software sviluppà d'ina autoritad federala èn pussaivlas tenor la LTrans (sche las cundiziuns correspundentas èn ademplidas), sto vegnir resguardà che la publicaziun da software tenor la LTrans na concedia betg automaticamain ina licenza OSS. L'utilisaziun da software publitgà tenor la LTrans sa limitescha uschia als intents fixads da la LTrans, sco la consultaziun dal code u sia execuziun per motivs d'observaziun. La publicaziun tenor la LTrans na cumpiglia dentant nagina licenza per l'utilisaziun reglada dal software u sco basa per il svilup vinavant da software (detagls en T. Poledna/S. Schlauri/S. Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source-Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern [trad.: Premissas giuridicas da l'utilisaziun da software open source en l'administraziun publica, en spezial en il chantun Berna], Turitg 2017, https://carlgrossmann.com/?ddownload=11748, N 393 sq.). ++ +La decisiun da licenziar software sco OSS sa drizza era lura vinavant tenor la EMBAG, sch'el croda sut la LTrans; in dretg a la concessiun d'ina licenza n'exista vinavant betg. ++ +Impurtant è: Software sviluppà avant il 1. da schaner 2024 na suttastat betg a la EMBAG, sto dentant tuttina vegnir surdà tenor la LTrans. + +=== OSS e protecziun da datas + +[qanda.unnumbered] +Pon datas persunalas da sviluppaders vegnir publitgadas senza vinavant? Tge aspects da la protecziun da datas ston vegnir resguardads?:: +Dal puntg da vista da la protecziun da datas è la publicaziun da datas persunalas (p.ex. nums u adressas d'e-mail) problematica, uschenavant ch'ils collaboraturs n'han betg consentì anticipadamain. Perquai che la communicaziun da datas persunalas po fundamentalmain vegnir evitada tras la pseudonimisaziun u l'anonimisaziun da las endataziuns en il repositori, quai che fiss necessari tenor il princip da la minimisaziun da las datas e da la proporziunalitad (art. 6 al. 2 LPD). ++ +In tal consentiment duess dentant per ordinari esser simpel da retrair, perquai ch'ils collaboraturs han savens in interess da mussar publicamain lur abilitads (uschia Poledna/Schlauri/Schweizer, N 68, cun renviaments). In consentiment po era vegnir dà taciturnamain tras l'utilisaziun da nums en il repositori, almain sche naginas directivas cuntraras da la patruna n'existan. ++ +Tuttina è recumandabel da reglar en ils contracts la responsabladad dal furnitur per las datas persunalas da ses collaboraturs. + +== Generalitads + +[qanda.unnumbered] +Giogia quai in rol, sche OSS vegn duvrà commerzialmain u betg commerzialmain?:: +Licenzas open source na differenzieschan per ordinari betg tranter utilisaziun commerziala e betg commerziala. OSS po perquai vegnir duvrà per mintga intent, era per applicaziuns commerzialas. Furniturs commerzials empruvan savens dad integrar cumponentas OSS en products proprietars. Quai è mo permess, sche las cumponentas OSS na stattan betg sut ina licenza cun effect copyleft (vesair era link:em002-3.pdf[Em002-3 Guida da licenzas OSS]). + +Existan restricziuns, tge organisaziuns che èn permessas per communitads?:: +A la fin sto adina vegnir considerà il cas singul: Tgi stat davos, e tge obligaziuns vegnan surpigliadas? ++ +Uschè ditg che nagin daner na flueschia e che naginas obligaziuns formalas na vegnan surpigliadas, è la situaziun relativamain simpla e senza problems. ++ +Commembranzas en associaziuns èn pussaivlas, sco era ina collavuraziun informala. ++ +I è pussaivel da delegar commembranzas ad eOperations u ad organisaziuns sumegliantas. ++ +Vesair era link:em002-4.pdf[Em002-4 Guida da communitads OSS], chapitel 3.1 + +En tge relaziun stat la norma ISO 5230 cun las guidas?:: +La norma ISO 5230:2020 è vegnida examinada e resguardada tar l'elavuraziun da las guidas. La glista sutvart mussa las pretensiuns da la norma e co ch'ellas èn vegnidas adressadas en las guidas: ++ +-- +*3.1 Programme foundation* + +* Las «link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala]» e las strategias referenziadas furman il rom. Per la realisaziun èn cumpetents ils departaments ed ils uffizis respectivs. + +*3.2 Relevant tasks defined and supported* + +* La guida «link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da OSS]» e las glistas da controlla defineschan incumbensas concretas per la publicaziun. In post central n'exista actualmain betg en l'administraziun federala. + +*3.3 Open source content review and approval* + +* Il process da publicaziun vegn descrit en il med «link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da OSS]». Quel renviescha era a l'existenza d'ina Software Bill of Materials (SBOM). +* Il med «link:em002-3.pdf[Em002-3 Guida da licenzas OSS]» infurmescha amplamain davart la licenziaziun. + +*3.4 Compliance artifact creation and delivery* + +* Il process da publicaziun vegn descrit en il med «link:em002-2.pdf[Em002-2 Instrucziun per la publicaziun da OSS]». Quel renviescha era a l'existenza d'ina Software Bill of Materials (SBOM). +* La realisaziun na vegn betg descritta pli detagliadamain ed ha lieu en ils departaments u en ils uffizis. + +*3.5 Understanding open source community engagements* + +* Il med «link:em002-4.pdf[Em002-4 Guida da communitads OSS]» descriva, co ch'ina communitad vegn construida e tgirada. Per mintga project sto vegnir definì e realisà in concept. + +*3.6 Adherence to the specification requirements* + +* Il chapitel final cuntegna pretensiuns ad organisaziuns u projects che vulan confermar expressivamain l'observaziun da las pretensiuns OpenChain. +-- ++ +La norma ISO delinescha ulteriurs secturs da responsabladad d'in Open Source Programme Office (OSPO) che n'èn betg cuverts da las guidas. + +== Agiunta + +=== Abreviaziuns + +[horizontal] +include::partials/abbreviations.rm.adoc[tags=abbr-em002-6] + +=== Glossari + +Ulteriuras noziuns sa chattan en TERMDAT, la https://www.bk.admin.ch/bk/rm/home/dokumentation/sprachen/termdat.html[banca da datas terminologica] da l'administraziun federala. + +include::partials/glossary.rm.adoc[tags=gloss-em002-6] +endif::[] diff --git a/docs/em002-7.adoc b/docs/em002-7.adoc new file mode 100644 index 0000000..9c5f794 --- /dev/null +++ b/docs/em002-7.adoc @@ -0,0 +1,3566 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002-7 OSS Guideline: Applying Article 9 EMOTA +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002-7 Leitfaden OSS: Anwendung von Artikel 9 EMBAG +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002-7 Guide OSS : application de l'article 9 LMETA +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002-7 Guida OSS: applicazione dell'articolo 9 LMeCA +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002-7 Guida OSS: applicaziun da l'artitgel 9 EMBAG +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +*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 {url-repo}/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.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] + +include::partials/document-map.en.adoc[] + +Figure 1: Overview of OSS tools + +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]. + +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*: [.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. In that model the layers beneath the roof -- collaboration, technology skills, the four pillars and regulation -- are the areas in which recommended measures promote digital sovereignty. + +[mermaid,align="center",alt="Schematic representation of the aspects of digital sovereignty enabling the provision of innovative products and services"] +.... +block-beta + columns 4 + Roof["Innovative digital products and services
from businesses and public authorities"]:4 + space:4 + Collab["Collaboration with research and civil society"]:4 + Skills["Technology skills (programming, data science, etc.)"]:4 + SW["Software"] Data["Data and
digital content"] AI["Artificial
intelligence"] Infra["ICT infrastructure
(hardware)"] + Reg["Regulation (laws, standards)"]:4 + Collab-- "enable" -->Roof +.... + +_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: + +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: + +0 -- Externally determined / non-sovereign:: +No control over systems, data or infrastructure; no transparency, high dependencies; no exit or alternative options + +1 -- Minimally controlled:: +Initial insight into usage and dependencies; selective control mechanisms; operational, legal or technological gaps remain + +2 -- Regulated and usable:: +Systems reliable and partially controllable; legal and technical framework established; strategic dependencies still present + +3 -- Self-directing and resilient:: +Market position is used; exit strategies and multi-vendor concepts implemented; know-how built up; resilience and crisis scenarios prepared + +4 -- Systemically sovereign:: +Sovereignty across all relevant dimensions (legal, technological, cultural, strategic); active shaping of markets and standards; geopolitical effect possible + +_Figure 3: Degree of digital sovereignty._ + +These two dimensions produce the following matrix: + +[.landscape] +[cols="2,^1,^1,^1,^1,^1",options="header"] +|=== +|Perspective +|0 + +Externally determined +|1 + +Minimally controlled +|2 + +Regulated and usable +|3 + +Self-directing and resilient +|4 + +Systemically sovereign + +|A -- Technological control +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|B -- Data sovereignty +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|C -- Legal capacity to act +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|D -- Resilience +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|E -- Economic control +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +|=== + +_Figure 4: Matrix of digital sovereignty: perspectives against degree of sovereignty._ + +Specific criteria can be described for the individual intersections of the grid 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.pdf[Em002 OSS Strategic Guidelines], Section 3, are ranked in descending order of importance: + +image::./assets/four-cs/four-cs.en.svg[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 _[DigiV]_. + +=== 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 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.pdf[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.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 + +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.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.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. + +=== 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.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. + +=== 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\], [KBB-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.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.] + +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.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. + +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.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. + +*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_. + +include::partials/references.en.adoc[tags=ref-em002-7] + +== 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]. + +include::partials/glossary.en.adoc[tags=gloss-em002-7] +endif::[] + +ifeval::["{lang}" == "de"] +*Haftungsausschluss:* 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 {url-repo}/tree/main[README]. + +''' + +== Das Wichtigste auf einen Blick + +Dieses Dokument ergänzt den Hilfsmittelsatz OSS Em002 um Aspekte der Beschaffung. Es baut auf dem vom Kompetenzzentrum Beschaffungswesen Bund (KBB)footnote:[Das Kompetenzzentrum Beschaffungswesen Bund (KBB) berät die Beschaffungs- und Bedarfsstellen in beschaffungsrechtlichen Fragen nach Art. 37 VöB. Zentrale E-Mail-Adresse für Anfragen: rechtsdienst.kbb@bbl.admin.ch] veröffentlichten _Merkblatt zur Softwarebeschaffung und Art. 9 EMBAG_ _[KBB-MB]_ auf und fasst die Inhalte von BBL-Dokumentenfootnote:[Das Bundesamt für Bauten und Logistik (BBL) ist die zentrale Beschaffungsstelle des Bundes (Art. 5–7 VöB). Es beschafft in seinem Zuständigkeitsbereich, bündelt wo sinnvoll und kann Rahmenverträge abschliessen.] wie der _Wegleitung Open Source in der Beschaffung_ [BBL-WL] zusammen, die nur im Intranet verfügbar sind.footnote:[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] Das Dokument behandelt zudem die digitale Souveränität als Beschaffungskriterium. + +Der Einsatz von Open-Source-Software lässt sich in vier Aspekte gliedern: + +* Consumption: die Nutzung bereits bestehender OSS +* Creation: die Entwicklung neuer OSS +* Contribution: das Einbringen eigener Anpassungen in ein bestehendes OSS-Projekt +* Collaboration: die gemeinsame Weiterentwicklung von OSS mit Dritten. + +In all diesen Situationen muss eine öffentliche Auftraggeberin das einschlägige Beschaffungsrecht einhalten. + +*Consumption:* + +* Das Beschaffungsrecht gilt, wenn Leistungen gegen Entgelt auf dem Markt eingekauft werden (Art. 8 BöB). + +Mit anderen Worten: + +* Die Nutzung von OSS, die kostenlos verfügbar ist (ohne Lizenzgebühren, Support- oder Wartungsverträge usw.), stellt in der Regel keine Beschaffung dar. +* Mehrwertleistungen, die für die Nutzung von OSS eingekauft werden (Support, Gewährleistung, Wartung und Weiterentwicklung), sind nach Beschaffungsrecht zu beschaffen. +* Bei der Beschaffung von Software ist es grundsätzlich zulässig, OSS als Anforderung vorzugeben, z. B. wenn die Verwaltungseinheit (VE) daraus konkrete Vorteile erwartet, etwa grössere Datensouveränität oder eine einfachere Einhaltung von Art. 9 EMBAG bei absehbaren individuellen Anpassungen. Der Markt darf dabei jedoch nicht unzulässig eingeschränkt werden. + +*Creation und Contribution:* + +* Bei der Entwicklung von Software oder Softwarekomponenten, auch im Hinblick auf einen späteren Beitrag zu einem OSS-Projekt, ist Art. 9 EMBAG stets zu berücksichtigen. Werden dafür Leistungen Dritter eingekauft, so gilt das Beschaffungsrecht. +* Bei Beiträgen an OSS-Projekte gibt die VE eigene Arbeit an Dritte weiter; dieser Vorgang untersteht daher nicht dem Beschaffungsrecht. +* Die Annahme von Beiträgen Dritter an ein OSS-Projekt des Bundes ist beschaffungsrechtlich ebenfalls unproblematisch, sofern keine Zahlung erfolgt. + +*Collaboration:* + +* Die Zusammenarbeit verschiedener öffentlicher Auftraggeberinnen an einem OSS-Projekt wirft eine Vielzahl rechtlicher Anforderungen auf. Beschaffungsrechtlich bedürfen jene Konstellationen einer sorgfältigen Prüfung, bei denen Leistungen gegen Entgelt erbracht werden. +* Bei einer informellen Zusammenarbeit kann jede beteiligte Partei Entwicklungsleistungen eigenständig beschaffen oder erbringen und anschliessend unentgeltlich zur Verfügung stellen. Ebenso können Koordinationsleistungen erbracht oder beschafft werden. +* Bei einer formalisierten Zusammenarbeit, z. B. über einen Verein öffentlicher Akteure, kann auch die zentrale Stelle Entwicklungsleistungen erbringen oder beschaffen, sofern sie selbst dem Beschaffungsrecht untersteht. +* Eine gemeinsame Beschaffung durch Auftraggeberinnen aus verschiedenen Ländern ist hingegen nicht ohne Weiteres zulässig. + +Für den nachhaltigen Einsatz von Open-Source-Software ist es wichtig, dass OSS nicht nur konsumiert wird, sondern dass möglichst viele Beteiligte auch zum Ökosystem beitragen. Dafür gibt es viele Wege: von regelmässigen Codebeiträgen über das Erstellen von Dokumentation bis zur Finanzierung von Entwicklerinnen und Entwicklern und vieles mehr. + +== Ziel und Zweck + +Das Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/de] verlangt, dass bei der Beschaffung neu entwickelter Software und von Softwareentwicklungsleistungen zusätzliche Überlegungen berücksichtigt werden. + +Zur Unterstützung der Einhaltung von Art. 9 EMBAG hat DTI im Rahmen von link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] und link:em002-1.pdf[Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung] Hilfsmittel erarbeitet. + +include::partials/document-map.de.adoc[] + +Abbildung 1: Übersicht über die OSS-Hilfsmittel + +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. + +Dieses Dokument geht über den Kern von Artikel 9 EMBAG hinaus und legt zudem dar, wie mit Open Source im Beschaffungskontext allgemein umzugehen ist. + +Kapitel 3:: Die Bedeutung der digitalen Souveränität im Kontext von Open Source und Beschaffung +Kapitel 4:: Relevante Beschaffungsanwendungsfälle im Zusammenhang mit Software und Open-Source-Software +Kapitel 5:: Creation: Ausschreibung von Software und Leistungen im Zusammenhang mit Art. 9 EMBAG +Kapitel 6:: Consumption: Softwarebeschaffung: Gleichbehandlung von Open-Source-Software +Kapitel 7:: Consumption: Beschaffung zusätzlicher Leistungen (Support/Wartung/Weiterentwicklung) für OSS +Kapitel 8:: Collaboration: Beschaffungsrechtliche Aspekte von Zusammenarbeiten für die Erstellung, Wartung und den Support von OSS +Kapitel 9:: Contribution: Beiträge an OSS-Projekte + +== Digitale Souveränität und Beschaffung + +=== Einführung in digitale Souveränität und OSS + +Mit Art. 9 EMBAG leistet die Bundesverwaltung durch die Veröffentlichung ihrer Software als OSS einen wichtigen Beitrag zur digitalen Nachhaltigkeit und Souveränität. + +Digitale Souveränität ist kein Selbstzweck, sondern eine Voraussetzung für eine wirksame, demokratische und zukunftsorientierte Verwaltung. Sie ist ein vielschichtiges Konzept mit technologischen, organisatorischen und politischen Dimensionen. + +**** +*Digitale Souveränität bedeutet, dass der Staat über die nötige Kontrolle und Handlungsfähigkeit im digitalen Raum verfügt, um die Erfüllung staatlicher Aufgaben sicherzustellen.* +**** + +Insbesondere bei der Beschaffung von Software sind die Auswirkungen auf die digitale Souveränität der Bundesverwaltung zu berücksichtigen. + +In ihren *Rollen als Nutzerin, Betreiberin und Auftraggeberin* im Bereich IKT und Software kann die Bundesverwaltung ihre diesbezügliche Verantwortung bewusst wahrnehmen. + +Im Bereich Software bestehen drei strategische Ziele: + +*Austauschbarkeit*: [.underline]#Als Nutzerin# strebt die öffentliche Verwaltung an, frei und flexibel zwischen Anbietern, IT-Lösungen und Technologien wählen zu können. Dies setzt die Verfügbarkeit leistungsfähiger und bewährter Alternativen sowie IT-Architekturen, Beschaffungswege und eine Personalausstattung voraus, die einen Wechsel erleichtern. + +*Gestaltungsfähigkeit*: [.underline]#Als IT-Betreiberin# verfügt die öffentliche Verwaltung über die Fähigkeit, ihre IT-Systeme zu gestalten und mitzugestalten. Dazu verfügt sie über das nötige Fachwissen und geeignete kooperative Strukturen, um IT-Lösungen zu verstehen und zu bewerten und nötigenfalls deren Entwicklung, Weiterentwicklung und Betrieb sicherzustellen. + +*Einfluss*: [.underline]#Als Auftraggeberin# kann die öffentliche Verwaltung ihre Anforderungen und Bedürfnisse gegenüber Technologieanbietern formulieren und durchsetzen. Dies gilt für Produktmerkmale (Funktionen, Betriebsoptionen, Verfügbarkeit, Informationssicherheit und Datenschutz usw.) ebenso wie für Vertragsgestaltung und Lizenzmodelle. + +*Offene Standards* und *Open-Source-Software* unterstützen diese Ziele durch *Open-Source-Prinzipien* am besten. + +OSS unterstützt die digitale Souveränität wie folgt: + +* Die IT-Sicherheit für die öffentliche Verwaltung, kritische Infrastrukturen und sicherheitsrelevante Anwendungen lässt sich [.underline]#jederzeit# durch [.underline]#vollen Zugriff# auf den Quellcode gewährleisten. +* OSS ermöglicht es öffentlichen Stellen, ihre eigene IT-Infrastruktur ohne einschränkende Lizenzbedingungen aufzubauen, zu betreiben, zu kontrollieren und anzupassen. +* OSS bietet volle Kontrolle über Updates, Funktionen und Sicherheitspatches, sowohl inhaltlich als auch zeitlich. +* OSS kann die Abhängigkeit von einzelnen Anbietern oder Lizenzmodellen verhindern und unterstützt die Austauschbarkeit. +* OSS erlaubt es, die gesamte Software-Lieferkette transparent darzustellen und nachzuvollziehen. +* OSS lässt sich anpassen und erweitern – gut geeignet für die spezifischen Anforderungen von Behörden und Bildungseinrichtungen, wobei dies vertiefte Kenntnisse der eigenen Mitarbeitenden voraussetzt. +* Investitionen in OSS kommen auch lokalen Unternehmen und Communities zugute (lokale Wertschöpfung) und erhöhen die Resilienz der Schweizer Wirtschaft. +* OSS beruht auf Zusammenarbeit und offenen Schnittstellen, erleichtert die Interoperabilität zwischen Systemen und fördert offene Standards – auch über Landesgrenzen hinweg. +* OSS verbessert die IT- und Datensicherheit durch Transparenz und Anpassbarkeit. +* Unter OSI-Lizenzen lizenzierte OSS garantiert klare rechtliche Bedingungen und Kontinuität sowie die grundlegenden Freiheiten von OSS und schützt Entwickelnde wie Nutzende gleichermassen. + +*Offene Standards:* Zur Unterstützung der Austauschbarkeit von Software sollten öffentliche Ausschreibungen die Einhaltung offener Standardsfootnote:[Beispielsweise offene Standards wie eCH, ODF; siehe auch https://de.wikipedia.org/wiki/Offener_Standard[Offener Standard – Wikipedia]] verlangen und damit Lock-in minimieren. +*Offene Schnittstellen:* Schnittstellen sollten ebenfalls offengelegt werden, um Interoperabilität zu ermöglichen. + +Bundesbehörden sind grundsätzlich verpflichtet, die eCH-Standards einzuhalten.footnote:[https://www.ech.ch/[www.ech.ch]] + +Die Berner Fachhochschule hat die massgebenden Überlegungen in der im Auftrag des EDA erstellten Studie _Technologische Perspektiven der digitalen Souveränität_ [Stü2024] anhand des Modells «Souveränitätshaus» dargelegt, in dem Software als tragende Säule dargestellt wird. In diesem Modell sind die Schichten unterhalb des Dachs – Zusammenarbeit, Technologie-Skills, die vier Säulen und Regulierungen – die Bereiche, in denen empfohlene Massnahmen die digitale Souveränität fördern. + +[mermaid,align="center",alt="Schematische Darstellung der Aspekte digitaler Souveränität, welche die Bereitstellung innovativer Produkte und Dienstleistungen ermöglichen"] +.... +block-beta + columns 4 + Roof["Innovative digitale Produkte und Dienstleistungen
von Unternehmen und Behörden"]:4 + space:4 + Collab["Zusammenarbeit mit Forschung und Zivilgesellschaft"]:4 + Skills["Technologie-Skills (Programmieren, Data Science usw.)"]:4 + SW["Software"] Data["Daten und
digitale Inhalte"] AI["Künstliche
Intelligenz"] Infra["ICT-Infrastruktur
(Hardware)"] + Reg["Regulierungen (Gesetze, Standards)"]:4 + Collab-- "ermöglichen" -->Roof +.... + +_Abbildung 2: Schematische Darstellung der Aspekte digitaler Souveränität, welche die Bereitstellung innovativer Produkte und Dienstleistungen ermöglichen [Stü2024]_ + +=== Digitale Souveränität messen + +Aspekte der digitalen Souveränität können in einer öffentlichen Ausschreibung verlangt werden, doch müssen solche Anforderungen sachlich begründet sein. Eine generelle Bevorzugung von OSS besteht nicht. + +*Wie lässt sich der Grad der digitalen Souveränität für eine bestimmte Technologie, ein Produkt oder eine Dienstleistung messen?* + +Diese Operationalisierung ist so objektiv und transparent wie möglich vorzunehmen. + +Verschiedene Initiativen versuchen dies. Die OSBA hat beispielsweise einen **Souveränitätsindex**footnote:[https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet[Ein Index für digitale Souveränität | OSBA – Open Source Business Alliance]] _[OSBA-VK]_ entwickelt. _Nextcloud_ hat einen Digital Sovereignty Index (DSI)footnote:[https://dsi.nextcloud.com/[dsi.nextcloud.com]] veröffentlicht, der ganze Länder vergleicht, aber auch nützliche Kriterien liefern kann. +Die Europäische Union hat für die Cloud ein 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]] veröffentlicht. +Das _Zentrum für Digitale Souveränität ZenDiS_ arbeitet an einem Souveränitätscheck, mit dem IT-Lösungen und Organisationen anhand transparenter Souveränitätskriterien bewertet werden sollen. + +Die Bundesverwaltung ist ebenfalls an der Entwicklung eines *Frameworks für digitale Souveränität* beteiligt, mit dem unter anderem der Erfüllungsgrad über verschiedene Perspektiven hinweg bestimmt werden kann. + +Mögliche Perspektiven sind: + +A -- Technologische Kontrolle:: +Inwieweit hat die Bundesverwaltung Kontrolle über die eingesetzten Technologien und deren Weiterentwicklung? + +B -- Datensouveränität:: +Wer hat Zugriff auf die Daten, Kontrolle darüber und Entscheidungsbefugnis – insbesondere bei sensiblen Verwaltungsdaten? + +C -- Rechtliche Handlungsfähigkeit:: +Inwieweit können die Schweiz und die Bundesverwaltung die rechtlichen und politischen Rahmenbedingungen der Digitalisierung beeinflussen? + +D -- Resilienz:: +Wie robust und krisenfest sind die digitalen Systeme und Prozesse der Bundesverwaltung gegenüber Störungen, Krisen und Abhängigkeiten? + +E -- Wirtschaftliche Kontrolle:: +Wie kann die Bundesverwaltung wirtschaftliche Kontrolle und strategisches Sourcing ausüben, um ihre digitale Souveränität kosteneffizient zu sichern und dabei Abhängigkeiten und Risiken in der IT-Beschaffung zu minimieren? + +Für jede dieser Perspektiven lässt sich der Grad der digitalen Souveränität anhand einer noch zu definierenden Skala bestimmen: + +0 -- Fremdbestimmt / nicht souverän:: +Keine Kontrolle über Systeme, Daten oder Infrastruktur; keine Transparenz, hohe Abhängigkeiten; keine Exit- oder Alternativoptionen + +1 -- Minimal kontrolliert:: +Erste Einsichten in Nutzung und Abhängigkeiten; punktuelle Kontrollmechanismen; operative, rechtliche oder technologische Lücken bestehen + +2 -- Geregelt nutzungsfähig:: +Systeme verlässlich und teilweise steuerbar; rechtlicher und technischer Rahmen etabliert; strategische Abhängigkeiten bestehen weiterhin + +3 -- Selbststeuernd und resilient:: +Marktposition wird genutzt; Exit-Strategien und Multivendor-Konzepte implementiert; Know-how aufgebaut; Resilienz und Krisenszenarien vorbereitet + +4 -- Systemisch souverän:: +Souveränität in allen relevanten Dimensionen (rechtlich, technologisch, kulturell, strategisch); aktive Markt- und Standardgestaltung; geopolitische Wirkung möglich + +_Abbildung 3: Grad der digitalen Souveränität._ + +Diese beiden Dimensionen ergeben die folgende Matrix: + +[.landscape] +[cols="2,^1,^1,^1,^1,^1",options="header"] +|=== +|Perspektive +|0 + +Fremdbestimmt +|1 + +Minimal kontrolliert +|2 + +Geregelt nutzungsfähig +|3 + +Selbststeuernd und resilient +|4 + +Systemisch souverän + +|A -- Technologische Kontrolle +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|B -- Datensouveränität +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|C -- Rechtliche Handlungsfähigkeit +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|D -- Resilienz +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|E -- Wirtschaftliche Kontrolle +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +|=== + +_Abbildung 4: Matrix digitale Souveränität: Perspektiven gegenüber dem Grad der Souveränität._ + +Zu den einzelnen Schnittfeldern des Rasters können konkrete Kriterien beschrieben werden, um die Einstufung möglichst objektiv zu gestalten. + +Ein solches Framework wird derzeit im Rahmen des Schwerpunkts 4 «Digitale Souveränität stärken» der «Strategie Digitale Bundesverwaltung» entwickelt.footnote:[https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html[www.bk.admin.ch – Digitale Bundesverwaltung]] + +Der Bundesrat hat die Dachweisung Digitale Souveränität in der Bundesverwaltungfootnote:[W012 – Weisungen für die digitale Souveränität in der Bundesverwaltung] auf den 1. Januar 2026 in Kraft gesetzt. Projekte müssen die verschiedenen Aspekte auf der Grundlage des konkreten Souveränitätsbedarfs in die Definition des Beschaffungsgegenstands und nötigenfalls in eine Ausschreibung einbeziehen – beispielsweise aus Risikosicht im Rahmen des Business Continuity Managements. + +== Anwendungsfälle der Softwarebeschaffung + +Informations- und Kommunikationstechnologie (IKT) und Software sind in der Bundesverwaltung kein Selbstzweck, sondern dienen stets der Erfüllung eines gesetzlichen Auftrags. Angesichts der fortschreitenden Digitalisierung und der zentralen Rolle der Bundesverwaltung in der Schweiz muss die Informationstechnologie eine Kernkompetenz der Verwaltung sein. + +Die folgenden *Faktoren* wirken sich daher unmittelbar auf die Beschaffung aus: + +* *Digitalisierung*: Die Digitalstrategiefootnote:[https://digital.swiss/de/] verlangt die Digitalisierung von Prozessen. +* *Prozessoptimierung*: Prozesse innerhalb der Bundesverwaltung und in ihren Aussenbeziehungen können und sollen optimiert werden. +* *Digitale Souveränität*: Die Bedeutung der digitalen Souveränität nimmt stetig zu; siehe _[Stü2024]_. +* Der Grundsatz *public money, public goods* und die Einhaltung von Art. 9 EMBAG. +* *Wirtschaftsfreiheit*: Massnahmen sollen die Wirtschaftsfreiheit nicht unnötig einschränken. +* Allgemeine *Sicherheitsüberlegungen*: Die Sicherheit informationsverarbeitender Systeme gewinnt zunehmend an Bedeutung. +* Krisen- und Katastrophenbewältigung (*Resilienz*): Angesichts der aktuellen weltweiten Lage muss die Verwaltung prüfen, wie sie die nötigen Arbeitsmittel auch unter kritischen Umständen weiterhin bereitstellen kann. +* Strategische Unabhängigkeit und Überlegungen zur *Lieferkette*: Diese ergeben sich aus digitaler Souveränität und Resilienz. +* Vermeidung bzw. Minimierung von *Vendor-Lock-in*: Abhängigkeiten lassen sich in der IT kaum vermeiden, doch sollte die Abhängigkeit von einem einzigen Anbieter wo immer möglich reduziert werden. +* *Befähigung* der Bundesverwaltungfootnote:[Nicht nur bei Führungskräften, Projektleitenden und IKT-Architektinnen und -Architekten, sondern bei allen Mitarbeitenden.] (einschliesslich der Geschäftsleitung) in IKT-Fragen: Die Steuerung, Entwicklung und der Betrieb von Informationstechnologie erfordern entsprechende Kompetenzen in der gesamten Belegschaft. + +Dieses Dokument unterscheidet folgende *Softwaretypen*: + +* *Commodity – Fachanwendungen/Branche – Fachanwendungen/Bundesbehörde*: +** Standardanwendung (Commodity-Software) ohne besondere Geschäftslogik. +** Fachanwendung: spezifischer Bedarf der Branche/aller föderalen Ebenen oder spezifischer Bedarf der Bundesbehörde +* *Gezielt – strategisch – essenziell*: +** Gezielte Anwendung +** Strategische Anwendung mit erheblicher Bedeutung für eine Bundesbehörde oder die Bundesverwaltung insgesamt +** Essenziell und geschäftskritisch – muss unter allen Umständen funktionsfähig bleiben (z. B. Flugsicherung) + +Anwendungen können in einem oder mehreren *Anwendungsbereichen* eingesetzt werden. + +Massgebend ist hier die *Standardisierung* der Anwendungen nach Produkt innerhalb jedes Bereichs: + +* Keine Strategie +* Ein-Produkt-Strategie +* Mehr-Produkt-Strategie + +Neben der Produktstandardisierung, die sorgfältig zu prüfen ist, gibt es auch die Standardisierung zur Interoperabilität (Datenformate, API, Geschäftselemente).footnote:[z. B. über eCH] +Standardisierung _ist zulässig_, sofern sie verhältnismässig ist und den Wettbewerb nicht unzulässig einschränkt (z. B. Art. 30 Abs. 3 BöB). Sie kann Betriebs- und Wartungskosten senken und Synergieeffekte erzeugen, insbesondere wenn alle föderalen Ebenen beteiligt sind. Andererseits erhöht sie Lock-in, Abhängigkeit und teilweise Sicherheitsrisiken (Klumpenrisiko). + +Die Gesamtbetriebskosten (TCO) – einschliesslich Betrieb, Wartung und Weiterentwicklung – sollten bei der Beschaffung stets berücksichtigt werden. Langfristige Kostenfolgen dürfen nicht übersehen werden. Open-Source-Geschäftsmodelle unterscheiden sich in gewisser Hinsicht von jenen proprietärer Anbieter. + +Die folgenden Kapitel konzentrieren sich zunehmend auf Open Source und behandeln das massgebende Beschaffungsvorgehen sowie dessen Umsetzung. + +Die Wahl zwischen Consumption, Contribution, Collaboration und Creation erfolgt _projektspezifisch_ nach Wirtschaftlichkeit und Rechtslage, wobei die Kosten möglichst breit verteilt werden. Aus dieser Sicht sind die vier C gemäss link:em002.pdf[Em002 Strategische Leitlinien OSS], Kapitel 3, in absteigender Bedeutung geordnet: + +image::./assets/four-cs/four-cs.de.svg[Rangfolge der vier C: Consumption, Contribution, Collaboration, Creation] + +. Consumption +. Contribution +. Collaboration +. Creation + +Bei einfacher *Consumption* verteilen sich die Kosten auf eine grosse Zahl anderer Nutzender, doch hat die Bundesbehörde keine Kontrolle über die Weiterentwicklung. Creation ist das Gegenteil: volle Kontrolle, aber volle Kosten. + +Bei der *Contribution* beschränkt sich der finanzielle Aufwand auf das entwickelte Element, das anschliessend einer anderen Organisation zur Pflege übergeben wird. + +*Collaboration* ist das komplexeste Szenario, da die Ausgestaltung stark variieren kann. Im besten Fall werden die Kosten geteilt und die Bundesbehörde hat genügend Einfluss, um ihre Anforderungen ohne Kompromisse umzusetzen (siehe Kapitel 8). + +Idealerweise entfällt auf *Creation* der kleinste Anteil. Software kann intern, über Dienstleistungen oder über einen Werkvertrag entwickelt werden. + +Reine Consumption wird nur bei Standardanwendungen möglich sein. + +=== Software erfordert zusätzliche Leistungen wie Wartung, Support und Weiterentwicklung. + +Open-Source-Anwendungen können zwar kostenlos genutzt werden, doch ihr strategischer Einsatz über Tausende von Instanzen hinweg erfordert Wartung, Support und nötigenfalls Weiterentwicklung. + +Bundesbehörden haben ein Interesse an langfristigem Support für eingesetzte Versionen (siehe Kapitel 3.2.3 in _[BITKOM2024]_). + +Art. 9 EMBAG selbst erfasst nur die interne Entwicklung oder Weiterentwicklung von Software und ist für andere Open-Source-Überlegungen nicht massgebend – hier gelten stattdessen digitale Souveränität und weitere Faktoren. Einschränkungen nach Art. 9 EMBAG bei einzelnen Entwicklungskomponenten können jedoch Rückwirkungen auf das Gesamtprojekt haben, wenn proprietäre oder zusätzliche Entwicklungen absehbar sind. Mit Collaboration lassen sich dann Synergieeffekte nutzen und die Kosten für die Bundesverwaltung insgesamt nach Möglichkeit senken. + +=== Veröffentlichungspflicht bei der Softwarebeschaffung + +Wenn die Anforderungen auf einen Anpassungsbedarf an der Software oder einen möglichen späteren Anpassungsbedarf hindeuten, ist Art. 9 EMBAG einschlägig und die Veröffentlichung für diese Teile obligatorisch, sofern nicht eine der beiden Ausnahmen greift. Bei der Beschaffung einer Open-Source-Lösung wäre eine solche Veröffentlichung bereits über einen Beitrag an das Open-Source-Projekt abgedeckt. Auch wenn die Beschaffung nur die Lizenzierung von Standardsoftware oder eine unter eine Ausnahme fallende IKT-Beschaffung betrifft, sind zusätzliche Entwicklungen grundsätzlich zu veröffentlichen; dies ist in den Beschaffungsunterlagen und im Vertragsentwurf abzubilden. + +*Die Veröffentlichungspflicht nach Art. 9 EMBAG ist daher für jede Beschaffung relevant, bei der eine Eigen- oder Weiterentwicklung wahrscheinlich ist* (siehe auch _[KBB-MB]_). + +== Creation: Ausschreibungen für Software und Leistungen mit Bezug zu Artikel 9 EMBAG + +Dieses Kapitel behandelt die Auswirkungen von Art. 9 EMBAG auf Ausschreibungen für Software und Leistungen, die die Erstellung oder Änderung von Software umfassen können. + +Es gilt für die zentrale wie für die dezentrale Bundesverwaltung. Ausnahmen von dieser Pflicht sind in der Digitalisierungsverordnung _[DigiV]_ festgelegt. + +=== Relevanz von Artikel 9 EMBAG für die Softwareerstellung + +Ein Vorgang fällt in den Anwendungsbereich von Art. 9 EMBAG, wenn er unter die massgebende Kategorie von Tabelle 1 fällt. Der Make-or-Buy-Entscheid bleibt für die Beschaffung zentral. Die Analyse der verschiedenen Anwendungsfälle zeigt, dass grundsätzlich Art. 9 EMBAG in allen Fällen relevant ist, ausser wenn bereits bestehende Software beschafft wird (z. B. reine Lizenzen). Kapitel II.4 der _Wegleitung Open Source in der Beschaffung [BBL-WL]_ legt das strategische Vorgehen dar, und Anhang VII.A beschreibt im Detail, was als Software gilt. Eine detaillierte Aufschlüsselung des strategischen Entscheids findet sich in Tabelle 1. + +[cols="3,2,4",options="header"] +|=== +|Anwendungsfall |Make or Buy |Veröffentlichungspflicht nach Art. 9 Abs. 1 EMBAG + +|Entwicklung von Software innerhalb der Bundesverwaltung +|Make +|Ja, Veröffentlichungspflicht + +|Software durch Dritte entwickeln lassen +|Buy als IT-Dienstleistungsvertrag +|Ja, Veröffentlichungspflicht + +|Beschaffung bestehender Software +|Buy +a|Grundsätzlich nein, aber prüfen, ob für zu entwickelnde Teile Veröffentlichungspflichten bestehen. Besonders relevant ist der Umgang mit Rechten Dritter (siehe link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung]). + +|Übernahme von Software anderer öffentlicher Stellen +|Make oder Buy +a|– Innerhalb der Bundesverwaltung: Veröffentlichungspflicht der abgebenden Verwaltungseinheit. + +– Andere: im Einzelfall prüfen, ob Anpassungen durch die Bundesverwaltung eine Veröffentlichungspflicht begründen, zumindest für diese Teile. + +|Beschaffung von Entwicklungsressourcen +|Make +|Ja, Veröffentlichungspflicht (Verträge müssen die Veröffentlichung zulassen) + +|Zusammenarbeit mit anderen öffentlichen Stellen bei der Softwareentwicklung +|Make +|Ja, Veröffentlichungspflicht (Verträge müssen die Veröffentlichung zulassen), insbesondere bei wesentlichen Entwicklungsbeiträgen durch oder für den Bund +|=== + +_Tabelle 1: Einordnung von Veröffentlichungspflicht und Make-or-Buy-Entscheid (in Anlehnung an eine Tabelle von Rika Koch, BFH)_ + +Hinweis: Art. 9 EMBAG ist auch bei bestehender Software und SaaS zu berücksichtigen, wenn die Software für den Bund weiterentwickelt oder angepasst werden soll. Auch wenn die Wahrscheinlichkeit gering ist, sollte dies im Beschaffungsprozess behandelt werden. + +Wo Klärungsbedarf besteht, wird link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] als Referenz empfohlen. Die Checklisten sollten für potenziell relevante Projekte *möglichst früh provisorisch ausgefüllt* werden. Auch die _Checkliste Integral-Ausnahme Art. 9 EMBAG [BBL-CL]_ kann hierfür verwendet werden. + +=== Vorbereitung einer Beschaffung nach Artikel 9 EMBAG + +Zusätzlich zu den üblichen Vorbereitungsschritten sind die folgenden beiden Dokumente stets beizuziehen, wenn eine Beschaffung Softwarekomponenten umfasst: + +* _Merkblatt zur Softwarebeschaffung und Art. 9 EMBAG [KBB-MB] und_ +* _Wegleitung Open Source in der Beschaffung [BBL-WL]_. + +Wo Art. 9 EMBAG klar einschlägig ist, sollte die Verwaltungseinheit: + +* die Checklisten link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] bis link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] provisorisch ausgefüllt haben; +* einen Grundsatzentscheid getroffen haben, ob eine Copyleft- oder eine permissive Lizenz verwendet wird;footnote:[Eine vertiefte Analyse kann bei Bedarf später anhand von _Em002-3 Leitfaden OSS-Lizenzierung_ erfolgen.] +* nach möglichen Open-Source-Alternativen (oder potenziellen Basisprojekten für Contributions/Collaboration) gemäss link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] gesucht haben, unter Verwendung der dort genannten Werkzeuge für Marktrecherche/Marktanalyse;footnote:[Siehe auch link:em002-1.pdf[Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung], Kapitel 7.] +* die Struktur einer allfälligen Community geklärt haben (link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] und link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community]). + +Soll ein bestehendes OSS-Projekt genutzt, unterstützt oder im Rahmen einer Collaboration darauf aufgebaut werden, so sind die Kapitel 5, 6, 8 und 9 dieses Dokuments zu lesen. + +=== Creation über bestehende Dienstleistungsverträge + +Erfolgt die Creation über bestehende Partnerverträge, so ist die OSS-Veröffentlichung spätestens beim Mini-Tender sicherzustellen, sofern nicht eine der beiden Ausnahmen greift. + +Neue Dienstleistungsausschreibungen sollten stets eine Anforderung zur Veröffentlichung nach Art. 9 EMBAG enthalten (siehe _[BBL-WL] und_ _[KBB-MB])_. + +=== Aufbau einer Community + +Der Aufbau und die Pflege einer Community maximieren den Nutzen von Open-Source-Software, sind aber auch mit erheblichem Aufwand verbunden. + +Wo eine Community und eine Collaboration sinnvoll sind, hat dies von Anfang an Auswirkungen auf die Beschaffung. Die link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] sollte daher anhand des link:em002-4.pdf[Em002-4 Leitfadens OSS-Community] ausgefüllt werden. + +Soll die Bundesbehörde eine bedeutende Rolle in der Community übernehmen (z. B. eine Governance-Rolle) oder ist eine Zusammenarbeit geplant (siehe Kapitel 8), so kann die Beschaffung zusätzlicher Leistungen nötig sein: Community-Aufbau, Konsolidierung von Anforderungen, Steuerung der Weiterentwicklung. + +=== Musterkriterien und Vertragselemente für die IT-Beschaffung + +Das KBB führt eine Vorlage möglicher Beschaffungskriterien sowie eine Vorlage für ein Rahmenvertragskapitel für softwarebezogene Ausschreibungen _[KBB-KV]_. + +Das KBB hat auf Perimap.admin.ch zwei Mustervorlagen veröffentlicht, die zeigen, wie die Mindestanforderungen für eine beschaffungskonforme Vergabe nach Art. 9 EMBAG erfüllt werden können. [KBB-KV] + +. https://perimap.admin.ch/goto_perimap_file_47064_download.html[Musterkriterien – Beschaffung EMBAG und Open Source] +. https://perimap.admin.ch/goto_perimap_file_47059_download.html[Mustervertragstexte – Softwareentwicklung] + +== Consumption: Softwarebeschaffung: Gleichbehandlung von Open-Source-Software + +Dieses Kapitel behandelt die Beschaffung und Nutzung (Consumption) von Open-Source-Software und hebt zentrale strategische Aspekte hervor. +Verwiesen wird zudem auf _[BBL-WL] und_ _[KBB-MB]_. + +*Derzeit besteht keine gesetzlich vorgeschriebene Bevorzugung von Open-Source-Software in der Beschaffung.* + +Bei Ausschreibungen für IT-Anwendungen werden alle Lizenztypen und Geschäftsmodelle berücksichtigt. Zur Erfüllung der gestellten Anforderungen können Anbieter Softwarelösungen auf Basis unveränderter Open-Source-, Closed-Source- oder proprietärer Software oder auf Basis von Kombinationen aus Lizenzmodellen und Mehrwertleistungen bzw. Subskriptionen anbieten. + +Die folgenden Punktefootnote:[Massgebende Referenzdokumente für die Beschaffung sind jene, die vom BBL und vom KBB auf den entsprechenden Plattformen veröffentlicht werden.] sind von den Bundesbehörden zu berücksichtigen: + +* Unabhängig von Lösung und Lizenzmodell muss der Leistungserbringer in seinem Angebot angeben, *welche Lizenzbedingungen der Leistungsbezüger bei der Nutzung der Leistung einzuhalten hat*. +* Der Leistungserbringer ist *frei in der Wahl der Lösung*, mit der er die ausgeschriebenen Anforderungen erfüllen will, sowie in der Form der Vergütung, die er erhalten möchte (Lizenz-, Wartungs- oder Subskriptionsgebühren), sofern dies technisch machbar und wirtschaftlich vertretbar ist. +* Der gesamte *Lebenszyklus* ist in den Spezifikationen und der Preisgestaltung zu berücksichtigen. + +Dies ermöglicht es der Bundesverwaltung, ihre Interessen in Bezug auf geistiges Eigentum, Gewährleistung und Haftung – unabhängig von Software- oder Lizenzmodell – auf Ebene der anwendbaren allgemeinen Geschäftsbedingungen geltend zu machen und vertraglich zu verankern. + +Werden *Softwareanpassungen* im Auftrag oder in Erfüllung eines Vertrags mit der Bundesbehörde vorgenommen, so gilt Art. 9 EMBAG. +Vorsorglich sollte die Veröffentlichungserlaubnis bereits in der Ausschreibung verlangt werden, da erfahrungsgemäss früher oder später Anpassungen nötig werden, auch wenn sie zum Zeitpunkt der Ausschreibung nicht absehbar sind. + +Bezieht der Leistungsbezüger neben der Software *Mehrwertleistungen* von einem Anbieter, so bieten OSS-Lieferanten häufig ein Subskriptionsmodell an, das eine lokale Ansprechstelle mit Gewährleistungs- und Haftungszusagen bietet, zusätzlich zur direkten Beziehung zu den Inhabern der Immaterialgüterrechte an den OSS-Komponenten (die oft im Ausland ansässig und teilweise unbekannt sind). + +=== OSS als strategisches Beschaffungskriterium + +Will eine Bundesbehörde aus strategischen Gründen Open-Source-Software beschaffen, so sind mehrere Szenarien möglich: + +* Funktionale Ausschreibung ohne OSS-spezifische Kriterien. +Da dies keine Einschränkungen mit sich bringt, ist keine besondere Begründung erforderlich. +* Funktionale Ausschreibung mit Eignungskriterium, technischen Kriterien und Zuschlagskriterien, die Open Source, vollen Zugriff auf den Quellcode oder nachweisbare Erfahrung mit Open-Source-Veröffentlichungen verlangen. + +*Eine Bevorzugung von Open Source ist beschaffungsrechtlich zulässig, wenn sich damit die konkreten Bedürfnisse der vergebenden Stelle (besser) erfüllen lassen*.footnote:[Siehe [BBL-WL\], [BBL-CL\], [KBB-MB\], [KBB-KV\]] + +Ein weiterer Grund für die Bevorzugung von OSS – über die digitale Souveränität hinaus – ist, dass bei erheblichen Softwareanpassungen durch die Verwaltung diese nach Art. 9 EMBAG veröffentlicht werden müssen. +Eine Veröffentlichung ist am einfachsten, wenn das gesamte Produkt von jeher Open Source war und Anpassungen teilweise direkt im Produkt vorgenommen werden können. Andernfalls ist eine Ausnahme zu definieren und sind nötigenfalls Codeteile zu isolieren und dennoch freizugeben. + +=== Die unentgeltliche Nutzung von OSS untersteht nicht dem Beschaffungsrecht. + +OSS kann oft direkt heruntergeladen und genutzt werden. Das Beschaffungsrecht gilt nur, wenn Leistungen von Dritten gegen Entgelt (einschliesslich nicht geldwerter Gegenleistungen) bezogen werden. + +Das kostenlose Herunterladen und Nutzen von OSS stellt für sich genommen keine Beschaffung dar. + +Es ist auch möglich, die nötigen Leistungen für heruntergeladene OSS zu einem späteren Zeitpunkt zu beschaffen, sofern dies nicht missbräuchlich geschieht.footnote:[Analogie: Eine Gemeinde kann eigenes Holz verwenden und den Bau eines Werkhofs mit diesem Holz in Auftrag geben – sie muss das Holz nicht selbst beschaffen.] + +Wartungs-, Support- und Weiterentwicklungsleistungen für das Produkt werden anschliessend separat nach Beschaffungsrecht ausgeschrieben. + +Es gibt bereits Beispiele für OSS, die auf den Standardarbeitsplätzen der Bundesverwaltung kostenlos genutzt und daher nicht beschafft wird.footnote:[Beispiele für OSS mit Standardisierungspotenzial: Gimp, FileZilla, VLC Media Player und 7-zip als Shell-2-Produkte (gemäss [A029\]), die genutzt werden können, weil die Installation kostenlos ist. 2024 hat das BIT Red Hat OpenShift aufgrund seiner einzigartigen technischen Eigenschaften für bestimmte Anwendungsbereiche als strategisches Produkt bezeichnet. OpenShift ist derzeit die strategische Plattform für Container und Betriebssysteme.] + +=== Abstimmung der Anforderungen mit anderen Beteiligten + +Eine Fachanwendung erfordert stets eine Bedarfsträgerin (in der Regel ein Bundesamt). In der Regel ist es sinnvoll, dass die bedarfstragende Stelle ihre Anforderungen mit jenen anderer Verwaltungsstellen abstimmt – intern oder im Rahmen einer Collaboration (siehe Kapitel 8) –, soweit ein verfügbares Marktprodukt oder eine gemeinsame Entwicklung der Entwicklung und Einführung förderlich ist. + +Haben viele Beteiligte die gleichen oder ähnliche Anforderungen, so kann es sich lohnen, diese Bedürfnisse gemeinsam abzudecken. Dies gilt für alle Formen von Software. + +Zwei Aspekte sind zu beachten: Werden anschliessend durch eine Bundesbehörde auf Wunsch Dritter Anpassungen vorgenommen, so gilt wiederum Art. 9 EMBAG – dies ist jedoch unproblematisch, wenn Open-Source-Software eingesetzt wird. + +Bei OSS müssen die Anforderungen unter Umständen aktiver durch die Bundesbehörde abgestimmt werden, da eine treibende Kraft wie ein kommerzieller Anbieter, der sein eigenes Produkt steuern und weiterentwickeln will, fehlen kann. + +=== Berücksichtigung weiterer möglicher öffentlicher Akteure bei der Beschaffung + +Das Beispiel ZenDiSfootnote:[https://www.zendis.de/en[https://www.zendis.de/] ZenDiS hat sich zum Ziel gesetzt, die Verwaltung aus kritischen Abhängigkeiten von einzelnen Technologieanbietern zu lösen.] zeigt, dass es machbar und lohnenswert sein kann, eine Ausschreibung gleichzeitig über alle föderalen Ebenen hinweg durchzuführen. + +*Ein fairer Wettbewerb ist stets zu wahren.* Bei Ausschreibungen ist stets zu prüfen, ob die Lösung sinnvollerweise auch für andere Stellen beschafft werden könnte. + +Ist dies der Fall, so sind diese potenziellen zusätzlichen Auftraggeberinnen zu kontaktieren und ihre Bedürfnisse in den Ausschreibungsunterlagen, insbesondere den Anforderungen, abzubilden. Eine gewisse Flexibilität bei den Anforderungen ist in solchen Fällen wichtig. + +Beispiel: eOperations Schweiz AG (http://www.eoperations.ch[www.eoperations.ch]) kann für solche Zusammenarbeiten genutzt werden. eOperations konsolidiert Anforderungen verschiedener Stellen und führt die Beschaffung selbst durch, ohne das Produkt zwingend selbst zu nutzen. Dies kann auch für die OSS-Beschaffung ein nützliches Modell sein. + +== Consumption: Beschaffung von Support und Wartung für OSS + +Die öffentliche Verwaltung kann Open-Source-Software auf verschiedene Weise nutzen, vom einfachen Herunterladen und Installieren bis zur förmlichen Beschaffung (siehe Kapitel 6.2). + +Wird OSS in kritischen Bereichen eingesetzt, so sind durchgehend hohe Standards bei Sicherheit,footnote:[Siehe auch link:em002-6.pdf[Em002-6 FAQ-OSS], Kapitel 5.3] Wartung und Weiterentwicklung erforderlich. Bei der regulären Softwarebeschaffung wird dies üblicherweise durch die Ausschreibung abgedeckt. Die Anforderungen gelten sowohl für die Software selbst als auch für die verwendeten Bibliotheken und Frameworks. Support und Wartung verdienen besondere Aufmerksamkeit, da die Weiterentwicklung oft im selben Vertrag abgedeckt ist und ohnehin Creation darstellt und damit in den Anwendungsbereich von Art. 9 EMBAG fällt. + +Diese arbeitsintensiven Leistungen überschreiten über den Anwendungslebenszyklus gerechnet fast immer den Schwellenwert nach dem Bundesgesetz über das öffentliche Beschaffungswesen (BöB). Werden sie von Dritten bezogen, so ist das Beschaffungsrecht einzuhalten. Ausnahmen können gelten, etwa die staatsinterne Beschaffung bei einer anderen öffentlichen Auftraggeberin,footnote:[Art. 10 Abs. 3 Bst. b BöB.] oder in Ausnahmefällen die freihändige Beschaffung von Spezialleistungen.footnote:[Art. 21 Abs. 2 Bst. c BöB.] + +Die folgende Tabelle zeigt die Fallunterscheidungen für die Beschaffung von Leistungen wie Support. + +[cols="1,1,1,2"] +|=== +2+h|Ausgangslage 2+h|Ergebnisse + +h|Lebenszykluskosten + +→ WTO-Schwellenwert?footnote:[Interne Kosten können ausgeklammert werden. Der gesamte Lebenszyklus ist zu berücksichtigen.] +h|Staatsintern?footnote:[Staatsinterne Beschaffung ist nicht ausschreibungspflichtig: staatliche Trägerschaft erforderlich, keine Marktteilnahme. Gilt nur innerhalb des schweizerischen öffentlichen Sektors.] +h|WTO-Ausschreibung erforderlich?footnote:[Die Beschaffungsrichtlinien des Bundes gelten stets, sobald eine Zahlung erfolgt.] +h|Bemerkungen + +|Nein +|Nein +|Nein footnote:[Software mit Support überschreitet in der Regel den BöB-Schwellenwert; «nein» trifft nur in seltenen Fällen zu (z. B. Finanzierung einer einzelnen Funktion für ein bestehendes OSS-Projekt).] +.2+|Selten ein vollständiges Softwarepaket mit Support – meist geringer Support und einzelne Funktionen. + +|Nein +|Ja +|Nein + +|Ja +|Nein +|Ja +|Nur das Volumen gegenüber Dritten ist massgebend. + +|Ja +|Ja +|Nein +|Die Ausschreibung wurde von der anderen öffentlichen Stelle durchgeführt. +|=== + +_Tabelle 2: Fallunterscheidung – Beschaffung von Support_ + +=== Support und Wartung sind immer Teil von Software + +Support und Wartung sind für den nachhaltigen Betrieb von Software im Behördenumfeld unerlässlich. In einer Welt von Zero-Day-Exploitsfootnote:[Ein Zero-Day-Exploit bezeichnet die Ausnutzung einer Sicherheitslücke, für die noch kein Patch des Komponentenentwicklers verfügbar ist.] ist ein rasches und professionelles Einspielen von Patches entscheidend. Diese «Infrastruktur» muss finanziert werden – zumal die Verwaltung höhere Anforderungen hat als private Konsumentinnen und Konsumenten. + +*Die Frage ist daher nicht, OB Support und Wartung erforderlich sind, sondern WIE sie erbracht werden.* + +Die Bundesbehörde muss anhand ihrer Anforderungen an die Dienstleistungsqualität festlegen, welches Mass an Support, Wartung, Gewährleistung und Haftung sie benötigt. + +Wichtig ist, dass ein Leistungserbringer für Wartung und Support ausreichende Erfahrung mit dem Produkt oder der betreffenden Open-Source-Community nachweisen kann – nur dann wird er diese Aufgaben wirksam erfüllen können (siehe auch _[KBB-MB]_, II.5).footnote:[Der Dienstleistungsvertrag muss allenfalls auch den möglichen Wissenstransfer an eine Nachfolgeorganisation abdecken.] + +Support und Wartung müssen auch auf Produktebene finanziert werden. Trägt niemand bei (das Trittbrettfahrerproblemfootnote:[https://de.wikipedia.org/wiki/Trittbrettfahrerproblem]), so ist die Zukunft des Projekts gefährdet und damit auch dessen Einsatz in der Bundesverwaltung. Angesichts ihrer Grösse kann von der Bundesverwaltung vernünftigerweise erwartet werden, dass sie sich an den Kosten von Software beteiligt, die sie strategisch einsetzt. + +=== Organisationen, die Support leisten können + +Die Qualität des Supports wirkt sich unmittelbar auf die Zufriedenheit und Produktivität der Endnutzenden aus. Ein strukturiertes Supportsystem mit raschen Reaktionszeiten und echter technischer Fachkompetenz stellt sicher, dass Nutzende und Administratorinnen und Administratoren wirksame Lösungen für ihre Anliegen erhalten, was Arbeitszeit der Auftraggeberin spart und die Akzeptanz der Softwarelösung fördert. + +Um die vertraglich vereinbarten Reaktionszeiten aus Service Level Agreements (SLA) einzuhalten, muss der Anbieter über qualifiziertes Personal mit dem nötigen Fachwissen verfügen. + +Mögliche Supportquellen sind: + +*Intern*: + +* Bundesämter +* Leistungserbringer + +*Staatsintern*: + +* Andere öffentliche Auftraggeberinnen in der Schweiz +* Von anderen öffentlichen Auftraggeberinnen in der Schweiz beschaffte Leistungen + +*Dritte*: + +* Beschaffte Leistung + +=== Weiterentwicklung für bestimmte Funktionen + +Benötigt eine Bundesbehörde nur eine begrenzte Zahl spezifischer Erweiterungen an einer Open-Source-Software, so kann dies mit internen Ressourcen oder beschafften Leistungen erfolgen. + +Solche Weiterentwicklungen sollten darauf ausgerichtet sein, dem ursprünglichen Projekt angeboten und darin integriert zu werden. Dies kommt nicht nur dem Ökosystem des Projekts zugute, sondern stellt sicher, dass die Erweiterungen künftig im Projekt gepflegt werden. Andernfalls kann jede neue Version des ursprünglichen Projekts eine manuelle Nachführung der Individualentwicklung erfordern (siehe auch Kapitel 8). + +=== Subskription + +Viele Unternehmen und Projekte im Open-Source-Umfeld bieten innerhalb bestimmter Grenzen kostenlosen Support an, der freiwillig von beliebigen Nutzenden geleistet wird, hauptsächlich über offene Kanäle wie Foren und öffentliche Ticketsysteme. Dieses kostenlose Angebot ist nicht auf professionelle Nutzende mit spezifischen SLA-Anforderungen ausgerichtet. + +Für professionelle Nutzende wie Bundesbehörden sind häufig OSS-Subskriptionen erhältlich, die Gewährleistung, Wartung und Support umfassen. + +Manche Anbieter bieten zudem spezielle «Enterprise-Versionen» an, die die Open-Source-Kriterien der OSI nicht mehr erfüllen. + +Beispiele für Subskriptionen: OpenShift von Red Hat, openDesk von ZenDiS + +=== Zertifizierungen im Open-Source-Bereich und OpenChain + +Wie bei proprietärer Software bestehen auch im Open-Source-Bereich verschiedene Zertifizierungen. Für die Verwaltung kann es sich lohnen, vor einer Ausschreibung zu prüfen, ob im betreffenden Bereich relevante Zertifizierungen existieren. + +*OpenChain* ist eine ISO-Norm zu Open-Source-Entwicklung und Lizenzkompatibilität (siehe unten). + +Bestehen einschlägige Zertifizierungen und sind sie für die Leistung massgebend, so sind sie bei der Beurteilung der Anbieter zu berücksichtigen. Wichtig ist, dass die Zertifizierung selbst als aussagekräftig gilt und dass Anbieter nachweisen können, dass sie die Leistung auch ohne Zertifizierung erbringen können. + +Angesichts der damit verbundenen Komplexität ist es nicht ratsam, Zertifizierungen als Eignungskriterium zu verlangen. Als Zuschlagskriterium – mit der Möglichkeit, die Einhaltung der Zertifizierungsinhalte über Referenzen nachzuweisen – können sie je nach OSS-Produkt angemessen sein, sofern es zulässig ist, Referenzen zum Nachweis der Erfüllung von Zertifizierungskriterien zu verwenden.footnote:[Hinweis: Wird eine Zertifizierung verlangt, die überzogen oder für den Ausschreibungsgegenstand ungeeignet ist, so führt dies unweigerlich zu weniger wettbewerbsfähigen Angeboten.] + +Eine Selbstzertifizierung nach OpenChain kann allenfalls als Ersatz dienen, wenn keine andere Zertifizierung besteht. Referenzen, die die massgebenden Kriterien abdecken, können fehlende Zertifizierungen ebenfalls ersetzen. + +*Zertifizierung von Partnerunternehmen* + +Manche Open-Source-Entwickelnde und -Projektefootnote:[etwa Nextcloud oder Univention] zertifizieren Partnerunternehmen, mit denen sie zusammenarbeiten. Solche Zertifizierungen können eine bestehende Beziehung zwischen Anbieter und Softwareentwicklung belegen. Zu beachten ist, dass viele OSS-Projekte solche Zertifizierungen nicht anbieten. Eine nachgewiesene Zusammenarbeit in Referenzprojekten ist ein ebenso gültiger – und weniger einschränkender – Indikator für die gewünschte Qualität. + +*Zertifizierung von Mitarbeitenden* + +Manche Open-Source-Hersteller oder -Communitiesfootnote:[etwa LibreOffice oder RedHat] zertifizieren Einzelpersonen mit Fachwissen zur betreffenden Software. Beschäftigt ein Leistungserbringer zertifiziertes Personal, so kann dies Fachwissen bei der Upstream-Veröffentlichung von Anpassungen und Patches sowie bei der Erbringung hochwertigen Third-Level-Supports belegen – insbesondere wenn mehrere Mitarbeitende mit dem Produkt arbeiten. Dies hängt auch von der Struktur des Ökosystems des OSS-Projekts ab. + +Als Alternative zu Zertifizierungen kann auch nachweisbare Projekterfahrung in Referenzen zum Beschaffungsgegenstand als Unterscheidungskriterium dienen. + +*OpenChain-Standard* + +Der OpenChain-Standard stellt sowohl eine Best Practice für Lizenzkompatibilität als auch eine für beschaffende Stellen interessante Zertifizierung dar. + +ISO/IEC 5230 «OpenChain» konzentriert sich auf Software-Lieferketten, eine schlanke Beschaffung und Lizenz-Compliance. Der OpenChain-Standard kann von einer akkreditierten Zertifizierungsstelle verliehen oder über eine Selbstzertifizierung erlangt werden. Diese Zertifizierung eignet sich, um allgemein zu belegen, dass sich ein Anbieter bereits eingehend mit den Anforderungen von Open-Source-Lizenzen und den Besonderheiten des Open-Source-Ökosystems befasst hat. +Da die Erstellung einer Software Bill of Materials (SBOM) Teil des Standards ist, belegt diese Zertifizierung auch das Engagement eines Lieferanten für die Sicherheit der Lieferkette durch Unterstützung grundlegender Komponenten. + +=== Weitere Möglichkeiten zur Beschaffung von Wartungs-, Support- oder Weiterentwicklungsleistungen + +Es ist sinnvoll, Weiterentwicklungsleistungen im selben Vertrag wie Support und Wartung zu behandeln, da die Abgrenzung nicht immer eindeutig und im Kontext von Open-Source-Software oft nicht praktikabel ist. Von einer Bundesbehörde finanzierte Weiterentwicklungen fallen in den Anwendungsbereich von Art. 9 EMBAG. + +Derzeit bestehen die folgenden Möglichkeitenfootnote:[Weitere, eher nischenhafte Möglichkeiten können ebenfalls bestehen.] zur Beschaffung von Support-, Wartungs- und/oder Weiterentwicklungsleistungen für OSS: + +* Intern, mit Kompetenzaufbau: Einsatz eigener Entwicklungsressourcen +* Beschaffung: nach Volumen und unter Einhaltung des BöB. Dies kann auch über bereits ausgeschriebene Dienstleistungsverträge erfolgen. Damit strategische Partner erfahrene Kernentwickelnde für OSS-Projekte bereitstellen können, die für die Bundesverwaltung zentral sind, kann es sinnvoll sein, Unterbeauftragungen zuzulassen oder das entsprechende Fachwissen in bestimmten Ausschreibungen zu verlangen. +* Kooperationsvereinbarungen mit Dritten für Wartung, Support oder Weiterentwicklung: unproblematisch, solange jede Partei ihre eigenen Kosten trägt. +* Beteiligung des Bundes an Organisationen: unproblematisch, solange jede Partei ihre eigenen Kosten trägt. + +== Collaboration: Beschaffungsrechtliche Aspekte der gemeinsamen Erstellung, Wartung und Unterstützung von OSS + +Die Kosten von Open-Source-Software sinken, wenn sie gemeinsam entwickelt wird, sei es informell oder in einer strukturierten Form. Der link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] legt die massgebenden Vorgehensweisen dar. + +Die Zusammenarbeit mit anderen öffentlichen Auftraggeberinnen oder Dritten ist beschaffungsrechtlich unproblematisch, solange jede Partei ihre eigenen Kosten trägt. Schwierigkeiten entstehen, wenn aus der Zusammenarbeit keine OSS resultiert, da die Bundesverwaltung an Art. 9 EMBAG gebunden ist. + +Eine solche Zusammenarbeit ist nach Art. 4 EMBAG zulässig. + +Zu klären ist die Frage, wie mit Gemeinkosten oder einer zentralen Struktur umzugehen ist: Die Struktur benötigt eine ausreichende Finanzierung, um das Projekt auch durch schwierige Zeiten zu tragen. Eine Alternative ist eine einzige führende Partnerin (z. B. wenn eine beteiligte Stelle gross genug ist, um die Koordinationsrolle zu übernehmen). Übernimmt die Bundesbehörde diese Rolle, so sind die entsprechenden Leistungen intern zu erbringen oder auf dem üblichen Weg auszuschreiben, wenn Dritte beigezogen werden sollen. + +Auf Vertragsebene gilt für Zusammenarbeiten Folgendes: + +* Fliesst kein Geld und sind keine förmlichen Verpflichtungen erforderlich, so ist ein Memorandum of Understanding auf Ebene des Bundesamts oder der Bundeskanzlei möglich. +* Die Schaffung einer gemeinsamen Struktur – etwa eines Vereins oder einer öffentlich-rechtlichen Körperschaft – ist grundsätzlich möglich, muss aber im Einzelfall beurteilt werden. Soll die gemeinsame Struktur selbst Leistungen von Dritten beschaffen, so ist die Anwendung des Beschaffungsrechts zu regeln. + +Die Mitgliedschaft kann in bestimmten Fällen über andere Organisationen wie eOperations oder eCH wahrgenommen werden. + +*Zusammenarbeit mit dem Ausland* + +Die Zusammenarbeit mit ausländischen Behörden ist unproblematisch, solange kein Geld fliesst und keinerlei Verpflichtungen eingegangen werden. + +Kooperationsvereinbarungen auf geeigneter Ebene sind grundsätzlich möglich, müssen aber im Einzelfall beurteilt werden. +Von völkerrechtlichen Verträgen ist angesichts der hohen Hürden abzusehen, auch wenn sie grundsätzlich ebenfalls möglich wären. + +Es bestehen zwei Sonderfälle,footnote:[https://www.eda.admin.ch/deza/de/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] in denen eine Zusammenarbeit bereits abgedeckt wäre: + +* Aufträge, die im Rahmen einer internationalen Vereinbarung zur gemeinsamen Durchführung eines Projekts durch Signatarstaaten vergeben werden. +* Aufträge, die nach den besonderen Verfahren oder Bedingungen einer internationalen Organisation vergeben werden. + +== Contribution: Beiträge an OSS-Projekte + +Die meisten Merkmale und rechtlichen Überlegungen zu Beiträgen werden im link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] behandelt. + +Beschaffungsrechtlich sind Beiträge grundsätzlich unproblematisch, da die Leistungen zur Entwicklung von Code für ein Projekt erbracht werden, das entweder für die Behörde unmittelbar relevant ist oder beschaffungsrechtlich bereits behandelt wurde. + +*Beiträge Dritter an OSS-Projekte von Bundesbehörden sind beschaffungsrechtlich ebenfalls unproblematisch, solange kein Geld fliesst.* + +Hinweis: Da die Bundesbehörde verpflichtet ist, von ihr entwickelte Software zu veröffentlichen, muss sie auch sicherstellen, dass diese veröffentlicht bleibt. Wird ein OSS-Projekt von seinen Betreibenden abgeschaltet, so muss die Bundesbehörde es im schlimmsten Fall eigenständig erneut veröffentlichen. In der Praxis bleibt der Quellcode typischerweise verfügbar (z. B. als Archiv), das Projekt wird als Fork weitergeführt, oder das Projekt – und damit der Quellcode – ist schlicht nicht mehr relevant. + +== Anhang A: Referenzen: + +Ein erheblicher Teil der Referenzen ist _bereits in Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung aufgeführt_. + +include::partials/references.de.adoc[tags=ref-em002-7] + +== Anhang B: Glossar + +Dieses Glossar behandelt spezifische Begriffe zu Beschaffungsthemen. + +Das allgemeine Glossar zum Dokumentensatz Em002 findet sich in Em002-6 OSS-FAQ. + +Weitere Begriffe finden sich in der https://www.bk.admin.ch/bk/de/home/dokumentation/sprachen/termdat.html[Terminologiedatenbank TERMDAT der Bundesverwaltung]. + +include::partials/glossary.de.adoc[tags=gloss-em002-7] +endif::[] + +ifeval::["{lang}" == "fr"] +*Clause de non-responsabilité :* 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 {url-repo}/tree/main[README] principal. + +''' + +== L'essentiel en bref + +Le présent document complète le jeu d'outils OSS Em002 par des aspects relatifs aux acquisitions. Il s'appuie sur l'_aide-mémoire sur l'acquisition de logiciels et l'art. 9 LMETA_ publié par le Centre de compétence des marchés publics de la Confédération (CCMP)footnote:[Le Centre de compétence des marchés publics de la Confédération (CCMP) conseille les services d'achat et les services demandeurs sur les questions de droit des marchés publics conformément à l'art. 37 OMP. Adresse électronique centrale pour les demandes : rechtsdienst.kbb@bbl.admin.ch] _[KBB-MB]_ et résume le contenu de documents de l'OFCLfootnote:[L'Office fédéral des constructions et de la logistique (OFCL) est le service central d'achat de la Confédération suisse (art. 5 à 7 OMP). Il procède aux acquisitions dans son domaine de compétence, les regroupe lorsque cela est judicieux et peut conclure des contrats-cadres.] tels que les _directives Open Source dans les acquisitions_ [BBL-WL], qui ne sont disponibles que sur l'intranet.footnote:[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] Le document traite en outre de la souveraineté numérique en tant que critère d'acquisition. + +L'utilisation de logiciels open source peut être divisée en quatre aspects : + +* Consumption : l'utilisation d'OSS préexistants +* Creation : le développement de nouveaux OSS +* Contribution : l'apport de modifications propres à un projet OSS existant +* Collaboration : le développement conjoint d'OSS avec des tiers. + +Dans toutes ces situations, un adjudicateur public doit respecter la législation applicable en matière de marchés publics. + +*Consumption :* + +* Le droit des marchés publics s'applique lorsque des prestations sont achetées sur le marché contre rémunération (art. 8 LMP). + +En d'autres termes : + +* L'utilisation d'OSS disponibles gratuitement (sans redevances de licence, contrats de support ou de maintenance, etc.) ne constitue généralement pas une acquisition. +* Les prestations à valeur ajoutée achetées pour l'utilisation d'OSS (support, garantie, maintenance et développement ultérieur) doivent être acquises conformément au droit des marchés publics. +* Lors de l'acquisition de logiciels, il est en principe admissible d'exiger des OSS, p. ex. lorsque l'unité administrative (UA) en attend des avantages concrets, tels qu'une plus grande souveraineté des données ou un respect simplifié de l'art. 9 LMETA en cas d'adaptations sur mesure prévisibles. Le marché ne doit toutefois pas être indûment restreint. + +*Creation et contribution :* + +* Lors du développement de logiciels ou de composants logiciels, y compris en vue d'une contribution ultérieure à un projet OSS, l'art. 9 LMETA doit toujours être pris en compte. Lorsque des prestations de tiers sont achetées à cette fin, le droit des marchés publics s'applique. +* Lors de contributions à des projets OSS, l'UA transmet son propre travail à des tiers ; ce processus n'est donc pas soumis au droit des marchés publics. +* L'acceptation de contributions de tiers à un projet OSS de la Confédération est également sans problème du point de vue du droit des marchés publics, pour autant qu'aucun paiement ne soit effectué. + +*Collaboration :* + +* La collaboration entre différents adjudicateurs publics sur un projet OSS soulève un large éventail d'exigences juridiques. Du point de vue du droit des marchés publics, les configurations impliquant la fourniture de prestations contre rémunération requièrent un examen attentif. +* Dans une collaboration informelle, chaque partie participante peut acquérir ou fournir des prestations de développement de manière autonome, puis les mettre à disposition gratuitement. Des prestations de coordination peuvent également être fournies ou acquises. +* Dans une collaboration formalisée, p. ex. par le biais d'une association d'acteurs publics, l'organe central peut aussi fournir ou acquérir des prestations de développement, pour autant qu'il soit lui-même soumis au droit des marchés publics. +* Une acquisition commune par des adjudicateurs de différents pays n'est en revanche pas admissible sans autre. + +Pour une utilisation durable des logiciels open source, il est important que les OSS ne soient pas seulement consommés, mais qu'un maximum de parties prenantes contribuent aussi à l'écosystème. Il existe de nombreuses manières de le faire : contributions régulières de code, création de documentation, financement de développeurs, et bien d'autres encore. + +== But et objet + +La loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/fr] exige que des considérations supplémentaires soient prises en compte lors de l'acquisition de logiciels nouvellement développés et de prestations de développement logiciel. + +Pour soutenir le respect de l'art. 9 LMETA, le secteur TNI a élaboré des outils et des ressources dans le cadre des link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] et du link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale] + +include::partials/document-map.fr.adoc[] + +Figure 1 : Vue d'ensemble des outils OSS + +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]. + +Le présent document va au-delà du cœur de l'article 9 LMETA et expose également comment l'open source doit être traité de manière générale dans le contexte des acquisitions. + +Chapitre 3:: L'importance de la souveraineté numérique dans le contexte de l'open source et des acquisitions +Chapitre 4:: Cas d'application pertinents en matière d'acquisition en lien avec les logiciels et les logiciels open source +Chapitre 5:: Creation : appels d'offres pour des logiciels et des prestations en lien avec l'art. 9 LMETA +Chapitre 6:: Consumption : acquisition de logiciels : égalité de traitement des logiciels open source +Chapitre 7:: Consumption : acquisition de prestations supplémentaires (support/maintenance/développement) pour les OSS +Chapitre 8:: Collaboration : aspects de droit des marchés publics des collaborations pour la création, la maintenance et le support d'OSS +Chapitre 9:: Contribution : contributions à des projets OSS + +== Souveraineté numérique et acquisitions + +=== Introduction à la souveraineté numérique et à l'OSS + +Par l'art. 9 LMETA, l'administration fédérale apporte une contribution importante à la durabilité et à la souveraineté numériques en publiant ses logiciels en OSS. + +La souveraineté numérique n'est pas une fin en soi, mais une condition préalable à une administration efficace, démocratique et tournée vers l'avenir. Il s'agit d'un concept à multiples facettes comportant des dimensions technologiques, organisationnelles et politiques. + +**** +*La souveraineté numérique signifie que l'État dispose du contrôle et de la capacité d'action nécessaires dans l'espace numérique afin de garantir l'accomplissement des tâches publiques.* +**** + +Lors de l'acquisition de logiciels en particulier, il convient de tenir compte des implications pour la souveraineté numérique de l'administration fédérale. + +Dans ses *rôles d'utilisatrice, d'exploitante et d'adjudicatrice* dans le domaine des TIC et des logiciels, l'administration fédérale peut assumer consciemment ses responsabilités en la matière. + +Trois objectifs stratégiques existent dans le domaine des logiciels : + +*Interchangeabilité* : [.underline]#en tant qu'utilisatrice#, l'administration publique cherche à pouvoir choisir librement et avec souplesse entre fournisseurs, solutions informatiques et technologies. Cela suppose la disponibilité d'alternatives performantes et éprouvées, ainsi que des architectures informatiques, des filières d'acquisition et des effectifs conçus pour faciliter le changement. + +*Capacité de conception* : [.underline]#en tant qu'exploitante informatique#, l'administration publique a la capacité de façonner et de co-concevoir ses systèmes informatiques. À cette fin, elle dispose des compétences nécessaires et de structures coopératives appropriées pour comprendre et évaluer les solutions informatiques et, si nécessaire, assurer leur développement, leur développement ultérieur et leur exploitation. + +*Influence* : [.underline]#en tant qu'adjudicatrice#, l'administration publique peut formuler et faire valoir ses exigences et ses besoins auprès des fournisseurs de technologies. Cela vaut pour les caractéristiques des produits (fonctions, options d'exploitation, disponibilité, sécurité de l'information et protection des données, etc.) comme pour la rédaction des contrats et les modèles de licence. + +Les *standards ouverts* et les *logiciels open source* soutiennent au mieux ces objectifs grâce aux *principes de l'open source*. + +Les OSS soutiennent la souveraineté numérique de la manière suivante : + +* La sécurité informatique pour l'administration publique, les infrastructures critiques et les applications sensibles peut être assurée [.underline]#à tout moment# grâce à un [.underline]#accès complet# au code source. +* Les OSS permettent aux organismes publics de construire, d'exploiter, de contrôler et d'adapter leur propre infrastructure informatique sans conditions de licence restrictives. +* Les OSS offrent un contrôle complet des mises à jour, des fonctionnalités et des correctifs de sécurité, tant sur le fond que sur le calendrier. +* Les OSS peuvent empêcher la dépendance envers des fournisseurs ou des modèles de licence particuliers et soutiennent l'interchangeabilité. +* Les OSS permettent de représenter et de retracer de manière transparente l'ensemble de la chaîne d'approvisionnement logicielle. +* Les OSS peuvent être adaptés et étendus — bien adaptés aux exigences spécifiques des autorités publiques et des institutions de formation, ce qui suppose toutefois des connaissances approfondies de la part des collaborateurs de l'organisation. +* Les investissements dans les OSS profitent aussi aux entreprises et aux communautés locales (création de valeur locale) et accroissent la résilience de l'économie suisse. +* Les OSS reposent sur la collaboration et des interfaces ouvertes, facilitent l'interopérabilité entre systèmes et favorisent les standards ouverts — également au-delà des frontières nationales. +* Les OSS améliorent la sécurité informatique et la sécurité des données grâce à la transparence et à l'adaptabilité. +* Les logiciels OSS sous licences OSI garantissent des conditions juridiques claires et une continuité, ainsi que les libertés fondamentales de l'OSS, protégeant développeurs et utilisateurs à parts égales. + +*Standards ouverts :* afin de soutenir l'interchangeabilité des logiciels, les appels d'offres publics devraient exiger le respect de standards ouverts,footnote:[Par exemple des standards ouverts tels qu'eCH, ODF ; voir aussi https://fr.wikipedia.org/wiki/Norme_ouverte[Norme ouverte — Wikipédia]] réduisant ainsi au minimum le lock-in. +*Interfaces ouvertes :* les interfaces devraient également être divulguées afin de permettre l'interopérabilité. + +Les autorités fédérales sont en principe tenues de respecter les normes eCH.footnote:[https://www.ech.ch/[www.ech.ch]] + +La Haute école spécialisée bernoise a exposé les considérations déterminantes dans l'étude _Perspectives technologiques de la souveraineté numérique_ [Stü2024], réalisée sur mandat du DFAE, au moyen du modèle de la « maison de la souveraineté », dans lequel le logiciel est présenté comme un pilier essentiel. Dans ce modèle, les couches situées sous le toit — collaboration, compétences technologiques, les quatre piliers et réglementation — sont les domaines dans lesquels les mesures recommandées favorisent la souveraineté numérique. + +[mermaid,align="center",alt="Représentation schématique des aspects de la souveraineté numérique permettant la fourniture de produits et services innovants"] +.... +block-beta + columns 4 + Roof["Produits et services numériques innovants
des entreprises et des autorités"]:4 + space:4 + Collab["Collaboration avec la recherche et la société civile"]:4 + Skills["Compétences technologiques (programmation, science des données, etc.)"]:4 + SW["Logiciels"] Data["Données et
contenus numériques"] AI["Intelligence
artificielle"] Infra["Infrastructure TIC
(matériel)"] + Reg["Réglementation (lois, normes)"]:4 + Collab-- "permettent" -->Roof +.... + +_Figure 2 : Représentation schématique des aspects de la souveraineté numérique permettant la fourniture de produits et services innovants [Stü2024]_ + +=== Mesurer la souveraineté numérique + +Des aspects de souveraineté numérique peuvent être exigés dans un appel d'offres public, mais de telles exigences doivent être objectivement justifiées. Il n'existe pas de préférence générale pour les OSS. + +*Comment mesurer alors le degré de souveraineté numérique pour une technologie, un produit ou un service donné ?* + +Cette opérationnalisation doit être aussi objective et transparente que possible. + +Diverses initiatives s'y emploient. L'OSBA a par exemple développé un **indice de souveraineté**footnote:[https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet[Un indice de souveraineté numérique | OSBA — Open Source Business Alliance]] _[OSBA-VK]_. _Nextcloud_ a publié un Digital Sovereignty Index (DSI),footnote:[https://dsi.nextcloud.com/[dsi.nextcloud.com]] qui compare des pays entiers mais peut aussi fournir des critères utiles. +L'Union européenne a publié un 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]] pour le cloud. +Le _Centre pour la souveraineté numérique ZenDiS_ travaille à un contrôle de souveraineté destiné à évaluer les solutions informatiques et les organisations au regard de critères de souveraineté transparents. + +L'administration fédérale participe également à l'élaboration d'un *cadre de souveraineté numérique* qui permettra notamment de déterminer le degré de réalisation selon différentes perspectives. + +Les perspectives possibles sont : + +A -- Contrôle technologique:: +Dans quelle mesure l'administration fédérale contrôle-t-elle les technologies utilisées et leur développement ultérieur ? + +B -- Souveraineté des données:: +Qui a accès aux données, en a le contrôle et le pouvoir de décision — en particulier pour les données administratives sensibles ? + +C -- Capacité juridique d'action:: +Dans quelle mesure la Suisse et l'administration fédérale peuvent-elles influencer le cadre juridique et politique de la numérisation ? + +D -- Résilience:: +Quelle est la robustesse et la résistance aux crises des systèmes et processus numériques de l'administration fédérale face aux perturbations, aux crises et aux dépendances ? + +E -- Contrôle économique:: +Comment l'administration fédérale peut-elle exercer un contrôle économique et un sourcing stratégique afin d'assurer sa souveraineté numérique de manière économiquement efficace, tout en minimisant les dépendances et les risques dans les acquisitions informatiques ? + +Pour chacune de ces perspectives, le degré de souveraineté numérique peut être déterminé au moyen d'une échelle à définir : + +0 -- Hétéronome / non souverain:: +Aucun contrôle sur les systèmes, les données ou l'infrastructure ; aucune transparence, fortes dépendances ; aucune option de sortie ou de remplacement + +1 -- Contrôle minimal:: +Premières informations sur l'utilisation et les dépendances ; mécanismes de contrôle ponctuels ; des lacunes opérationnelles, juridiques ou technologiques subsistent + +2 -- Utilisable de manière réglementée:: +Systèmes fiables et partiellement pilotables ; cadre juridique et technique établi ; des dépendances stratégiques subsistent + +3 -- Autonome et résilient:: +La position sur le marché est exploitée ; stratégies de sortie et concepts multifournisseurs mis en œuvre ; savoir-faire développé ; résilience et scénarios de crise préparés + +4 -- Souverain sur le plan systémique:: +Souveraineté dans toutes les dimensions pertinentes (juridique, technologique, culturelle, stratégique) ; façonnage actif du marché et des normes ; effet géopolitique possible + +_Figure 3 : Degré de souveraineté numérique._ + +Ces deux dimensions produisent la matrice suivante : + +[.landscape] +[cols="2,^1,^1,^1,^1,^1",options="header"] +|=== +|Perspective +|0 + +Hétéronome +|1 + +Contrôle minimal +|2 + +Utilisable de manière réglementée +|3 + +Autonome et résilient +|4 + +Souverain sur le plan systémique + +|A -- Contrôle technologique +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|B -- Souveraineté des données +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|C -- Capacité juridique d'action +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|D -- Résilience +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|E -- Contrôle économique +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +|=== + +_Figure 4 : Matrice Souveraineté numérique : perspectives et degré de souveraineté._ + +Des critères concrets peuvent être décrits pour les différentes intersections de la grille afin de rendre le classement aussi objectif que possible. + +Un tel cadre est actuellement élaboré dans le cadre de la priorité 4, « Renforcer la souveraineté numérique », de la « Stratégie Administration fédérale numérique ».footnote:[https://www.bk.admin.ch/bk/fr/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html[www.bk.admin.ch — Administration fédérale numérique]] + +Le Conseil fédéral a mis en vigueur au 1er janvier 2026 la directive faîtière Souveraineté numérique au sein de l'administration fédérale.footnote:[W012 - Directives pour la souveraineté numérique au sein de l'administration fédérale] Les projets doivent intégrer les différents aspects dans la définition de l'objet de l'acquisition et, si nécessaire, dans un appel d'offres, sur la base du besoin concret de souveraineté — par exemple sous l'angle des risques dans le cadre de la gestion de la continuité des activités. + +== Cas d'application pour l'acquisition de logiciels + +Les technologies de l'information et de la communication (TIC) et les logiciels ne sont pas une fin en soi au sein de l'administration fédérale, mais servent toujours à accomplir un mandat légal. Compte tenu de la numérisation croissante et du rôle central de l'administration fédérale en Suisse, l'informatique doit être une compétence clé de l'administration. + +Les *facteurs* suivants ont donc une incidence directe sur les acquisitions : + +* *Numérisation* : la stratégie numériquefootnote:[https://digital.swiss/fr/] appelle à la numérisation des processus. +* *Optimisation des processus* : les processus au sein de l'administration fédérale et dans ses relations extérieures peuvent et doivent être optimisés. +* *Souveraineté numérique* : l'importance de la souveraineté numérique ne cesse de croître ; voir _[Stü2024]_. +* Le principe *public money, public goods* et le respect de l'art. 9 LMETA. +* *Liberté économique* : les mesures ne doivent pas restreindre inutilement la liberté économique. +* Considérations générales de *sécurité* : la sécurité des systèmes de traitement de l'information revêt une importance croissante. +* Gestion des crises et des catastrophes (*résilience*) : compte tenu de la situation mondiale actuelle, l'administration doit examiner comment elle peut continuer à fournir les outils de travail nécessaires dans des circonstances critiques. +* Indépendance stratégique et considérations relatives à la *chaîne d'approvisionnement* : elles découlent de la souveraineté numérique et de la résilience. +* Éviter ou réduire au minimum le *vendor lock-in* : les dépendances sont quasiment inévitables en informatique, mais la dépendance envers un fournisseur unique devrait être réduite partout où cela est possible. +* *Renforcement des compétences* de l'administration fédéralefootnote:[Non seulement chez les cadres, les cheffes et chefs de projet et les architectes TIC, mais dans l'ensemble du personnel.] (y compris la direction) en matière de TIC : piloter, développer et exploiter les technologies de l'information exige des compétences appropriées dans l'ensemble du personnel. + +Le présent document distingue les *types de logiciels* suivants : + +* *Commodity — applications spécialisées/branche — applications spécialisées/autorité fédérale* : +** Application standard (logiciel commodity) sans logique métier particulière. +** Application spécialisée : besoin spécifique de la branche/de tous les niveaux fédéraux ou besoin spécifique de l'autorité fédérale +* *Ciblé — stratégique — essentiel* : +** Application ciblée +** Application stratégique revêtant une importance considérable pour une autorité fédérale ou pour l'ensemble de l'administration fédérale +** Essentielle et critique pour l'activité — doit rester fonctionnelle en toutes circonstances (p. ex. contrôle aérien) + +Les applications peuvent être utilisées dans un ou plusieurs *domaines d'application*. + +Ce qui importe ici est la *standardisation* des applications par produit au sein de chaque domaine : + +* Aucune stratégie +* Stratégie mono-produit +* Stratégie multi-produits + +Outre la standardisation des produits, qui doit être examinée avec soin, il existe aussi une standardisation aux fins d'interopérabilité (formats de données, API, éléments métier).footnote:[P. ex. via eCH] +La standardisation _est admissible_ pour autant qu'elle soit proportionnée et ne restreigne pas indûment la concurrence (p. ex. art. 30, al. 3, LMP). Elle peut réduire les coûts d'exploitation et de maintenance et générer des effets de synergie, en particulier lorsque tous les niveaux fédéraux sont impliqués. En revanche, elle accroît le lock-in, la dépendance et, dans certains cas, les risques de sécurité (risque de concentration). + +Le coût total de possession (TCO) — couvrant l'exploitation, la maintenance et le développement ultérieur — devrait toujours être pris en compte lors des acquisitions. Les conséquences financières à long terme ne doivent pas être négligées. Les modèles d'affaires open source diffèrent à certains égards de ceux des fournisseurs propriétaires. + +Les chapitres suivants se concentrent de plus en plus sur l'open source et traitent de l'approche d'acquisition pertinente et de sa mise en œuvre. + +Le choix entre consumption, contribution, collaboration et creation est effectué _au cas par cas selon le projet_, en fonction de l'efficacité économique et de la situation juridique, les coûts étant répartis aussi largement que possible. Dans cette optique, les quatre C tels que définis dans les link:em002.pdf[Em002 Lignes directrices stratégiques OSS], chapitre 3, sont classés par ordre d'importance décroissante : + +image::./assets/four-cs/four-cs.fr.svg[Classement des quatre C : Consumption, Contribution, Collaboration, Creation] + +. Consumption +. Contribution +. Collaboration +. Creation + +Avec la simple *consumption*, les coûts se répartissent sur un grand nombre d'autres utilisateurs, mais l'autorité fédérale n'a aucun contrôle sur le développement ultérieur. La creation est l'inverse : contrôle total, mais coût total. + +Avec la *contribution*, l'engagement financier se limite à l'élément développé, qui est ensuite remis à une autre organisation pour la maintenance. + +La *collaboration* est le scénario le plus complexe, car les arrangements peuvent varier considérablement. Dans le meilleur des cas, les coûts sont partagés et l'autorité fédérale dispose d'une influence suffisante pour mettre en œuvre ses exigences sans compromis (voir chapitre 8). + +Idéalement, la *creation* représente la part la plus faible. Un logiciel peut être développé en interne, par des prestations de services ou par un contrat d'entreprise. + +La consumption pure ne sera réalisable que pour les applications standard. + +=== Un logiciel requiert des prestations supplémentaires telles que maintenance, support et développement ultérieur. + +Bien que les applications open source puissent être utilisées gratuitement, leur déploiement stratégique sur des milliers d'instances requiert maintenance, support et, si nécessaire, développement ultérieur. + +Les autorités fédérales ont un intérêt à un support à long terme des versions déployées (voir chapitre 3.2.3 dans _[BITKOM2024]_). + +L'art. 9 LMETA lui-même ne couvre que le développement ou le développement ultérieur de logiciels en interne et n'est pas déterminant pour d'autres considérations relatives à l'open source — la souveraineté numérique et d'autres facteurs s'appliquent alors. Des restrictions au titre de l'art. 9 LMETA sur des composants de développement isolés peuvent toutefois avoir des répercussions sur l'ensemble du projet lorsque des développements propriétaires ou supplémentaires sont prévisibles. La collaboration peut alors être utilisée pour exploiter des effets de synergie et, si possible, réduire les coûts pour l'ensemble de l'administration fédérale. + +=== Obligation de publication lors de l'acquisition de logiciels + +Lorsque les exigences indiquent un besoin d'adaptation du logiciel, ou un besoin d'adaptation ultérieur potentiel, l'art. 9 LMETA est pertinent et la publication est obligatoire pour ces parties, à moins que l'une des deux exceptions ne s'applique. Lors de l'acquisition d'une solution open source, une telle publication serait déjà couverte par une contribution au projet open source. Même lorsque l'acquisition ne porte que sur la licence d'un logiciel standard ou sur une acquisition TIC relevant d'une exception, les développements supplémentaires doivent en principe être publiés, ce qui doit se refléter dans les documents d'acquisition et le projet de contrat. + +*L'obligation de publication prévue à l'art. 9 LMETA est donc pertinente pour toute acquisition dans laquelle un développement propre ou un développement ultérieur est probable* (voir aussi _[KBB-MB]_). + +== Creation : appels d'offres pour des logiciels et des prestations relevant de l'article 9 LMETA + +Ce chapitre traite des implications de l'art. 9 LMETA pour les appels d'offres portant sur des logiciels et des prestations pouvant impliquer la création ou la modification de logiciels. + +Il s'applique tant à l'administration fédérale centrale que décentralisée. Les exceptions à cette obligation sont fixées dans l'ordonnance sur la numérisation _[DigiV]_. + +=== Pertinence de l'article 9 LMETA pour la création de logiciels + +Une opération entre dans le champ d'application de l'art. 9 LMETA si elle relève de la catégorie déterminante du tableau 1. La décision « make or buy » reste centrale pour les acquisitions. L'analyse des différents cas d'application montre qu'en principe l'art. 9 LMETA est pertinent dans tous les cas, sauf lorsqu'un logiciel préexistant est acquis (p. ex. licences pures). Le chapitre II.4 des _directives Open Source dans les acquisitions [BBL-WL]_ expose l'approche stratégique, et l'annexe VII.A décrit en détail ce qui constitue un logiciel. Une ventilation détaillée de la décision stratégique figure au tableau 1. + +[cols="3,2,4",options="header"] +|=== +|Cas d'application |Make or buy |Obligation de publication selon l'art. 9, al. 1, LMETA + +|Développer un logiciel au sein de l'administration fédérale +|Make +|Oui, obligation de publication + +|Faire développer un logiciel par des tiers +|Buy, sous forme de contrat de prestations informatiques +|Oui, obligation de publication + +|Acquérir un logiciel existant +|Buy +a|En principe non, mais vérifier si des obligations de publication s'appliquent aux parties développées. Le traitement des droits de tiers est particulièrement pertinent (voir link:em002-3.pdf[Em002-3 Guide de licences OSS]). + +|Reprendre un logiciel d'autres organismes publics +|Make ou buy +a|— Au sein de l'administration fédérale : obligation de publication pour l'unité administrative cédante. + +— Autres : examiner au cas par cas si les adaptations effectuées par l'administration fédérale créent une obligation de publication, au moins pour ces parties. + +|Acquérir des ressources de développement +|Make +|Oui, obligation de publication (les contrats doivent permettre la publication) + +|Collaborer avec d'autres organismes publics au développement de logiciels +|Make +|Oui, obligation de publication (les contrats doivent permettre la publication), en particulier en cas de contributions de développement substantielles par ou pour la Confédération +|=== + +_Tableau 1 : Classification de l'obligation de publication et de la décision « make or buy » (d'après un tableau de Rika Koch, BFH)_ + +Remarque : l'art. 9 LMETA doit aussi être pris en compte pour les logiciels existants et les SaaS lorsque le logiciel doit être développé ou adapté pour la Confédération. Même lorsque la probabilité en est faible, cela devrait être traité dans le processus d'acquisition. + +Lorsqu'une clarification est nécessaire, la référence recommandée est link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source]. Les listes de contrôle devraient être *remplies provisoirement le plus tôt possible* pour les projets potentiellement concernés. La _liste de contrôle pour l'exception forfaitaire selon l'art. 9 LMETA [BBL-CL]_ peut également être utilisée à cette fin. + +=== Préparer une acquisition au sens de l'article 9 LMETA + +Outre les étapes préparatoires habituelles, les deux documents suivants devraient être consultés chaque fois qu'une acquisition comporte des composants logiciels : + +* _aide-mémoire sur l'acquisition de logiciels et l'art. 9 LMETA [KBB-MB] et_ +* _directives Open Source dans les acquisitions [BBL-WL]_. + +Lorsque l'art. 9 LMETA est clairement pertinent, l'unité administrative devrait avoir : + +* rempli provisoirement les listes de contrôle link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Évaluation préalable OSS] à link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Validation et publication OSS] ; +* pris une décision de principe sur l'utilisation d'une licence copyleft ou permissive ;footnote:[Une analyse plus détaillée peut être effectuée ultérieurement au moyen du _Em002-3 Guide de licences OSS_ si nécessaire.] +* recherché d'éventuelles alternatives open source (ou des projets de base potentiels pour des contributions ou une collaboration) conformément à link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source], au moyen des outils qui y sont indiqués pour la recherche et l'analyse de marché ;footnote:[Voir aussi link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale], chapitre 7.] +* clarifié la structure d'une éventuelle communauté (link:em002-4.pdf[Em002-4 Guide des communautés OSS] et link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle Communauté OSS]). + +Lorsqu'un projet OSS existant doit être utilisé, soutenu ou servir de base à une collaboration, les chapitres 5, 6, 8 et 9 du présent document doivent être lus. + +=== Creation via des contrats de prestations existants + +Lorsque la creation passe par des contrats de partenariat existants, la publication OSS doit être assurée au stade du mini-appel d'offres, à moins que l'une des deux exceptions ne s'applique. + +Les nouveaux appels d'offres de prestations devraient toujours comporter une exigence de publication conformément à l'art. 9 LMETA (voir _[BBL-WL] et_ _[KBB-MB])_. + +=== Constituer une communauté + +Constituer et entretenir une communauté maximise les bénéfices des logiciels open source, mais représente aussi une charge considérable. + +Lorsqu'une communauté et une collaboration sont judicieuses, cela a des implications pour l'acquisition dès le départ. La link:em002-4-1-checklist-oss-community.pdf[liste de contrôle Em002-4.1 Communauté OSS] devrait donc être remplie sur la base du link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +Lorsque l'autorité fédérale doit assumer un rôle important dans la communauté (p. ex. un rôle de gouvernance) ou lorsqu'une collaboration est prévue (voir chapitre 8), il peut être nécessaire d'acquérir des prestations supplémentaires : constitution de la communauté, consolidation des exigences, pilotage du développement ultérieur. + +=== Critères types et éléments contractuels pour les acquisitions informatiques + +Le CCMP tient à jour un modèle de critères d'acquisition possibles ainsi qu'un modèle de chapitre de contrat-cadre pour les appels d'offres portant sur des logiciels _[KBB-KV]_. + +Le CCMP a publié deux documents types sur Perimap.admin.ch montrant comment les exigences minimales d'une adjudication conforme au droit des marchés publics au sens de l'art. 9 LMETA peuvent être satisfaites. [KBB-KV] + +. https://perimap.admin.ch/goto_perimap_file_47064_download.html[Critères types — Acquisition LMETA et open source] +. https://perimap.admin.ch/goto_perimap_file_47059_download.html[Textes contractuels types — Développement logiciel] + +== Consumption : acquisition de logiciels : égalité de traitement des logiciels open source + +Ce chapitre traite de l'acquisition et de l'utilisation (consumption) de logiciels open source et met en évidence les principaux aspects stratégiques. +Il est également renvoyé à _[BBL-WL] et_ _[KBB-MB]_. + +*Il n'existe actuellement aucune préférence légalement prescrite pour les logiciels open source dans les acquisitions.* + +Lors d'appels d'offres portant sur des applications informatiques, tous les types de licence et modèles d'affaires sont pris en compte. Pour satisfaire aux exigences formulées, les fournisseurs peuvent proposer des solutions logicielles fondées sur des logiciels open source non modifiés, propriétaires ou closed source, ou sur des combinaisons de modèles de licence et de prestations à valeur ajoutée ou d'abonnements. + +Les points suivantsfootnote:[Les documents de référence déterminants en matière d'acquisition sont ceux publiés par l'OFCL et le CCMP sur les plateformes correspondantes.] devraient être pris en compte par les autorités fédérales : + +* Indépendamment de sa solution et de son modèle de licence, le prestataire doit indiquer dans son offre *quelles conditions de licence le service acquéreur doit respecter lors de l'utilisation de la prestation*. +* Le prestataire est *libre de choisir la solution* avec laquelle il entend satisfaire aux exigences mises au concours ainsi que la forme de rémunération qu'il souhaite percevoir (redevances de licence, de maintenance ou d'abonnement), pour autant que cela soit techniquement réalisable et économiquement raisonnable. +* L'ensemble du *cycle de vie* devrait être pris en compte dans les spécifications et la tarification. + +Cela permet à l'administration fédérale de faire valoir ses intérêts en matière de propriété intellectuelle, de garantie et de responsabilité — indépendamment du logiciel ou du modèle de licence — au niveau des conditions générales applicables et de les ancrer dans le contrat. + +Lorsque des *adaptations logicielles* sont effectuées sur mandat ou en exécution d'un contrat avec l'autorité fédérale, l'art. 9 LMETA s'applique. +Par précaution, l'autorisation de publication devrait être demandée dès l'appel d'offres, l'expérience montrant que des adaptations s'avèrent tôt ou tard nécessaires, même si elles ne sont pas prévisibles au moment de l'appel d'offres. + +Lorsque le service acquéreur acquiert auprès d'un fournisseur des *prestations à valeur ajoutée* en plus du logiciel, les fournisseurs OSS proposent souvent un modèle d'abonnement offrant un interlocuteur local assorti d'engagements de garantie et de responsabilité, en sus de la relation directe avec les titulaires des droits de propriété intellectuelle sur les composants OSS (souvent établis à l'étranger et parfois inconnus). + +=== L'OSS comme critère stratégique d'acquisition + +Lorsqu'une autorité fédérale souhaite acquérir un logiciel open source pour des raisons stratégiques, plusieurs scénarios sont possibles : + +* Appel d'offres fonctionnel sans critères spécifiques à l'OSS. +Comme cela n'implique aucune restriction, aucune justification particulière n'est nécessaire. +* Appel d'offres fonctionnel assorti d'un critère d'aptitude, de critères techniques et de critères d'adjudication exigeant l'open source, un accès complet au code source ou une expérience démontrable en matière de publication open source. + +*Toute préférence pour l'open source est admissible au regard du droit des marchés publics lorsqu'elle permet de (mieux) répondre aux besoins concrets du service adjudicateur*.footnote:[Voir [BBL-WL\], [BBL-CL\], [KBB-MB\], [KBB-KV\]] + +Une autre raison de privilégier l'OSS — au-delà de la souveraineté numérique — tient au fait que lorsque l'administration requiert des adaptations logicielles importantes, celles-ci doivent être publiées en vertu de l'art. 9 LMETA. +La publication est la plus simple lorsque l'ensemble du produit a toujours été open source et que les adaptations peuvent dans certains cas être effectuées directement dans le produit. À défaut, une exception doit être définie et, si nécessaire, des parties du code doivent être isolées puis publiées malgré tout. + +=== L'utilisation gratuite d'OSS n'est pas soumise au droit des marchés publics. + +Les OSS peuvent souvent être téléchargés et utilisés directement. Le droit des marchés publics ne s'applique que lorsque des prestations sont obtenues de tiers contre rémunération (y compris des contreparties non monétaires). + +Le téléchargement et l'utilisation gratuits d'OSS ne constituent pas en soi une acquisition. + +Il est aussi possible d'acquérir ultérieurement les prestations nécessaires pour des OSS téléchargés, pour autant que cela ne se fasse pas de manière abusive.footnote:[Analogie : une commune peut utiliser son propre bois et commander la construction d'un dépôt d'entretien avec ce bois — elle n'est pas tenue d'acquérir elle-même le bois.] + +Les prestations de maintenance, de support et de développement ultérieur du produit font ensuite l'objet d'un appel d'offres distinct conformément au droit des marchés publics. + +Il existe déjà des exemples d'OSS utilisés gratuitement sur les postes de travail standard de l'administration fédérale et donc non acquis.footnote:[Exemples d'OSS à potentiel de standardisation : Gimp, FileZilla, VLC Media Player et 7-zip en tant que produits Shell 2 (selon [A029\]), qui peuvent être utilisés parce que l'installation est gratuite. En 2024, l'OFIT a désigné Red Hat OpenShift comme produit stratégique pour certains domaines d'application en raison de ses caractéristiques techniques uniques. OpenShift est actuellement la plateforme stratégique pour les conteneurs et les systèmes d'exploitation.] + +=== Coordonner les exigences avec d'autres parties prenantes + +Une application spécialisée requiert toujours un porteur de besoin (généralement un office fédéral). Il est en règle générale judicieux que l'entité ayant le besoin harmonise ses exigences avec celles d'autres services publics — soit en interne, soit dans le cadre d'une collaboration (voir chapitre 8) — dans la mesure où un produit disponible sur le marché ou un développement conjoint favorise le développement et le déploiement. + +Lorsque de nombreuses parties prenantes ont des exigences identiques ou similaires, il peut valoir la peine de répondre à ces besoins sur une base commune. Cela vaut pour toutes les formes de logiciels. + +Deux aspects sont à relever : lorsque des adaptations sont ensuite effectuées par une autorité fédérale à la demande de tiers, l'art. 9 LMETA s'applique à nouveau — ce qui ne pose toutefois pas de problème lorsqu'un logiciel open source est utilisé. + +Avec les OSS, les exigences doivent parfois être harmonisées plus activement par l'autorité fédérale, car il peut n'y avoir aucune force motrice telle qu'un fournisseur commercial cherchant à piloter et à développer son propre produit. + +=== Prendre en compte d'autres acteurs publics potentiels lors de l'acquisition + +L'exemple de ZenDiSfootnote:[https://www.zendis.de/en[https://www.zendis.de/] ZenDiS s'est donné pour mission de permettre à l'administration de se libérer de dépendances critiques envers des fournisseurs de technologies isolés.] montre qu'il peut être à la fois réalisable et payant de lancer un appel d'offres couvrant simultanément tous les niveaux fédéraux. + +*Une concurrence équitable doit toujours être préservée.* Lors du lancement d'appels d'offres, il convient toujours d'examiner si la solution pourrait utilement être acquise également pour d'autres entités. + +Si tel est le cas, ces clients supplémentaires potentiels devraient être contactés et leurs besoins reflétés dans les documents d'appel d'offres, en particulier dans les exigences. Une certaine souplesse dans les exigences est importante dans de tels cas. + +Exemple : eOperations Suisse SA (http://www.eoperations.ch[www.eoperations.ch]) peut être utilisée pour de telles collaborations. eOperations consolide les exigences de différents services et procède elle-même à l'acquisition, sans nécessairement utiliser le produit elle-même. Cela peut aussi constituer un modèle utile pour l'acquisition d'OSS. + +== Consumption : acquisition de support et de maintenance pour les OSS + +L'administration publique peut utiliser des logiciels open source de diverses manières, du simple téléchargement et installation jusqu'à une acquisition formelle (voir chapitre 6.2). + +Lorsque des OSS sont déployés dans des domaines critiques, des standards élevés et constants de sécurité,footnote:[Voir aussi link:em002-6.pdf[Em002-6 FAQ-OSS], chapitre 5.3] de maintenance et de développement ultérieur sont requis. Dans une acquisition de logiciel ordinaire, cela est généralement couvert par l'appel d'offres. Les exigences s'appliquent tant au logiciel lui-même qu'aux bibliothèques et frameworks utilisés. Le support et la maintenance méritent une attention particulière, le développement ultérieur étant souvent couvert par le même contrat et constituant de toute façon de la creation, relevant ainsi du champ d'application de l'art. 9 LMETA. + +Ces prestations à forte intensité de main-d'œuvre dépassent presque toujours la valeur seuil de la loi fédérale sur les marchés publics (LMP) lorsqu'elles sont calculées sur l'ensemble du cycle de vie de l'application. Lorsqu'elles sont achetées auprès de tiers, le droit des marchés publics doit être respecté. Des exceptions peuvent s'appliquer, par exemple l'acquisition intra-étatique auprès d'un autre adjudicateur public,footnote:[Art. 10, al. 3, let. b, LMP.] ou, dans des cas exceptionnels, l'acquisition de gré à gré de prestations spécialisées.footnote:[Art. 21, al. 2, let. c, LMP.] + +Le tableau suivant présente les distinctions de cas pour l'acquisition de prestations telles que le support. + +[cols="1,1,1,2"] +|=== +2+h|Situation initiale 2+h|Résultats + +h|Coûts du cycle de vie + +→ valeur seuil OMC ?footnote:[Les coûts internes peuvent être exclus. L'ensemble du cycle de vie doit être pris en compte.] +h|Intra-étatique ?footnote:[L'acquisition intra-étatique n'est pas soumise à appel d'offres : portage étatique requis, pas de participation au marché. Ne s'applique qu'au sein du secteur public suisse.] +h|Appel d'offres OMC requis ?footnote:[Les directives fédérales en matière d'acquisition s'appliquent toujours dès qu'un paiement est effectué.] +h|Remarques + +|Non +|Non +|Non footnote:[Un logiciel avec support dépasse généralement la valeur seuil LMP ; « non » ne s'appliquera que dans de rares cas (p. ex. financement d'une seule fonctionnalité pour un projet OSS existant).] +.2+|Rarement un progiciel complet avec support — le plus souvent un support mineur et des fonctionnalités isolées. + +|Non +|Oui +|Non + +|Oui +|Non +|Oui +|Seul le volume destiné à des tiers est déterminant. + +|Oui +|Oui +|Non +|L'appel d'offres a été lancé par l'autre organisme public. +|=== + +_Tableau 2 : Distinction de cas — acquisition de support_ + +=== Le support et la maintenance font toujours partie du logiciel + +Le support et la maintenance sont essentiels à l'exploitation durable d'un logiciel dans un environnement administratif. Dans un monde d'exploits zero-day,footnote:[Un exploit zero-day désigne l'exploitation d'une faille de sécurité pour laquelle aucun correctif n'est encore disponible auprès du développeur du composant.] le déploiement rapide et professionnel des correctifs est déterminant. Cette « infrastructure » doit être financée — d'autant que l'administration a des exigences plus élevées qu'un consommateur privé. + +*La question n'est donc pas SI le support et la maintenance seront nécessaires, mais COMMENT ils seront assurés.* + +L'autorité fédérale doit déterminer le niveau de support, de maintenance, de garantie et de responsabilité dont elle a besoin en fonction de ses exigences de qualité de service. + +Il est important que tout prestataire chargé de la maintenance et du support puisse démontrer une expérience suffisante du produit ou de la communauté open source concernée — ce n'est qu'alors qu'il sera en mesure de remplir efficacement ces tâches (voir aussi _[KBB-MB]_, II.5).footnote:[Le contrat de prestations devra peut-être aussi couvrir le transfert éventuel de connaissances à une organisation successeure.] + +Le support et la maintenance doivent aussi être financés au niveau du produit. Lorsque personne ne contribue (le problème du passager clandestinfootnote:[https://fr.wikipedia.org/wiki/Passager_clandestin_(%C3%A9conomie)]), l'avenir du projet est compromis, et avec lui son utilisation au sein de l'administration fédérale. Compte tenu de sa taille, on peut raisonnablement attendre de l'administration fédérale qu'elle contribue aux coûts des logiciels qu'elle déploie de manière stratégique. + +=== Organisations pouvant fournir un support + +La qualité du support a une incidence directe sur la satisfaction et la productivité des utilisateurs finaux. Un système de support structuré, offrant des temps de réponse rapides et une véritable expertise technique, garantit que les utilisateurs et les administrateurs obtiennent des solutions efficaces à leurs problèmes, ce qui économise du temps de travail à l'adjudicateur et favorise l'acceptation de la solution logicielle. + +Pour respecter les temps de réponse convenus contractuellement dans les service level agreements (SLA), le fournisseur doit disposer de personnel qualifié possédant les compétences nécessaires. + +Les sources de support possibles sont : + +*En interne* : + +* Offices fédéraux +* Prestataires + +*Intra-étatique* : + +* Autres adjudicateurs publics en Suisse +* Prestations acquises par d'autres adjudicateurs publics en Suisse + +*Tiers* : + +* Prestation acquise + +=== Développement ultérieur pour des fonctionnalités spécifiques + +Lorsqu'une autorité fédérale n'a besoin que d'un nombre limité d'améliorations spécifiques d'un logiciel open source, cela peut être réalisé avec des ressources internes ou des prestations acquises. + +De tels développements ultérieurs devraient viser à être proposés au projet d'origine et à y être intégrés. Cela profite non seulement à l'écosystème du projet, mais garantit que les améliorations continueront d'être maintenues au sein du projet. À défaut, chaque nouvelle version du projet d'origine peut exiger une mise à jour manuelle du développement sur mesure (voir aussi chapitre 8). + +=== Abonnement + +De nombreuses entreprises et projets du milieu open source offrent un support gratuit dans certaines limites, fourni volontairement par n'importe quel utilisateur, principalement via des canaux ouverts tels que des forums et des systèmes de tickets publics. Cette offre gratuite n'est pas conçue pour des utilisateurs professionnels ayant des exigences SLA spécifiques. + +Pour les utilisateurs professionnels tels que les autorités fédérales, des abonnements OSS incluant garantie, maintenance et support sont souvent disponibles. + +Certains fournisseurs proposent aussi des « versions entreprise » spéciales qui ne répondent plus aux critères open source de l'OSI. + +Exemples d'abonnements : OpenShift de Red Hat, openDesk de ZenDiS + +=== Certifications dans le domaine de l'open source et OpenChain + +Comme pour les logiciels propriétaires, diverses certifications existent dans le domaine de l'open source. Il peut être utile pour l'administration de vérifier, avant de lancer un appel d'offres, l'existence de certifications potentiellement pertinentes dans le domaine concerné. + +*OpenChain* est une norme ISO portant sur le développement open source et la compatibilité des licences (voir ci-dessous). + +Lorsque des certifications pertinentes existent et sont déterminantes pour la prestation, elles devraient être prises en compte dans l'évaluation des fournisseurs. Il importe que la certification elle-même soit jugée significative et que les fournisseurs puissent démontrer qu'ils sont en mesure de fournir la prestation même sans certification. + +Compte tenu de la complexité en jeu, exiger des certifications comme critère d'aptitude n'est pas recommandé. Comme critère d'adjudication — avec la possibilité de démontrer par des références le respect du contenu de la certification — elles peuvent être appropriées selon le produit OSS, pour autant qu'il soit admissible d'utiliser des références pour prouver que les critères de certification sont satisfaits.footnote:[Remarque : exiger une certification excessive ou mal adaptée à l'objet de l'appel d'offres produira inévitablement des offres moins compétitives.] + +Une autocertification OpenChain peut tout au plus servir de substitut lorsqu'aucune autre certification n'existe. Des références couvrant les critères déterminants peuvent également remplacer des certifications manquantes. + +*Certification des entreprises partenaires* + +Certains développeurs et projets open sourcefootnote:[tels que Nextcloud ou Univention] certifient les entreprises partenaires avec lesquelles ils collaborent. De telles certifications peuvent attester d'une relation existante entre le fournisseur et le développeur du logiciel. Il convient de noter que de nombreux projets OSS ne proposent pas de telles certifications. Une collaboration avérée dans des projets de référence est un indicateur tout aussi valable — et moins restrictif — de la qualité recherchée. + +*Certification des collaborateurs* + +Certains fabricants ou communautés open sourcefootnote:[tels que LibreOffice ou RedHat] certifient des personnes disposant d'une expertise spécialisée dans le logiciel concerné. Lorsqu'un prestataire emploie du personnel certifié, cela peut démontrer une expertise dans la publication upstream d'adaptations et de correctifs ainsi que dans la fourniture d'un support de troisième niveau de qualité — en particulier lorsque plusieurs collaborateurs travaillent avec le produit. Cela dépend aussi de la structure de l'écosystème du projet OSS. + +En guise d'alternative aux certifications, une expérience de projet démontrable dans des références relatives à l'objet de l'acquisition peut également servir de critère de différenciation. + +*Standard OpenChain* + +Le standard OpenChain représente à la fois une bonne pratique en matière de compatibilité des licences et une certification intéressante pour les services adjudicateurs. + +La norme ISO/IEC 5230 « OpenChain » se concentre sur les chaînes d'approvisionnement logicielles, la simplification des acquisitions et la conformité des licences. Le standard OpenChain peut être attribué par un organisme de certification accrédité ou obtenu par autocertification. Cette certification convient pour démontrer de manière générale qu'un fournisseur s'est déjà penché en profondeur sur les exigences des licences open source et sur les spécificités de l'écosystème open source. +L'établissement d'une Software Bill of Materials (SBOM) faisant partie du standard, cette certification atteste également de l'engagement d'un fournisseur en faveur de la sécurité de la chaîne d'approvisionnement par le soutien de composants fondamentaux. + +=== Autres possibilités d'acquérir des prestations de maintenance, de support ou de développement + +Il est judicieux de traiter les prestations de développement ultérieur dans le même contrat que le support et la maintenance, la distinction n'étant pas toujours évidente et souvent peu praticable dans le contexte des logiciels open source. Les développements ultérieurs financés par une autorité fédérale relèvent du champ d'application de l'art. 9 LMETA. + +Les possibilités suivantes sont actuellement disponiblesfootnote:[D'autres possibilités, plus marginales, peuvent également exister.] pour acquérir des prestations de support, de maintenance et/ou de développement ultérieur pour les OSS : + +* En interne, avec renforcement des compétences : recourir à ses propres ressources de développement +* Acquisition : selon le volume et dans le respect de la LMP. Cela peut aussi se faire via des contrats de prestations déjà mis au concours. Afin que des partenaires stratégiques puissent fournir des développeurs principaux expérimentés pour des projets OSS centraux pour l'administration fédérale, il peut être utile d'autoriser la sous-traitance ou d'exiger l'expertise correspondante dans certains appels d'offres. +* Accords de coopération avec des tiers pour la maintenance, le support ou le développement ultérieur : sans problème tant que chaque partie supporte ses propres coûts. +* Participation de la Confédération à des organisations : sans problème tant que chaque partie supporte ses propres coûts. + +== Collaboration : aspects de droit des marchés publics de la création, de la maintenance et du support conjoints d'OSS + +Les coûts des logiciels open source diminuent lorsqu'ils sont développés en commun, que ce soit de manière informelle ou dans un cadre structuré. Le link:em002-4.pdf[Em002-4 Guide des communautés OSS] expose les approches pertinentes. + +La collaboration avec d'autres adjudicateurs publics ou avec des tiers ne pose pas de problème au regard du droit des marchés publics tant que chaque partie supporte ses propres coûts. Des difficultés apparaissent lorsque la collaboration n'aboutit pas à un OSS, l'administration fédérale étant liée par l'art. 9 LMETA. + +Une telle coopération est admise par l'art. 4 LMETA. + +La question du traitement des frais généraux ou d'une structure centralisée doit être réglée : la structure a besoin d'un financement suffisant pour porter le projet à travers les périodes difficiles. Une alternative consiste en un partenaire gestionnaire unique (p. ex. si un participant est suffisamment grand pour assumer le rôle de coordination). Lorsque l'autorité fédérale assume ce rôle, les prestations correspondantes doivent être fournies en interne ou mises au concours de la manière habituelle si des tiers doivent être mandatés. + +Au niveau contractuel, ce qui suit s'applique aux collaborations : + +* Lorsqu'aucun argent ne circule et qu'aucune obligation formelle n'est requise, un Memorandum of Understanding au niveau de l'office fédéral ou de la Chancellerie fédérale est possible. +* La création d'une structure commune — telle qu'une association ou une corporation de droit public — est possible en principe mais doit être évaluée au cas par cas. Lorsque la structure commune doit elle-même acquérir des prestations auprès de tiers, l'application du droit des marchés publics doit être réglée. + +L'adhésion peut dans certains cas être exercée par l'intermédiaire d'autres organisations telles qu'eOperations ou eCH. + +*Coopération avec l'étranger* + +La coopération avec des autorités étrangères ne pose pas de problème tant qu'aucun argent ne circule et qu'aucune obligation d'aucune sorte n'est contractée. + +Des accords de coopération au niveau approprié sont possibles en principe mais doivent être évalués au cas par cas. +Les traités internationaux devraient être évités compte tenu des obstacles élevés qu'ils impliquent, bien qu'ils soient en principe également possibles. + +Il existe deux cas particuliersfootnote:[https://www.eda.admin.ch/deza/fr/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] dans lesquels la collaboration serait déjà couverte : + +* Les marchés adjugés en vertu d'un accord international en vue de la réalisation conjointe d'un projet par des États signataires. +* Les marchés adjugés conformément aux procédures ou conditions particulières d'une organisation internationale. + +== Contribution : contributions à des projets OSS + +La plupart des caractéristiques et considérations juridiques relatives aux contributions sont traitées dans le link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +Du point de vue du droit des marchés publics, les contributions ne posent généralement pas de problème, les prestations étant fournies pour développer du code destiné à un projet qui est soit directement pertinent pour l'autorité, soit déjà traité sous l'angle du droit des marchés publics. + +*Les contributions de tiers à des projets OSS menés par des autorités fédérales ne posent pas non plus de problème au regard du droit des marchés publics, tant qu'aucun argent ne circule.* + +Remarque : l'autorité fédérale étant tenue de publier les logiciels qu'elle développe, elle doit aussi veiller à ce qu'ils restent publiés. Si un projet OSS est retiré par ses exploitants, l'autorité fédérale devra dans le pire des cas le republier de manière autonome. Dans la pratique, le code source reste typiquement disponible (p. ex. sous forme d'archive), le projet se poursuit sous forme de fork, ou le projet — et avec lui le code source — est simplement devenu sans objet. + +== Annexe A : Références : + +Une part importante des références est _déjà mentionnée dans les Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale_. + +include::partials/references.fr.adoc[tags=ref-em002-7] + +== Annexe B : Glossaire + +Ce glossaire couvre les termes spécifiques liés aux thèmes des acquisitions. + +Le glossaire général du jeu de documents Em002 figure dans Em002-6 FAQ-OSS. + +D'autres termes figurent dans la https://www.bk.admin.ch/bk/fr/home/dokumentation/sprachen/termdat.html[banque de données terminologiques TERMDAT de l'administration fédérale]. + +include::partials/glossary.fr.adoc[tags=gloss-em002-7] +endif::[] + +ifeval::["{lang}" == "it"] +*Avvertenza:* 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 {url-repo}/tree/main[README] principale. + +''' + +== L'essenziale in breve + +Il presente documento completa la serie di strumenti OSS Em002 con aspetti relativi agli acquisti. Si fonda sul _promemoria sull'acquisto di software e l'art. 9 LMeCA_ pubblicato dal Centro di competenza per gli acquisti pubblici della Confederazione (CCAP)footnote:[Il Centro di competenza per gli acquisti pubblici della Confederazione (CCAP) consiglia i servizi d'acquisto e i servizi richiedenti sulle questioni di diritto degli acquisti pubblici conformemente all'art. 37 OAPub. Indirizzo e-mail centrale per le richieste: rechtsdienst.kbb@bbl.admin.ch] _[KBB-MB]_ e riassume il contenuto di documenti dell'UFCLfootnote:[L'Ufficio federale delle costruzioni e della logistica (UFCL) è il servizio centrale d'acquisto della Confederazione Svizzera (art. 5–7 OAPub). Effettua acquisti nel proprio ambito di competenza, li aggrega ove opportuno e può concludere contratti quadro.] quali le _direttive Open Source negli acquisti_ [BBL-WL], disponibili soltanto sull'intranet.footnote:[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] Il documento tratta inoltre la sovranità digitale quale criterio d'acquisto. + +L'impiego di software open source può essere suddiviso in quattro aspetti: + +* Consumption: l'utilizzo di OSS preesistenti +* Creation: lo sviluppo di nuovi OSS +* Contribution: l'apporto di adattamenti propri a un progetto OSS esistente +* Collaboration: l'ulteriore sviluppo congiunto di OSS con terzi. + +In tutte queste situazioni un committente pubblico deve rispettare la legislazione applicabile in materia di acquisti pubblici. + +*Consumption:* + +* Il diritto degli acquisti pubblici si applica quando prestazioni sono acquistate sul mercato dietro rimunerazione (art. 8 LAPub). + +In altre parole: + +* L'utilizzo di OSS disponibili gratuitamente (senza tasse di licenza, contratti di supporto o manutenzione ecc.) non costituisce di regola un acquisto. +* Le prestazioni a valore aggiunto acquistate per l'utilizzo di OSS (supporto, garanzia, manutenzione e sviluppo ulteriore) devono essere acquistate conformemente al diritto degli acquisti pubblici. +* Nell'acquisto di software è in linea di principio ammissibile richiedere OSS, p. es. quando l'unità amministrativa (UA) se ne attende vantaggi concreti, come una maggiore sovranità dei dati o un rispetto semplificato dell'art. 9 LMeCA in presenza di adattamenti su misura prevedibili. Il mercato non deve però essere indebitamente ristretto. + +*Creation e contribution:* + +* Nello sviluppo di software o componenti software, anche in vista di un successivo contributo a un progetto OSS, l'art. 9 LMeCA va sempre considerato. Se a tal fine sono acquistate prestazioni di terzi, si applica il diritto degli acquisti pubblici. +* Nei contributi a progetti OSS l'UA trasmette il proprio lavoro a terzi; tale processo non sottostà quindi al diritto degli acquisti pubblici. +* L'accettazione di contributi di terzi a un progetto OSS della Confederazione è parimenti priva di problemi sotto il profilo del diritto degli acquisti pubblici, purché non venga effettuato alcun pagamento. + +*Collaboration:* + +* La collaborazione tra diversi committenti pubblici a un progetto OSS solleva un'ampia gamma di requisiti giuridici. Sotto il profilo del diritto degli acquisti pubblici, le configurazioni che comportano la fornitura di prestazioni dietro rimunerazione richiedono un esame accurato. +* In una collaborazione informale ciascuna parte partecipante può acquistare o fornire autonomamente prestazioni di sviluppo e metterle poi a disposizione gratuitamente. Possono parimenti essere fornite o acquistate prestazioni di coordinamento. +* In una collaborazione formalizzata, p. es. mediante un'associazione di attori pubblici, anche l'organo centrale può fornire o acquistare prestazioni di sviluppo, purché sia esso stesso soggetto al diritto degli acquisti pubblici. +* Un acquisto congiunto da parte di committenti di Paesi diversi non è invece ammissibile senza altro. + +Per un impiego sostenibile del software open source è importante che gli OSS non siano soltanto consumati, ma che il maggior numero possibile di parti interessate contribuisca anche all'ecosistema. Vi sono molti modi per farlo: dai contributi regolari di codice alla creazione di documentazione, fino al finanziamento di sviluppatori e molto altro. + +== Scopo e obiettivo + +La legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/it] esige che nell'acquisto di software di nuovo sviluppo e di prestazioni di sviluppo software siano considerati aspetti supplementari. + +Per sostenere il rispetto dell'art. 9 LMeCA, il settore TDT ha elaborato strumenti e risorse nell'ambito delle link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] e della link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale] + +include::partials/document-map.it.adoc[] + +Figura 1: Panoramica degli strumenti OSS + +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]. + +Il presente documento va oltre il nucleo dell'articolo 9 LMeCA ed espone inoltre come trattare in generale l'open source nel contesto degli acquisti. + +Capitolo 3:: L'importanza della sovranità digitale nel contesto dell'open source e degli acquisti +Capitolo 4:: Casi d'applicazione rilevanti in materia di acquisti in relazione al software e al software open source +Capitolo 5:: Creation: bandi per software e prestazioni in relazione all'art. 9 LMeCA +Capitolo 6:: Consumption: acquisto di software: parità di trattamento del software open source +Capitolo 7:: Consumption: acquisto di prestazioni supplementari (supporto/manutenzione/sviluppo) per l'OSS +Capitolo 8:: Collaboration: aspetti di diritto degli acquisti pubblici delle collaborazioni per la creazione, la manutenzione e il supporto di OSS +Capitolo 9:: Contribution: contributi a progetti OSS + +== Sovranità digitale e acquisti + +=== Introduzione alla sovranità digitale e all'OSS + +Con l'art. 9 LMeCA l'Amministrazione federale fornisce, pubblicando il proprio software come OSS, un contributo importante alla sostenibilità e alla sovranità digitali. + +La sovranità digitale non è fine a sé stessa, bensì un presupposto per un'amministrazione efficace, democratica e orientata al futuro. È un concetto sfaccettato con dimensioni tecnologiche, organizzative e politiche. + +**** +*Sovranità digitale significa che lo Stato dispone del controllo e della capacità d'azione necessari nello spazio digitale per garantire l'adempimento dei compiti pubblici.* +**** + +In particolare nell'acquisto di software occorre considerare le ripercussioni sulla sovranità digitale dell'Amministrazione federale. + +Nei suoi *ruoli di utente, gestore e committente* nel settore delle TIC e del software, l'Amministrazione federale può assumere consapevolmente le proprie responsabilità in materia. + +Nel settore del software vi sono tre obiettivi strategici: + +*Intercambiabilità*: [.underline]#in quanto utente#, l'amministrazione pubblica mira a poter scegliere liberamente e con flessibilità tra fornitori, soluzioni informatiche e tecnologie. Ciò presuppone la disponibilità di alternative valide e collaudate nonché architetture informatiche, canali d'acquisto e dotazioni di personale concepiti per agevolare il cambiamento. + +*Capacità di configurazione*: [.underline]#in quanto gestore informatico#, l'amministrazione pubblica ha la capacità di configurare e co-configurare i propri sistemi informatici. A tal fine dispone delle competenze necessarie e di strutture cooperative adeguate per comprendere e valutare le soluzioni informatiche e, se necessario, assicurarne lo sviluppo, l'ulteriore sviluppo e l'esercizio. + +*Influenza*: [.underline]#in quanto committente#, l'amministrazione pubblica può formulare e far valere le proprie esigenze e i propri bisogni nei confronti dei fornitori di tecnologia. Ciò vale per le caratteristiche dei prodotti (funzioni, opzioni d'esercizio, disponibilità, sicurezza delle informazioni e protezione dei dati ecc.) così come per la redazione dei contratti e i modelli di licenza. + +Gli *standard aperti* e il *software open source* sostengono al meglio questi obiettivi grazie ai *principi dell'open source*. + +L'OSS sostiene la sovranità digitale nei modi seguenti: + +* La sicurezza informatica per l'amministrazione pubblica, le infrastrutture critiche e le applicazioni sensibili può essere garantita [.underline]#in ogni momento# grazie all'[.underline]#accesso completo# al codice sorgente. +* L'OSS consente agli enti pubblici di costruire, esercire, controllare e adattare la propria infrastruttura informatica senza condizioni di licenza restrittive. +* L'OSS offre il controllo completo su aggiornamenti, funzionalità e patch di sicurezza, sia nei contenuti sia nei tempi. +* L'OSS può impedire la dipendenza da singoli fornitori o modelli di licenza e sostiene l'intercambiabilità. +* L'OSS consente di rappresentare e ricostruire in modo trasparente l'intera catena di fornitura del software. +* L'OSS può essere adattato ed esteso — ben adatto alle esigenze specifiche delle autorità pubbliche e degli istituti di formazione, il che presuppone tuttavia conoscenze approfondite dei propri collaboratori. +* Gli investimenti nell'OSS vanno anche a beneficio delle imprese e delle community locali (creazione di valore locale) e accrescono la resilienza dell'economia svizzera. +* L'OSS si basa sulla collaborazione e su interfacce aperte, agevola l'interoperabilità tra sistemi e promuove gli standard aperti — anche oltre i confini nazionali. +* L'OSS migliora la sicurezza informatica e la sicurezza dei dati grazie alla trasparenza e all'adattabilità. +* Il software OSS licenziato sotto licenze OSI garantisce condizioni giuridiche chiare e continuità, oltre alle libertà fondamentali dell'OSS, proteggendo in egual misura sviluppatori e utenti. + +*Standard aperti:* per sostenere l'intercambiabilità del software, i bandi pubblici dovrebbero esigere il rispetto di standard aperti,footnote:[Per esempio standard aperti quali eCH, ODF; cfr. anche https://it.wikipedia.org/wiki/Standard_aperto[Standard aperto — Wikipedia]] riducendo così al minimo il lock-in. +*Interfacce aperte:* anche le interfacce dovrebbero essere divulgate per consentire l'interoperabilità. + +Le autorità federali sono in linea di principio tenute a rispettare gli standard eCH.footnote:[https://www.ech.ch/[www.ech.ch]] + +La Scuola universitaria professionale di Berna ha esposto le considerazioni determinanti nello studio _Prospettive tecnologiche della sovranità digitale_ [Stü2024], realizzato su mandato del DFAE, mediante il modello della «casa della sovranità», in cui il software è presentato quale pilastro portante. In questo modello, gli strati sottostanti al tetto — collaborazione, competenze tecnologiche, i quattro pilastri e regolamentazione — sono gli ambiti in cui le misure raccomandate promuovono la sovranità digitale. + +[mermaid,align="center",alt="Rappresentazione schematica degli aspetti della sovranità digitale che consentono la fornitura di prodotti e servizi innovativi"] +.... +block-beta + columns 4 + Roof["Prodotti e servizi digitali innovativi
di imprese e autorità"]:4 + space:4 + Collab["Collaborazione con la ricerca e la società civile"]:4 + Skills["Competenze tecnologiche (programmazione, data science ecc.)"]:4 + SW["Software"] Data["Dati e
contenuti digitali"] AI["Intelligenza
artificiale"] Infra["Infrastruttura TIC
(hardware)"] + Reg["Regolamentazione (leggi, standard)"]:4 + Collab-- "consentono" -->Roof +.... + +_Figura 2: Rappresentazione schematica degli aspetti della sovranità digitale che consentono la fornitura di prodotti e servizi innovativi [Stü2024]_ + +=== Misurare la sovranità digitale + +Aspetti della sovranità digitale possono essere richiesti in un bando pubblico, ma tali requisiti devono essere oggettivamente motivati. Non sussiste una preferenza generale per l'OSS. + +*Come si può dunque misurare il grado di sovranità digitale per una determinata tecnologia, un prodotto o un servizio?* + +Questa operazionalizzazione va effettuata nel modo più oggettivo e trasparente possibile. + +Diverse iniziative tentano di farlo. L'OSBA ha per esempio sviluppato un **indice di sovranità**footnote:[https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet[Un indice per la sovranità digitale | OSBA — Open Source Business Alliance]] _[OSBA-VK]_. _Nextcloud_ ha pubblicato un Digital Sovereignty Index (DSI),footnote:[https://dsi.nextcloud.com/[dsi.nextcloud.com]] che confronta interi Paesi ma può fornire anche criteri utili. +L'Unione europea ha pubblicato per il cloud un Cloud Sovereignty Framework.footnote:[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]] +Il _Centro per la sovranità digitale ZenDiS_ sta lavorando a un controllo della sovranità volto a valutare soluzioni informatiche e organizzazioni sulla base di criteri di sovranità trasparenti. + +Anche l'Amministrazione federale partecipa allo sviluppo di un *quadro di riferimento per la sovranità digitale* che consentirà tra l'altro di determinare il grado di adempimento secondo diverse prospettive. + +Le prospettive possibili sono: + +A -- Controllo tecnologico:: +In che misura l'Amministrazione federale controlla le tecnologie impiegate e il loro ulteriore sviluppo? + +B -- Sovranità dei dati:: +Chi ha accesso ai dati, il controllo su di essi e il potere decisionale — in particolare per i dati amministrativi sensibili? + +C -- Capacità giuridica d'azione:: +In che misura la Svizzera e l'Amministrazione federale possono influenzare il quadro giuridico e politico della digitalizzazione? + +D -- Resilienza:: +Quanto sono robusti e resistenti alle crisi i sistemi e i processi digitali dell'Amministrazione federale di fronte a perturbazioni, crisi e dipendenze? + +E -- Controllo economico:: +Come può l'Amministrazione federale esercitare un controllo economico e un sourcing strategico per assicurare la propria sovranità digitale in modo efficiente sotto il profilo dei costi, riducendo al minimo dipendenze e rischi negli acquisti informatici? + +Per ciascuna di queste prospettive il grado di sovranità digitale può essere determinato mediante una scala ancora da definire: + +0 -- Eterodiretto / non sovrano:: +Nessun controllo su sistemi, dati o infrastrutture; nessuna trasparenza, forti dipendenze; nessuna opzione di uscita o alternativa + +1 -- Controllo minimo:: +Prime conoscenze sull'utilizzo e sulle dipendenze; meccanismi di controllo puntuali; permangono lacune operative, giuridiche o tecnologiche + +2 -- Utilizzabile in modo regolamentato:: +Sistemi affidabili e parzialmente governabili; quadro giuridico e tecnico consolidato; permangono dipendenze strategiche + +3 -- Autonomo e resiliente:: +La posizione di mercato viene sfruttata; strategie di uscita e concetti multifornitore attuati; know-how sviluppato; resilienza e scenari di crisi preparati + +4 -- Sistemicamente sovrano:: +Sovranità in tutte le dimensioni rilevanti (giuridica, tecnologica, culturale, strategica); definizione attiva del mercato e degli standard; effetto geopolitico possibile + +_Figura 3: Grado di sovranità digitale._ + +Queste due dimensioni producono la matrice seguente: + +[.landscape] +[cols="2,^1,^1,^1,^1,^1",options="header"] +|=== +|Prospettiva +|0 + +Eterodiretto +|1 + +Controllo minimo +|2 + +Utilizzabile in modo regolamentato +|3 + +Autonomo e resiliente +|4 + +Sistemicamente sovrano + +|A -- Controllo tecnologico +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|B -- Sovranità dei dati +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|C -- Capacità giuridica d'azione +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|D -- Resilienza +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|E -- Controllo economico +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +|=== + +_Figura 4: Matrice Sovranità digitale: prospettive e grado di sovranità._ + +Per le singole intersezioni della griglia possono essere descritti criteri concreti per rendere la classificazione il più oggettiva possibile. + +Un simile quadro di riferimento è attualmente in fase di elaborazione nell'ambito della priorità 4 «Rafforzare la sovranità digitale» della «Strategia Amministrazione federale digitale».footnote:[https://www.bk.admin.ch/bk/it/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html[www.bk.admin.ch — Amministrazione federale digitale]] + +Il Consiglio federale ha posto in vigore il 1° gennaio 2026 la direttiva quadro Sovranità digitale nell'Amministrazione federale.footnote:[W012 - Direttive per la sovranità digitale nell'Amministrazione federale] I progetti devono integrare i diversi aspetti nella definizione dell'oggetto dell'acquisto e, se necessario, in un bando, sulla base del concreto fabbisogno di sovranità — per esempio sotto il profilo dei rischi nell'ambito della gestione della continuità operativa. + +== Casi d'applicazione per l'acquisto di software + +Le tecnologie dell'informazione e della comunicazione (TIC) e il software non sono fine a sé stessi nell'Amministrazione federale, bensì servono sempre ad adempiere un mandato legale. Data la digitalizzazione crescente e il ruolo centrale dell'Amministrazione federale in Svizzera, l'informatica deve essere una competenza chiave dell'amministrazione. + +I seguenti *fattori* incidono pertanto direttamente sugli acquisti: + +* *Digitalizzazione*: la strategia digitalefootnote:[https://digital.swiss/it/] richiede la digitalizzazione dei processi. +* *Ottimizzazione dei processi*: i processi in seno all'Amministrazione federale e nelle sue relazioni esterne possono e devono essere ottimizzati. +* *Sovranità digitale*: l'importanza della sovranità digitale cresce costantemente; cfr. _[Stü2024]_. +* Il principio *public money, public goods* e il rispetto dell'art. 9 LMeCA. +* *Libertà economica*: le misure non devono limitare inutilmente la libertà economica. +* Considerazioni generali di *sicurezza*: la sicurezza dei sistemi di elaborazione delle informazioni assume crescente importanza. +* Gestione delle crisi e delle catastrofi (*resilienza*): vista l'attuale situazione mondiale, l'amministrazione deve esaminare come poter continuare a mettere a disposizione gli strumenti di lavoro necessari anche in circostanze critiche. +* Indipendenza strategica e considerazioni sulla *catena di fornitura*: derivano dalla sovranità digitale e dalla resilienza. +* Evitare o ridurre al minimo il *vendor lock-in*: in informatica le dipendenze sono pressoché inevitabili, ma la dipendenza da un unico fornitore andrebbe ridotta ovunque possibile. +* *Rafforzamento delle competenze* dell'Amministrazione federalefootnote:[Non soltanto tra i quadri, i capiprogetto e gli architetti TIC, ma in tutto il personale.] (compresa la direzione) in materia di TIC: pilotare, sviluppare ed esercire le tecnologie dell'informazione richiede competenze adeguate nell'intero organico. + +Il presente documento distingue i seguenti *tipi di software*: + +* *Commodity — applicazioni specialistiche/settore — applicazioni specialistiche/autorità federale*: +** Applicazione standard (software commodity) senza logica applicativa particolare. +** Applicazione specialistica: esigenza specifica del settore/di tutti i livelli federali oppure esigenza specifica dell'autorità federale +* *Mirato — strategico — essenziale*: +** Applicazione mirata +** Applicazione strategica di notevole importanza per un'autorità federale o per l'insieme dell'Amministrazione federale +** Essenziale e critica per l'attività — deve restare funzionante in ogni circostanza (p. es. controllo del traffico aereo) + +Le applicazioni possono essere impiegate in uno o più *ambiti d'applicazione*. + +Ciò che conta qui è la *standardizzazione* delle applicazioni per prodotto all'interno di ciascun ambito: + +* Nessuna strategia +* Strategia monoprodotto +* Strategia multiprodotto + +Oltre alla standardizzazione dei prodotti, che va esaminata con cura, esiste anche la standardizzazione ai fini dell'interoperabilità (formati di dati, API, elementi applicativi).footnote:[P. es. tramite eCH] +La standardizzazione _è ammissibile_ purché sia proporzionata e non limiti indebitamente la concorrenza (p. es. art. 30 cpv. 3 LAPub). Può ridurre i costi d'esercizio e di manutenzione e generare effetti di sinergia, in particolare quando sono coinvolti tutti i livelli federali. D'altro canto accresce il lock-in, la dipendenza e in alcuni casi i rischi per la sicurezza (rischio di concentrazione). + +Il costo totale di proprietà (TCO) — comprendente esercizio, manutenzione e sviluppo ulteriore — andrebbe sempre considerato negli acquisti. Le conseguenze finanziarie a lungo termine non vanno trascurate. I modelli di business open source differiscono per certi aspetti da quelli dei fornitori proprietari. + +I capitoli seguenti si concentrano in misura crescente sull'open source e trattano il relativo approccio d'acquisto e la sua attuazione. + +La scelta tra consumption, contribution, collaboration e creation è effettuata _caso per caso secondo il progetto_, in funzione dell'efficienza economica e della situazione giuridica, ripartendo i costi il più ampiamente possibile. In quest'ottica le quattro C definite nelle link:em002.pdf[Em002 Linee guida strategiche OSS], capitolo 3, sono ordinate per importanza decrescente: + +image::./assets/four-cs/four-cs.it.svg[Ordine delle quattro C: Consumption, Contribution, Collaboration, Creation] + +. Consumption +. Contribution +. Collaboration +. Creation + +Con la semplice *consumption* i costi si ripartiscono su un gran numero di altri utenti, ma l'autorità federale non ha alcun controllo sullo sviluppo ulteriore. La creation è l'opposto: controllo totale, ma costo totale. + +Con la *contribution* l'impegno finanziario si limita all'elemento sviluppato, che viene poi consegnato a un'altra organizzazione per la manutenzione. + +La *collaboration* è lo scenario più complesso, poiché le configurazioni possono variare notevolmente. Nel migliore dei casi i costi sono condivisi e l'autorità federale dispone di influenza sufficiente per attuare le proprie esigenze senza compromessi (cfr. capitolo 8). + +Idealmente alla *creation* spetta la quota minore. Il software può essere sviluppato internamente, tramite prestazioni di servizi o mediante un contratto d'appalto. + +La pura consumption sarà praticabile soltanto per le applicazioni standard. + +=== Il software richiede prestazioni supplementari quali manutenzione, supporto e sviluppo ulteriore. + +Sebbene le applicazioni open source possano essere utilizzate gratuitamente, il loro impiego strategico su migliaia di istanze richiede manutenzione, supporto e, se necessario, sviluppo ulteriore. + +Le autorità federali hanno interesse a un supporto a lungo termine delle versioni impiegate (cfr. capitolo 3.2.3 in _[BITKOM2024]_). + +L'art. 9 LMeCA stesso riguarda soltanto lo sviluppo o l'ulteriore sviluppo interno di software e non è determinante per altre considerazioni relative all'open source — si applicano invece la sovranità digitale e altri fattori. Restrizioni ai sensi dell'art. 9 LMeCA su singoli componenti di sviluppo possono tuttavia ripercuotersi sull'intero progetto quando sono prevedibili sviluppi proprietari o supplementari. La collaboration può allora essere impiegata per sfruttare effetti di sinergia e, ove possibile, ridurre i costi per l'insieme dell'Amministrazione federale. + +=== Obbligo di pubblicazione nell'acquisto di software + +Quando le esigenze indicano un bisogno di adattamento del software o un possibile bisogno di adattamento successivo, l'art. 9 LMeCA è rilevante e la pubblicazione è obbligatoria per tali parti, salvo che si applichi una delle due eccezioni. Nell'acquisto di una soluzione open source tale pubblicazione sarebbe già coperta da un contributo al progetto open source. Anche quando l'acquisto riguarda soltanto la licenza di software standard o un acquisto TIC coperto da un'eccezione, gli sviluppi supplementari devono in linea di principio essere pubblicati, il che va rispecchiato nella documentazione d'acquisto e nella bozza di contratto. + +*L'obbligo di pubblicazione secondo l'art. 9 LMeCA è pertanto rilevante per ogni acquisto in cui è probabile uno sviluppo proprio o un ulteriore sviluppo* (cfr. anche _[KBB-MB]_). + +== Creation: bandi per software e prestazioni che rientrano nell'articolo 9 LMeCA + +Il presente capitolo tratta le implicazioni dell'art. 9 LMeCA per i bandi relativi a software e prestazioni che possono comportare la creazione o la modifica di software. + +Esso si applica sia all'Amministrazione federale centrale sia a quella decentralizzata. Le eccezioni a tale obbligo sono stabilite nell'ordinanza sulla digitalizzazione _[DigiV]_. + +=== Rilevanza dell'articolo 9 LMeCA per la creazione di software + +Un'operazione rientra nel campo d'applicazione dell'art. 9 LMeCA se ricade nella categoria determinante della tabella 1. La decisione «make or buy» resta centrale per gli acquisti. L'analisi dei diversi casi d'applicazione mostra che in linea di principio l'art. 9 LMeCA è rilevante in tutti i casi, salvo quando viene acquistato software preesistente (p. es. semplici licenze). Il capitolo II.4 delle _direttive Open Source negli acquisti [BBL-WL]_ espone l'approccio strategico e l'allegato VII.A descrive in dettaglio che cosa costituisca software. Una ripartizione dettagliata della decisione strategica figura nella tabella 1. + +[cols="3,2,4",options="header"] +|=== +|Caso d'applicazione |Make or buy |Obbligo di pubblicazione secondo l'art. 9 cpv. 1 LMeCA + +|Sviluppare software in seno all'Amministrazione federale +|Make +|Sì, obbligo di pubblicazione + +|Far sviluppare software da terzi +|Buy, quale contratto di prestazioni informatiche +|Sì, obbligo di pubblicazione + +|Acquistare software esistente +|Buy +a|In linea di principio no, ma verificare se sussistono obblighi di pubblicazione per le parti sviluppate. Particolarmente rilevante è la gestione dei diritti di terzi (cfr. link:em002-3.pdf[Em002-3 Guida alle licenze OSS]). + +|Riprendere software da altri enti pubblici +|Make o buy +a|— In seno all'Amministrazione federale: obbligo di pubblicazione per l'unità amministrativa cedente. + +— Altri: esaminare caso per caso se gli adattamenti effettuati dall'Amministrazione federale generino un obbligo di pubblicazione, almeno per tali parti. + +|Acquistare risorse di sviluppo +|Make +|Sì, obbligo di pubblicazione (i contratti devono consentire la pubblicazione) + +|Collaborare con altri enti pubblici allo sviluppo di software +|Make +|Sì, obbligo di pubblicazione (i contratti devono consentire la pubblicazione), in particolare in presenza di contributi di sviluppo sostanziali da parte o a favore della Confederazione +|=== + +_Tabella 1: Classificazione dell'obbligo di pubblicazione e della decisione «make or buy» (sulla base di una tabella di Rika Koch, BFH)_ + +Nota: l'art. 9 LMeCA va considerato anche per il software esistente e per i SaaS quando il software deve essere ulteriormente sviluppato o adattato per la Confederazione. Anche se la probabilità è ridotta, ciò andrebbe trattato nel processo d'acquisto. + +Ove occorra un chiarimento, il riferimento raccomandato è link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source]. Le liste di controllo andrebbero *compilate provvisoriamente il prima possibile* per i progetti potenzialmente interessati. Anche la _lista di controllo per l'eccezione forfettaria secondo l'art. 9 LMeCA [BBL-CL]_ può essere utilizzata a tal fine. + +=== Preparare un acquisto ai sensi dell'articolo 9 LMeCA + +Oltre alle consuete fasi preparatorie, i due documenti seguenti andrebbero consultati ogniqualvolta un acquisto comprenda componenti software: + +* _promemoria sull'acquisto di software e l'art. 9 LMeCA [KBB-MB] e_ +* _direttive Open Source negli acquisti [BBL-WL]_. + +Quando l'art. 9 LMeCA è chiaramente rilevante, l'unità amministrativa dovrebbe avere: + +* compilato provvisoriamente le liste di controllo link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Valutazione preliminare OSS] fino a link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Rilascio e pubblicazione OSS]; +* preso una decisione di principio sull'utilizzo di una licenza copyleft o permissiva;footnote:[Se necessario, un'analisi più approfondita può essere svolta in seguito mediante la _Em002-3 Guida alle licenze OSS_.] +* cercato eventuali alternative open source (o potenziali progetti di base per contributi o collaborazioni) conformemente a link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source], utilizzando gli strumenti ivi indicati per la ricerca e l'analisi di mercato;footnote:[Cfr. anche link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale], capitolo 7.] +* chiarito la struttura di un'eventuale community (link:em002-4.pdf[Em002-4 Guida alle community OSS] e link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo Community OSS]). + +Se un progetto OSS esistente deve essere utilizzato, sostenuto o posto a base di una collaborazione, vanno letti i capitoli 5, 6, 8 e 9 del presente documento. + +=== Creation mediante contratti di prestazioni esistenti + +Quando la creation avviene mediante contratti di partenariato esistenti, la pubblicazione OSS va assicurata al più tardi in sede di mini-bando, salvo che si applichi una delle due eccezioni. + +I nuovi bandi di prestazioni dovrebbero sempre includere un requisito di pubblicazione conformemente all'art. 9 LMeCA (cfr. _[BBL-WL] e_ _[KBB-MB])_. + +=== Costituire una community + +Costituire e curare una community massimizza i benefici del software open source, ma comporta anche un onere considerevole. + +Quando una community e una collaborazione sono opportune, ciò ha implicazioni per l'acquisto sin dall'inizio. La link:em002-4-1-checklist-oss-community.pdf[lista di controllo Em002-4.1 Community OSS] andrebbe pertanto compilata sulla base della link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +Se l'autorità federale deve assumere un ruolo importante nella community (p. es. un ruolo di governance) o se è prevista una collaborazione (cfr. capitolo 8), può essere necessario acquistare prestazioni supplementari: costituzione della community, consolidamento delle esigenze, gestione dello sviluppo ulteriore. + +=== Criteri tipo ed elementi contrattuali per gli acquisti informatici + +Il CCAP tiene un modello di possibili criteri d'acquisto nonché un modello di capitolo di contratto quadro per i bandi relativi al software _[KBB-KV]_. + +Il CCAP ha pubblicato su Perimap.admin.ch due documenti tipo che mostrano come possano essere soddisfatti i requisiti minimi per un'aggiudicazione conforme al diritto degli acquisti pubblici ai sensi dell'art. 9 LMeCA. [KBB-KV] + +. https://perimap.admin.ch/goto_perimap_file_47064_download.html[Criteri tipo — Acquisto LMeCA e open source] +. https://perimap.admin.ch/goto_perimap_file_47059_download.html[Testi contrattuali tipo — Sviluppo software] + +== Consumption: acquisto di software: parità di trattamento del software open source + +Il presente capitolo tratta l'acquisto e l'utilizzo (consumption) di software open source e mette in evidenza i principali aspetti strategici. +Si rinvia inoltre a _[BBL-WL] e_ _[KBB-MB]_. + +*Attualmente non esiste alcuna preferenza legalmente prescritta per il software open source negli acquisti.* + +Nei bandi relativi ad applicazioni informatiche sono considerati tutti i tipi di licenza e i modelli di business. Per soddisfare le esigenze formulate, i fornitori possono proporre soluzioni software basate su software open source non modificato, closed source o proprietario, oppure su combinazioni di modelli di licenza e prestazioni a valore aggiunto o abbonamenti. + +I punti seguentifootnote:[I documenti di riferimento determinanti per gli acquisti sono quelli pubblicati dall'UFCL e dal CCAP sulle rispettive piattaforme.] andrebbero considerati dalle autorità federali: + +* Indipendentemente dalla soluzione e dal modello di licenza, il fornitore di prestazioni deve indicare nella propria offerta *quali condizioni di licenza il servizio acquirente deve rispettare nell'utilizzo della prestazione*. +* Il fornitore di prestazioni è *libero di scegliere la soluzione* con cui intende soddisfare le esigenze messe a concorso nonché la forma di rimunerazione che desidera ricevere (tasse di licenza, di manutenzione o di abbonamento), purché ciò sia tecnicamente realizzabile ed economicamente ragionevole. +* L'intero *ciclo di vita* andrebbe considerato nelle specifiche e nella determinazione dei prezzi. + +Ciò consente all'Amministrazione federale di far valere i propri interessi in materia di proprietà intellettuale, garanzia e responsabilità — indipendentemente dal software o dal modello di licenza — a livello delle condizioni generali applicabili e di ancorarli nel contratto. + +Quando *adattamenti software* sono effettuati su mandato o in esecuzione di un contratto con l'autorità federale, si applica l'art. 9 LMeCA. +In via precauzionale l'autorizzazione alla pubblicazione andrebbe richiesta già nel bando, poiché l'esperienza mostra che prima o poi si rendono necessari adattamenti, anche se non prevedibili al momento del bando. + +Quando il servizio acquirente acquista da un fornitore *prestazioni a valore aggiunto* in aggiunta al software, i fornitori OSS propongono spesso un modello di abbonamento che offre un interlocutore locale con impegni di garanzia e responsabilità, oltre al rapporto diretto con i titolari dei diritti di proprietà intellettuale sui componenti OSS (spesso con sede all'estero e talvolta ignoti). + +=== L'OSS quale criterio strategico d'acquisto + +Quando un'autorità federale intende acquistare software open source per ragioni strategiche, sono possibili diversi scenari: + +* Bando funzionale senza criteri specifici per l'OSS. +Poiché ciò non comporta restrizioni, non è necessaria alcuna motivazione particolare. +* Bando funzionale con criterio di idoneità, criteri tecnici e criteri di aggiudicazione che esigono open source, accesso completo al codice sorgente o esperienza dimostrabile nella pubblicazione open source. + +*Una preferenza per l'open source è ammissibile sotto il profilo del diritto degli acquisti pubblici quando consente di soddisfare (meglio) le esigenze concrete del servizio aggiudicatore*.footnote:[Cfr. [BBL-WL\], [BBL-CL\], [KBB-MB\], [KBB-KV\]] + +Un'ulteriore ragione per privilegiare l'OSS — oltre alla sovranità digitale — è che, quando l'amministrazione richiede adattamenti software rilevanti, questi devono essere pubblicati ai sensi dell'art. 9 LMeCA. +La pubblicazione è più semplice quando l'intero prodotto è sempre stato open source e gli adattamenti possono in taluni casi essere effettuati direttamente nel prodotto. Altrimenti va definita un'eccezione e, se necessario, parti del codice vanno isolate e comunque pubblicate. + +=== L'utilizzo gratuito di OSS non sottostà al diritto degli acquisti pubblici. + +L'OSS può spesso essere scaricato e utilizzato direttamente. Il diritto degli acquisti pubblici si applica soltanto quando prestazioni sono ottenute da terzi dietro rimunerazione (comprese controprestazioni non pecuniarie). + +Lo scaricamento e l'utilizzo gratuiti di OSS non costituiscono di per sé un acquisto. + +È inoltre possibile acquistare in un secondo tempo le prestazioni necessarie per OSS scaricati, purché ciò non avvenga in modo abusivo.footnote:[Analogia: un Comune può utilizzare il proprio legname e commissionare la costruzione di un deposito di manutenzione con tale legname — non è tenuto ad acquistare esso stesso il legname.] + +Le prestazioni di manutenzione, supporto e sviluppo ulteriore del prodotto sono poi messe a concorso separatamente conformemente al diritto degli acquisti pubblici. + +Esistono già esempi di OSS utilizzati gratuitamente sulle postazioni di lavoro standard dell'Amministrazione federale e quindi non acquistati.footnote:[Esempi di OSS con potenziale di standardizzazione: Gimp, FileZilla, VLC Media Player e 7-zip quali prodotti Shell 2 (secondo [A029\]), utilizzabili perché l'installazione è gratuita. Nel 2024 l'UFIT ha designato Red Hat OpenShift quale prodotto strategico per determinati ambiti d'applicazione in ragione delle sue caratteristiche tecniche uniche. OpenShift è attualmente la piattaforma strategica per container e sistemi operativi.] + +=== Coordinare le esigenze con altre parti interessate + +Un'applicazione specialistica richiede sempre un titolare del fabbisogno (di regola un ufficio federale). Di regola è opportuno che l'ente con il fabbisogno armonizzi le proprie esigenze con quelle di altri servizi pubblici — internamente o nell'ambito di una collaborazione (cfr. capitolo 8) — nella misura in cui un prodotto disponibile sul mercato o uno sviluppo congiunto favorisca lo sviluppo e l'introduzione. + +Quando molte parti interessate hanno esigenze uguali o analoghe, può valere la pena soddisfare tali bisogni su base comune. Ciò vale per tutte le forme di software. + +Vanno rilevati due aspetti: quando in seguito un'autorità federale effettua adattamenti su richiesta di terzi, si applica nuovamente l'art. 9 LMeCA — il che tuttavia non pone problemi se viene impiegato software open source. + +Con l'OSS le esigenze devono talvolta essere armonizzate in modo più attivo dall'autorità federale, poiché può mancare una forza trainante come un fornitore commerciale che intenda pilotare e sviluppare il proprio prodotto. + +=== Considerare altri possibili attori pubblici nell'acquisto + +L'esempio di ZenDiSfootnote:[https://www.zendis.de/en[https://www.zendis.de/] ZenDiS si è posta l'obiettivo di liberare l'amministrazione da dipendenze critiche da singoli fornitori di tecnologia.] mostra che può essere sia praticabile sia conveniente indire un bando che copra simultaneamente tutti i livelli federali. + +*Una concorrenza equa va sempre preservata.* Nell'indire bandi occorre sempre esaminare se la soluzione potrebbe utilmente essere acquistata anche per altri enti. + +In tal caso questi potenziali committenti supplementari andrebbero contattati e le loro esigenze rispecchiate nella documentazione di gara, in particolare nei requisiti. Una certa flessibilità nei requisiti è importante in simili casi. + +Esempio: eOperations Svizzera SA (http://www.eoperations.ch[www.eoperations.ch]) può essere utilizzata per tali collaborazioni. eOperations consolida le esigenze di diversi servizi ed effettua essa stessa l'acquisto, senza necessariamente utilizzare il prodotto. Ciò può costituire un modello utile anche per l'acquisto di OSS. + +== Consumption: acquisto di supporto e manutenzione per l'OSS + +L'amministrazione pubblica può utilizzare il software open source in vari modi, dal semplice scaricamento e installazione fino all'acquisto formale (cfr. capitolo 6.2). + +Quando l'OSS è impiegato in ambiti critici, sono necessari standard costantemente elevati di sicurezza,footnote:[Cfr. anche link:em002-6.pdf[Em002-6 FAQ-OSS], capitolo 5.3] manutenzione e sviluppo ulteriore. Nell'acquisto ordinario di software ciò è di regola coperto dal bando. I requisiti valgono sia per il software stesso sia per le librerie e i framework utilizzati. Supporto e manutenzione meritano particolare attenzione, poiché lo sviluppo ulteriore è spesso coperto dal medesimo contratto e costituisce in ogni caso creation, rientrando così nel campo d'applicazione dell'art. 9 LMeCA. + +Queste prestazioni ad alta intensità di lavoro superano quasi sempre il valore soglia della legge federale sugli appalti pubblici (LAPub) se calcolate sull'intero ciclo di vita dell'applicazione. Se sono acquistate da terzi, va rispettato il diritto degli acquisti pubblici. Possono applicarsi eccezioni, quali l'acquisto intrastatale presso un altro committente pubblico,footnote:[Art. 10 cpv. 3 lett. b LAPub.] oppure, in casi eccezionali, l'acquisto per incarico diretto di prestazioni specialistiche.footnote:[Art. 21 cpv. 2 lett. c LAPub.] + +La tabella seguente presenta le distinzioni di caso per l'acquisto di prestazioni quali il supporto. + +[cols="1,1,1,2"] +|=== +2+h|Situazione iniziale 2+h|Risultati + +h|Costi del ciclo di vita + +→ valore soglia OMC?footnote:[I costi interni possono essere esclusi. Va considerato l'intero ciclo di vita.] +h|Intrastatale?footnote:[L'acquisto intrastatale non è soggetto a bando: è richiesto un ente responsabile statale, senza partecipazione al mercato. Si applica soltanto all'interno del settore pubblico svizzero.] +h|Bando OMC necessario?footnote:[Le direttive federali in materia di acquisti si applicano sempre non appena viene effettuato un pagamento.] +h|Osservazioni + +|No +|No +|No footnote:[Il software con supporto supera di regola il valore soglia LAPub; «no» si applicherà soltanto in rari casi (p. es. finanziamento di una singola funzionalità per un progetto OSS esistente).] +.2+|Raramente un pacchetto software completo con supporto — per lo più supporto ridotto e singole funzionalità. + +|No +|Sì +|No + +|Sì +|No +|Sì +|È determinante soltanto il volume destinato a terzi. + +|Sì +|Sì +|No +|Il bando è stato indetto dall'altro ente pubblico. +|=== + +_Tabella 2: Distinzione di caso — acquisto di supporto_ + +=== Supporto e manutenzione fanno sempre parte del software + +Supporto e manutenzione sono essenziali per l'esercizio sostenibile del software in un contesto amministrativo. In un mondo di exploit zero-day,footnote:[Un exploit zero-day designa lo sfruttamento di una falla di sicurezza per la quale non è ancora disponibile alcuna patch dello sviluppatore del componente.] l'applicazione rapida e professionale delle patch è determinante. Questa «infrastruttura» va finanziata — tanto più che l'amministrazione ha esigenze superiori a quelle di un consumatore privato. + +*La domanda non è dunque SE supporto e manutenzione saranno necessari, bensì COME saranno assicurati.* + +L'autorità federale deve stabilire quale livello di supporto, manutenzione, garanzia e responsabilità le occorre in base alle proprie esigenze di qualità del servizio. + +È importante che ogni fornitore di prestazioni incaricato della manutenzione e del supporto possa dimostrare un'esperienza sufficiente con il prodotto o con la relativa community open source — soltanto allora sarà in grado di adempiere efficacemente tali compiti (cfr. anche _[KBB-MB]_, II.5).footnote:[Il contratto di prestazioni dovrà eventualmente coprire anche il possibile trasferimento di conoscenze a un'organizzazione successiva.] + +Supporto e manutenzione vanno finanziati anche a livello di prodotto. Se nessuno contribuisce (il problema del free ridingfootnote:[https://it.wikipedia.org/wiki/Free_riding]), il futuro del progetto è compromesso e con esso il suo impiego in seno all'Amministrazione federale. Date le sue dimensioni, ci si può ragionevolmente attendere che l'Amministrazione federale contribuisca ai costi del software che impiega strategicamente. + +=== Organizzazioni che possono fornire supporto + +La qualità del supporto incide direttamente sulla soddisfazione e sulla produttività degli utenti finali. Un sistema di supporto strutturato, con tempi di risposta rapidi e reale competenza tecnica, garantisce che utenti e amministratori ottengano soluzioni efficaci ai loro problemi, risparmiando tempo di lavoro al committente e favorendo l'accettazione della soluzione software. + +Per rispettare i tempi di risposta convenuti contrattualmente nei service level agreement (SLA), il fornitore deve disporre di personale qualificato con le competenze necessarie. + +Le possibili fonti di supporto sono: + +*Interne*: + +* Uffici federali +* Fornitori di prestazioni + +*Intrastatali*: + +* Altri committenti pubblici in Svizzera +* Prestazioni acquistate da altri committenti pubblici in Svizzera + +*Terzi*: + +* Prestazione acquistata + +=== Sviluppo ulteriore per funzionalità specifiche + +Quando un'autorità federale necessita soltanto di un numero limitato di miglioramenti specifici di un software open source, ciò può avvenire con risorse interne o prestazioni acquistate. + +Tali sviluppi ulteriori dovrebbero mirare a essere proposti al progetto originario e a esservi integrati. Ciò non soltanto giova all'ecosistema del progetto, ma assicura che i miglioramenti continuino a essere mantenuti all'interno del progetto. In caso contrario ogni nuova versione del progetto originario può richiedere un aggiornamento manuale dello sviluppo su misura (cfr. anche capitolo 8). + +=== Abbonamento + +Molte imprese e progetti dell'ambiente open source offrono supporto gratuito entro certi limiti, fornito volontariamente da qualsiasi utente, principalmente attraverso canali aperti quali forum e sistemi di ticket pubblici. Questa offerta gratuita non è concepita per utenti professionali con esigenze SLA specifiche. + +Per utenti professionali quali le autorità federali sono spesso disponibili abbonamenti OSS che comprendono garanzia, manutenzione e supporto. + +Alcuni fornitori propongono anche speciali «versioni enterprise» che non soddisfano più i criteri open source dell'OSI. + +Esempi di abbonamenti: OpenShift di Red Hat, openDesk di ZenDiS + +=== Certificazioni nel settore open source e OpenChain + +Come per il software proprietario, anche nel settore open source esistono diverse certificazioni. Per l'amministrazione può valere la pena verificare, prima di indire un bando, l'esistenza di certificazioni potenzialmente rilevanti nell'ambito interessato. + +*OpenChain* è una norma ISO relativa allo sviluppo open source e alla compatibilità delle licenze (cfr. sotto). + +Se esistono certificazioni pertinenti e determinanti per la prestazione, esse andrebbero considerate nella valutazione dei fornitori. È importante che la certificazione stessa sia ritenuta significativa e che i fornitori possano dimostrare di essere in grado di fornire la prestazione anche senza certificazione. + +Data la complessità in gioco, non è consigliabile esigere certificazioni quale criterio di idoneità. Quale criterio di aggiudicazione — con la possibilità di dimostrare mediante referenze il rispetto dei contenuti della certificazione — esse possono essere adeguate a seconda del prodotto OSS, purché sia ammissibile utilizzare referenze per provare il soddisfacimento dei criteri di certificazione.footnote:[Nota: esigere una certificazione eccessiva o poco adatta all'oggetto del bando produrrà inevitabilmente offerte meno competitive.] + +Un'autocertificazione OpenChain può tutt'al più fungere da sostituto quando non esiste alcun'altra certificazione. Anche referenze che coprono i criteri determinanti possono sostituire certificazioni mancanti. + +*Certificazione delle imprese partner* + +Alcuni sviluppatori e progetti open sourcefootnote:[quali Nextcloud o Univention] certificano le imprese partner con cui collaborano. Tali certificazioni possono attestare una relazione esistente tra il fornitore e lo sviluppatore del software. Va notato che molti progetti OSS non offrono simili certificazioni. Una collaborazione comprovata in progetti di riferimento è un indicatore altrettanto valido — e meno restrittivo — della qualità ricercata. + +*Certificazione dei collaboratori* + +Alcuni fabbricanti o community open sourcefootnote:[quali LibreOffice o RedHat] certificano singole persone con competenze specialistiche nel software in questione. Se un fornitore di prestazioni impiega personale certificato, ciò può attestare competenze nella pubblicazione upstream di adattamenti e patch nonché nella fornitura di un supporto di terzo livello di qualità — in particolare quando più collaboratori lavorano con il prodotto. Ciò dipende anche dalla struttura dell'ecosistema del progetto OSS. + +In alternativa alle certificazioni, anche un'esperienza progettuale dimostrabile in referenze relative all'oggetto dell'acquisto può fungere da criterio distintivo. + +*Standard OpenChain* + +Lo standard OpenChain rappresenta sia una best practice in materia di compatibilità delle licenze sia una certificazione interessante per i servizi aggiudicatori. + +La norma ISO/IEC 5230 «OpenChain» si concentra sulle catene di fornitura del software, sulla semplificazione degli acquisti e sulla conformità delle licenze. Lo standard OpenChain può essere attribuito da un organismo di certificazione accreditato oppure ottenuto mediante autocertificazione. Questa certificazione è idonea a dimostrare in termini generali che un fornitore si è già occupato approfonditamente dei requisiti delle licenze open source e delle specificità dell'ecosistema open source. +Poiché l'allestimento di una Software Bill of Materials (SBOM) fa parte dello standard, questa certificazione attesta anche l'impegno di un fornitore a favore della sicurezza della catena di fornitura mediante il sostegno di componenti fondamentali. + +=== Ulteriori possibilità di acquistare prestazioni di manutenzione, supporto o sviluppo + +È opportuno trattare le prestazioni di sviluppo ulteriore nel medesimo contratto del supporto e della manutenzione, poiché la distinzione non è sempre netta e spesso non è praticabile nel contesto del software open source. Gli sviluppi ulteriori finanziati da un'autorità federale rientrano nel campo d'applicazione dell'art. 9 LMeCA. + +Attualmente sono disponibili le seguenti possibilitàfootnote:[Possono esistere anche altre possibilità, più di nicchia.] per acquistare prestazioni di supporto, manutenzione e/o sviluppo ulteriore per l'OSS: + +* Internamente, con sviluppo delle competenze: impiegare risorse di sviluppo proprie +* Acquisto: secondo il volume e nel rispetto della LAPub. Ciò può avvenire anche mediante contratti di prestazioni già messi a concorso. Affinché partner strategici possano mettere a disposizione sviluppatori principali esperti per progetti OSS centrali per l'Amministrazione federale, può essere opportuno ammettere il subappalto o esigere le relative competenze in determinati bandi. +* Accordi di cooperazione con terzi per manutenzione, supporto o sviluppo ulteriore: privi di problemi purché ciascuna parte sostenga i propri costi. +* Partecipazione della Confederazione a organizzazioni: priva di problemi purché ciascuna parte sostenga i propri costi. + +== Collaboration: aspetti di diritto degli acquisti pubblici della creazione, manutenzione e supporto congiunti di OSS + +I costi del software open source diminuiscono quando esso è sviluppato congiuntamente, sia in modo informale sia in una forma strutturata. La link:em002-4.pdf[Em002-4 Guida alle community OSS] espone i relativi approcci. + +La collaborazione con altri committenti pubblici o con terzi non pone problemi sotto il profilo del diritto degli acquisti pubblici purché ciascuna parte sostenga i propri costi. Sorgono difficoltà quando dalla collaborazione non risulta un OSS, poiché l'Amministrazione federale è vincolata all'art. 9 LMeCA. + +Tale cooperazione è ammessa dall'art. 4 LMeCA. + +Va chiarita la questione del trattamento delle spese generali o di una struttura centralizzata: la struttura necessita di un finanziamento sufficiente per sostenere il progetto anche nei periodi difficili. Un'alternativa è un unico partner gestore (p. es. se un partecipante è sufficientemente grande da assumere il ruolo di coordinamento). Se l'autorità federale assume tale ruolo, le relative prestazioni devono essere fornite internamente o messe a concorso nel modo consueto qualora debbano essere coinvolti terzi. + +A livello contrattuale, alle collaborazioni si applica quanto segue: + +* Quando non circola denaro e non sono richiesti obblighi formali, è possibile un Memorandum of Understanding a livello di ufficio federale o di Cancelleria federale. +* La creazione di una struttura comune — quale un'associazione o una corporazione di diritto pubblico — è in linea di principio possibile ma va valutata caso per caso. Se la struttura comune deve a sua volta acquistare prestazioni da terzi, occorre disciplinare l'applicazione del diritto degli acquisti pubblici. + +L'adesione può in taluni casi essere esercitata mediante altre organizzazioni quali eOperations o eCH. + +*Cooperazione con l'estero* + +La cooperazione con autorità estere non pone problemi purché non circoli denaro e non venga assunto alcun obbligo di sorta. + +Accordi di cooperazione al livello appropriato sono in linea di principio possibili ma vanno valutati caso per caso. +I trattati internazionali andrebbero evitati dati gli elevati ostacoli che comportano, sebbene siano in linea di principio anch'essi possibili. + +Esistono due casi particolarifootnote:[https://www.eda.admin.ch/deza/it/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] in cui la collaborazione sarebbe già coperta: + +* Le commesse aggiudicate in virtù di un accordo internazionale per la realizzazione congiunta di un progetto da parte di Stati firmatari. +* Le commesse aggiudicate conformemente alle procedure o condizioni particolari di un'organizzazione internazionale. + +== Contribution: contributi a progetti OSS + +La maggior parte delle caratteristiche e delle considerazioni giuridiche relative ai contributi è trattata nella link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +Sotto il profilo del diritto degli acquisti pubblici i contributi non pongono di regola problemi, poiché le prestazioni sono fornite per sviluppare codice destinato a un progetto che è o direttamente rilevante per l'autorità o già trattato sotto il profilo del diritto degli acquisti pubblici. + +*Anche i contributi di terzi a progetti OSS gestiti da autorità federali non pongono problemi sotto il profilo del diritto degli acquisti pubblici, purché non circoli denaro.* + +Nota: poiché l'autorità federale è tenuta a pubblicare il software che sviluppa, essa deve anche assicurare che esso resti pubblicato. Se un progetto OSS viene ritirato dai suoi gestori, nel peggiore dei casi l'autorità federale dovrà ripubblicarlo autonomamente. Nella pratica il codice sorgente resta tipicamente disponibile (p. es. come archivio), il progetto prosegue come fork, oppure il progetto — e con esso il codice sorgente — è semplicemente divenuto irrilevante. + +== Allegato A: Riferimenti: + +Una parte considerevole dei riferimenti è _già menzionata nelle Em002 Linee guida strategiche per il software open source nell'Amministrazione federale_. + +include::partials/references.it.adoc[tags=ref-em002-7] + +== Allegato B: Glossario + +Il presente glossario tratta termini specifici relativi ai temi degli acquisti. + +Il glossario generale della serie di documenti Em002 figura in Em002-6 FAQ-OSS. + +Ulteriori termini figurano nella https://www.bk.admin.ch/bk/it/home/dokumentation/sprachen/termdat.html[banca dati terminologica TERMDAT dell'Amministrazione federale]. + +include::partials/glossary.it.adoc[tags=gloss-em002-7] +endif::[] + +ifeval::["{lang}" == "rm"] +*Exclusiun da responsabladad:* 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 {url-repo}/tree/main[README]. + +''' + +== L'essenzial en curt + +Quest document cumplettescha la seria da meds OSS Em002 cun aspects da l'acquist. El sa basa sin il _fegl d'infurmaziun davart l'acquist da software e l'art. 9 EMBAG_ publitgà dal Center da cumpetenza per l'acquist public da la Confederaziun (CCA)footnote:[Il Center da cumpetenza per l'acquist public da la Confederaziun (CCA) cusseglia ils posts d'acquist e da basegn en dumondas dal dretg d'acquist tenor l'art. 37 OAPub. Adressa d'e-mail centrala per dumondas: rechtsdienst.kbb@bbl.admin.ch] _[KBB-MB]_ e resumescha ils cuntegns da documents da l'UFCLfootnote:[L'Uffizi federal per edifizis e logistica (UFCL) è il post d'acquist central da la Confederaziun svizra (art. 5–7 OAPub). El acquista en ses sectur da cumpetenza, radunescha nua ch'igl è sensa e po concluder contracts da rom.] sco la _directiva Open Source en l'acquist_ [BBL-WL], che èn disponibels mo en l'intranet.footnote:[https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html] Il document tracta ultra da quai la suveranitad digitala sco criteri d'acquist. + +L'utilisaziun da software open source sa lascha repartir en quatter aspects: + +* Consumption: l'utilisaziun da OSS gia existent +* Creation: il svilup da nov OSS +* Contribution: l'integraziun d'agens adattaments en in project OSS existent +* Collaboration: il svilup vinavant cuminaivel da OSS cun terzas persunas. + +En tuttas questas situaziuns sto ina incumbensadra publica observar il dretg d'acquist applitgabel. + +*Consumption:* + +* Il dretg d'acquist vala, sche prestaziuns vegnan cumpradas sin il martgà cunter pajament (art. 8 LAPub). + +Cun autras pleds: + +* L'utilisaziun da OSS ch'è disponibel gratuitamain (senza taxas da licenza, contracts da support u da mantenziun etc.) na represchenta per ordinari nagin acquist. +* Prestaziuns cun plivalur che vegnan cumpradas per l'utilisaziun da OSS (support, garanzia, mantenziun e svilup vinavant) ston vegnir acquistadas tenor il dretg d'acquist. +* Tar l'acquist da software è fundamentalmain permess d'exiger OSS, p.ex. sche l'unitad administrativa (UA) spetga da quai avantatgs concrets, sco ina pli gronda suveranitad da las datas u ina observaziun pli simpla da l'art. 9 EMBAG tar adattaments individuals previsibels. Il martgà na dastga dentant betg vegnir restrenschì nunlubidamain. + +*Creation e contribution:* + +* Tar il svilup da software u da cumponentas da software, era en vista ad ina contribuziun posteriura ad in project OSS, sto l'art. 9 EMBAG adina vegnir resguardà. Sche prestaziuns da terzas persunas vegnan cumpradas per quai, vala il dretg d'acquist. +* Tar contribuziuns a projects OSS dat l'UA vinavant agen lavur a terzas persunas; quest process na suttastat perquai betg al dretg d'acquist. +* L'acceptaziun da contribuziuns da terzas persunas ad in project OSS da la Confederaziun è era senza problems dal puntg da vista dal dretg d'acquist, uschenavant che nagin pajament na vegn fatg. + +*Collaboration:* + +* La collavuraziun da differentas incumbensadras publicas ad in project OSS chaschuna ina gronda varietad da pretensiuns giuridicas. Dal puntg da vista dal dretg d'acquist basegnan quellas constellaziuns in'examinaziun accurata, nua che prestaziuns vegnan furnidas cunter pajament. +* Tar ina collavuraziun informala po mintga partida participanta acquistar u furnir prestaziuns da svilup independentamain e las metter suenter a disposiziun gratuitamain. Era prestaziuns da coordinaziun pon vegnir furnidas u acquistadas. +* Tar ina collavuraziun formalisada, p.ex. via in'associaziun d'acturs publics, po era il post central furnir u acquistar prestaziuns da svilup, uschenavant ch'el suttastat sez al dretg d'acquist. +* In acquist cuminaivel tras incumbensadras da differents pajais n'è percunter betg permess senza ulteriur. + +Per l'utilisaziun persistenta da software open source è impurtant che l'OSS na vegnia betg mo consumà, mabain che uschè blers participants sco pussaivel contribueschian era a l'ecosistem. Per quai datti blers vias: da contribuziuns regularas da code sur la creaziun da documentaziun fin a la finanziaziun da sviluppadras e sviluppaders e bler auter. + +== Finamira ed intent + +La lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG)footnote:[https://www.fedlex.admin.ch/eli/cc/2023/682/rm] pretenda che reflexiuns supplementaras vegnian resguardadas tar l'acquist da software sviluppà da nov e da prestaziuns da svilup da software. + +Per sustegnair l'observaziun da l'art. 9 EMBAG ha il sectur TDT elavurà meds e resursas en il rom da link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] e da link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala] + +include::partials/document-map.rm.adoc[] + +Illustraziun 1: Survista dals meds OSS + +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]. + +Quest document va ultra dal center da l'artitgel 9 EMBAG ed exponta ultra da quai, co ch'i sto vegnir tractà en general cun l'open source en il context da l'acquist. + +Chapitel 3:: L'impurtanza da la suveranitad digitala en il context da l'open source e da l'acquist +Chapitel 4:: Cas d'applicaziun relevants da l'acquist en connex cun software e software open source +Chapitel 5:: Creation: concurs per software e prestaziuns en connex cun l'art. 9 EMBAG +Chapitel 6:: Consumption: acquist da software: tractanda eguala dal software open source +Chapitel 7:: Consumption: acquist da prestaziuns supplementaras (support/mantenziun/svilup vinavant) per l'OSS +Chapitel 8:: Collaboration: aspects dal dretg d'acquist da collavuraziuns per la creaziun, la mantenziun ed il support da l'OSS +Chapitel 9:: Contribution: contribuziuns a projects OSS + +== Suveranitad digitala ed acquist + +=== Introducziun en la suveranitad digitala e l'OSS + +Cun l'art. 9 EMBAG dat l'administraziun federala, cun publitgar ses software sco OSS, ina contribuziun impurtanta a la persistenza ed a la suveranitad digitalas. + +La suveranitad digitala n'è betg in intent per sasez, mabain ina premissa per in'administraziun effizienta, democratica ed orientada al futur. Ella è in concept cun bleras fatschas cun dimensiuns tecnologicas, organisatoricas e politicas. + +**** +*Suveranitad digitala munta che il stadi dispona da la controlla e da la capacitad d'agir necessarias en il spazi digital per garantir l'adempliment da las incumbensas statalas.* +**** + +En spezial tar l'acquist da software ston vegnir resguardads ils effects sin la suveranitad digitala da l'administraziun federala. + +En ses *rols sco utilisadra, manadra ed incumbensadra* en il sectur da las TIC e dal software po l'administraziun federala prender conscientamain sia responsabladad en quest sectur. + +En il sectur dal software existan trais finamiras strategicas: + +*Substituibilitad*: [.underline]#Sco utilisadra# aspira l'administraziun publica da pudair tscherner libramain e flexibelmain tranter purschiders, soluziuns informaticas e tecnologias. Quai premetta la disponibladad d'alternativas effizientas e cumprovadas sco er architecturas informaticas, vias d'acquist ed ina dotaziun da persunal ch'èn concepidas per facilitar ina midada. + +*Capacitad da configuraziun*: [.underline]#Sco manadra d'informatica# dispona l'administraziun publica da la capacitad da configurar e da co-configurar ses sistems informatics. Per quai dispona ella da la savida necessaria e da structuras cooperativas adattadas per chapir e valitar soluziuns informaticas e per garantir sche necessari lur svilup, lur svilup vinavant e lur manaschi. + +*Influenza*: [.underline]#Sco incumbensadra# po l'administraziun publica formular ed imponer sias pretensiuns e ses basegns vers ils purschiders da tecnologia. Quai vala per las caracteristicas dals products (funcziuns, opziuns da manaschi, disponibladad, segirezza da las infurmaziuns e protecziun da datas etc.) sco er per la redacziun dals contracts ed ils models da licenza. + +*Standards averts* e *software open source* sustegnan quellas finamiras il meglier cun *princips open source*. + +L'OSS sustegna la suveranitad digitala uschia: + +* La segirezza informatica per l'administraziun publica, las infrastructuras criticas e las applicaziuns relevantas per la segirezza sa lascha garantir [.underline]#da tut temp# tras l'[.underline]#access cumplet# al code da funtauna. +* L'OSS pussibilitescha a posts publics da construir, da manar, da controllar e d'adattar lur atgna infrastructura informatica senza cundiziuns da licenza restrictivas. +* L'OSS porscha la controlla cumpletta davart actualisaziuns, funcziuns e patchs da segirezza, tant dal puntg da vista dal cuntegn sco er dal temp. +* L'OSS po impedir la dependenza da singuls purschiders u models da licenza e sustegna la substituibilitad. +* L'OSS permetta da represchentar e da suandar transparentamain l'entira chadaina da furniziun dal software. +* L'OSS sa lascha adattar ed extender – bain adattà a las pretensiuns specificas d'autoritads ed instituziuns da furmaziun, quai che premetta dentant enconuschientschas profundas dals agens collaboraturs. +* Investiziuns en l'OSS van era a bun da interpresas e communitads localas (creaziun da valur locala) ed augmentan la resilienza da l'economia svizra. +* L'OSS sa basa sin la collavuraziun e sin interfatschas avertas, facilitescha l'interoperabilitad tranter sistems e promova standards averts – era sur ils cunfins naziunals ora. +* L'OSS meglierescha la segirezza informatica e la segirezza da las datas tras la transparenza e l'adattabladad. +* Software OSS licenzià sut licenzas OSI garantescha cundiziuns giuridicas cleras e continuitad sco er las libertads fundamentalas da l'OSS e protegia tant las sviluppadras ed ils sviluppaders sco era las utilisadras ed ils utilisaders. + +*Standards averts:* Per sustegnair la substituibilitad dal software duessan concurs publics pretender l'observaziun da standards averts,footnote:[Per exempel standards averts sco eCH, ODF; vesair era https://de.wikipedia.org/wiki/Offener_Standard[Standard avert – Wikipedia]] e uschia minimar il lock-in. +*Interfatschas avertas:* Era las interfatschas duessan vegnir publitgadas per pussibilitar l'interoperabilitad. + +Las autoritads federalas èn fundamentalmain obligadas d'observar ils standards eCH.footnote:[https://www.ech.ch/[www.ech.ch]] + +La Scola auta spezialisada bernaisa ha exponì las reflexiuns relevantas en il studi _Perspectivas tecnologicas da la suveranitad digitala_ [Stü2024], elavurà per incumbensa dal DFAE, cun agid dal model «chasa da la suveranitad», en il qual il software vegn preschentà sco pitgun purtant. En quest model èn ils strats sut il tetg – collavuraziun, cumpetenzas tecnologicas, ils quatter pitguns e regulaziuns – ils secturs, en ils quals las mesiras recumandadas promovan la suveranitad digitala. + +[mermaid,align="center",alt="Represchentaziun schematica dals aspects da la suveranitad digitala che pussibiliteschan la purschida da products e servetschs innovativs"] +.... +block-beta + columns 4 + Roof["Products e servetschs digitals innovativs
da interpresas ed autoritads"]:4 + space:4 + Collab["Collavuraziun cun la perscrutaziun e la societad civila"]:4 + Skills["Cumpetenzas tecnologicas (programmaziun, data science etc.)"]:4 + SW["Software"] Data["Datas e
cuntegns digitals"] AI["Intelligenza
artifiziala"] Infra["Infrastructura TIC
(hardware)"] + Reg["Regulaziuns (leschas, standards)"]:4 + Collab-- "pussibiliteschan" -->Roof +.... + +_Illustraziun 2: Represchentaziun schematica dals aspects da la suveranitad digitala che pussibiliteschan la purschida da products e servetschs innovativs [Stü2024]_ + +=== Mesirar la suveranitad digitala + +Aspects da la suveranitad digitala pon vegnir pretendids en in concurs public, ma talas pretensiuns ston esser motivadas objectivamain. Ina preferenza generala per l'OSS n'exista betg. + +*Co sa lascha pia mesirar il grad da suveranitad digitala per ina tscherta tecnologia, in product u in servetsch?* + +Questa operaziunalisaziun sto vegnir fatga uschè objectivamain e transparentamain sco pussaivel. + +Differentas iniziativas empruvan quai. L'OSBA ha per exempel sviluppà in **index da suveranitad**footnote:[https://osb-alliance.de/featured/ein-index-fuer-digitale-souveraenitaet[In index per la suveranitad digitala | OSBA – Open Source Business Alliance]] _[OSBA-VK]_. _Nextcloud_ ha publitgà in Digital Sovereignty Index (DSI)footnote:[https://dsi.nextcloud.com/[dsi.nextcloud.com]] che cumparegliescha entirs pajais, ma po era furnir criteris utils. +L'Uniun europeica ha publitgà per il cloud in Cloud Sovereignty Framework.footnote:[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]] +Il _Center per la suveranitad digitala ZenDiS_ lavura ad ina controlla da suveranitad cun la quala soluziuns informaticas ed organisaziuns duain vegnir valitadas sin la basa da criteris da suveranitad transparents. + +Era l'administraziun federala è participada al svilup d'in *framework per la suveranitad digitala* cun il qual il grad d'adempliment po vegnir determinà tranter auter sur differentas perspectivas. + +Perspectivas pussaivlas èn: + +A -- Controlla tecnologica:: +Quant lunsch ha l'administraziun federala la controlla davart las tecnologias duvradas e lur svilup vinavant? + +B -- Suveranitad da las datas:: +Tgi ha access a las datas, la controlla davart ellas ed il pudair da decider – en spezial tar datas administrativas sensiblas? + +C -- Capacitad giuridica d'agir:: +Quant lunsch pon la Svizra e l'administraziun federala influenzar las cundiziuns basicas giuridicas e politicas da la digitalisaziun? + +D -- Resilienza:: +Quant robusts e resistents en cas da crisa èn ils sistems ed ils process digitals da l'administraziun federala envers disturbis, crisas e dependenzas? + +E -- Controlla economica:: +Co po l'administraziun federala exercitar ina controlla economica ed in sourcing strategic per garantir sia suveranitad digitala en moda effizienta areguard ils custs e per minimar a medem temp dependenzas e ristgs en l'acquist informatic? + +Per mintgina da questas perspectivas sa lascha determinar il grad da suveranitad digitala cun agid d'ina scala anc da definir: + +0 -- Determinà da terzs / betg suveran:: +Nagina controlla davart sistems, datas u infrastructura; nagina transparenza, grondas dependenzas; naginas opziuns d'exit u alternativas + +1 -- Controllà minimalmain:: +Emprimas enconuschientschas davart l'utilisaziun e las dependenzas; mecanissems da controlla puntuals; lacunas operativas, giuridicas u tecnologicas persistan + +2 -- Utilisabel en moda reglamentada:: +Sistems fidaivels e per part controllabels; rom giuridic e tecnic stabilì; dependenzas strategicas persistan + +3 -- Autoregulà e resilient:: +La posiziun sin il martgà vegn duvrada; strategias d'exit e concepts multifurnitur implementads; know-how construì; resilienza e scenaris da crisa preparads + +4 -- Suveran sistemicamain:: +Suveranitad en tut las dimensiuns relevantas (giuridica, tecnologica, culturala, strategica); format activ dal martgà e dals standards; effect geopolitic pussaivel + +_Illustraziun 3: Grad da la suveranitad digitala._ + +Questas duas dimensiuns dattan la suandanta matrix: + +[.landscape] +[cols="2,^1,^1,^1,^1,^1",options="header"] +|=== +|Perspectiva +|0 + +Determinà da terzs +|1 + +Controllà minimalmain +|2 + +Utilisabel en moda reglamentada +|3 + +Autoregulà e resilient +|4 + +Suveran sistemicamain + +|A -- Controlla tecnologica +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|B -- Suveranitad da las datas +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|C -- Capacitad giuridica d'agir +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|D -- Resilienza +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} + +|E -- Controlla economica +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +a| +[%interactive] +* [ ] {empty} +|=== + +_Illustraziun 4: Matrix suveranitad digitala: perspectivas ed il grad da suveranitad._ + +Per ils singuls champs da cruschada da la grilla pon vegnir descrits criteris concrets per render la classificaziun uschè objectiva sco pussaivel. + +In tal framework vegn actualmain sviluppà en il rom da l'accent 4 «Rinforzar la suveranitad digitala» da la «Strategia Administraziun federala digitala».footnote:[https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/digitale-bundesverwaltung.html[www.bk.admin.ch – Administraziun federala digitala]] + +Il Cussegl federal ha mess en vigur la directiva da tetg Suveranitad digitala en l'administraziun federalafootnote:[W012 - Directivas per la suveranitad digitala en l'administraziun federala] sin il 1. da schaner 2026. Projects ston integrar ils differents aspects en la definiziun da l'object d'acquist e sche necessari en in concurs, sin la basa dal basegn concret da suveranitad – per exempel dal puntg da vista dal ristg en il rom dal business continuity management. + +== Cas d'applicaziun per l'acquist da software + +La tecnologia d'infurmaziun e da communicaziun (TIC) ed il software n'èn en l'administraziun federala nagin intent per sasez, mabain servan adina a l'adempliment d'in mandat legal. Vista la digitalisaziun che progredescha ed il rol central da l'administraziun federala en Svizra sto la tecnologia d'infurmaziun esser ina cumpetenza centrala da l'administraziun. + +Ils suandants *facturs* ageschan perquai directamain sin l'acquist: + +* *Digitalisaziun*: La strategia digitalafootnote:[https://digital.swiss/rm/] pretenda la digitalisaziun dals process. +* *Optimaziun dals process*: Process entaifer l'administraziun federala ed en sias relaziuns externas pon e duain vegnir optimads. +* *Suveranitad digitala*: L'impurtanza da la suveranitad digitala crescha cuntinuadamain; vesair _[Stü2024]_. +* Il princip *public money, public goods* e l'observaziun da l'art. 9 EMBAG. +* *Libertad economica*: Mesiras na duain betg restrenscher nunnecessariamain la libertad economica. +* Reflexiuns generalas da *segirezza*: La segirezza dals sistems che elavuran infurmaziuns survegn adina dapli impurtanza. +* Gestiun da crisas e da catastrofas (*resilienza*): Vista la situaziun mundiala actuala sto l'administraziun examinar, co ch'ella po metter a disposiziun vinavant ils meds da lavur necessaris era en circumstanzas criticas. +* Independenza strategica e reflexiuns davart la *chadaina da furniziun*: Quellas resultan da la suveranitad digitala e da la resilienza. +* Evitar/minimar il *vendor lock-in*: Dependenzas sa laschan bunamain betg evitar en l'informatica, ma la dependenza d'in sulet purschider duess vegnir reducida nua ch'igl è pussaivel. +* *Abilitaziun* da l'administraziun federalafootnote:[Betg mo tar las persunas da direcziun, las manadras ed ils manaders da project e las architectas ed ils architects TIC, mabain tar tut ils collaboraturs.] (inclusiv la direcziun) en dumondas TIC: La direcziun, il svilup ed il manaschi da la tecnologia d'infurmaziun pretendan cumpetenzas adequatas en l'entira schientscha da lavur. + +Quest document distingua ils suandants *tips da software*: + +* *Commodity – applicaziuns spezialisadas/branscha – applicaziuns spezialisadas/autoritad federala*: +** Applicaziun standard (software commodity) senza logica da fatschenta speziala. +** Applicaziun spezialisada: basegn specific da la branscha/da tut ils nivels federals u basegn specific da l'autoritad federala +* *Mirà – strategic – essenzial*: +** Applicaziun mirada +** Applicaziun strategica cun ina impurtanza considerabla per in'autoritad federala u per l'administraziun federala entira +** Essenziala e critica per la fatschenta – sto restar funcziunanta en mintga circumstanza (p.ex. controlla dal traffic aviatic) + +Applicaziuns pon vegnir duvradas en in u en plirs *secturs d'applicaziun*. + +Determinanta è qua la *standardisaziun* da las applicaziuns tenor product entaifer mintga sectur: + +* Nagina strategia +* Strategia d'in product +* Strategia da plirs products + +Ultra da la standardisaziun dals products, che sto vegnir examinada accuratamain, datti era la standardisaziun per l'interoperabilitad (formats da datas, API, elements da fatschenta).footnote:[P.ex. via eCH] +La standardisaziun _è permessa_, uschenavant ch'ella è proporziunada e na restrenscha betg nunlubidamain la concurrenza (p.ex. art. 30 al. 3 LAPub). Ella po reducir ils custs da manaschi e da mantenziun e generar effects da sinergia, en spezial sche tut ils nivels federals èn participads. Da l'autra vart augmenta ella il lock-in, la dependenza ed en part ils ristgs da segirezza (ristg da cluster). + +Ils custs totals da possess (TCO) – inclusiv manaschi, mantenziun e svilup vinavant – duessan adina vegnir resguardads tar l'acquist. Consequenzas da custs a lunga vista na dastgan betg vegnir surtratgas. Models da fatschenta open source sa distinguan en tscherta moda da quels da purschiders proprietars. + +Ils chapitels suandants sa concentreschan adina dapli sin l'open source e tractan il proceder d'acquist relevant e sia realisaziun. + +La tscherna tranter consumption, contribution, collaboration e creation vegn fatga _specificamain per mintga project_ tenor la rentabilitad e la situaziun giuridica, cun repartir ils custs uschè amplamain sco pussaivel. Da questa vista èn ils quatter C tenor link:em002.pdf[Em002 Directivas strategicas OSS], chapitel 3, ordinads en impurtanza decreschenta: + +image::./assets/four-cs/four-cs.rm.svg[Rang dals quatter C: Consumption, Contribution, Collaboration, Creation] + +. Consumption +. Contribution +. Collaboration +. Creation + +Tar la simpla *consumption* sa repartan ils custs sin in grond dumber d'auters utilisaders, ma l'autoritad federala n'ha nagina controlla davart il svilup vinavant. La creation è il cuntrari: controlla cumpletta, ma custs cumplets. + +Tar la *contribution* sa limitescha la despaisa finanziala a l'element sviluppà, che vegn suenter surdà ad in'autra organisaziun per la tgira. + +La *collaboration* è il scenari il pli cumplex, perquai che la concepziun po variar fitg. En il meglier cas vegnan ils custs dividids e l'autoritad federala ha avunda influenza per realisar sias pretensiuns senza cumpromiss (vesair chapitel 8). + +Idealmain croda sin la *creation* la part la pli pitschna. Software po vegnir sviluppà internamain, via prestaziuns u via in contract d'ovra. + +Pura consumption vegn ad esser pussaivla mo tar applicaziuns standard. + +=== Software pretenda prestaziuns supplementaras sco mantenziun, support e svilup vinavant. + +Schebain che applicaziuns open source pon vegnir utilisadas gratuitamain, pretenda lur utilisaziun strategica sur millis d'instanzas mantenziun, support e sche necessari svilup vinavant. + +Autoritads federalas han in interess ad in support a lunga vista per las versiuns duvradas (vesair chapitel 3.2.3 en _[BITKOM2024]_). + +L'art. 9 EMBAG sez cuvra mo il svilup u il svilup vinavant intern da software e n'è betg determinant per autras reflexiuns davart l'open source – qua valan enstagl la suveranitad digitala ed ulteriurs facturs. Restricziuns tenor l'art. 9 EMBAG tar singulas cumponentas da svilup pon dentant avair consequenzas per l'entir project, sche svilups proprietars u supplementars èn previsibels. Cun la collaboration sa laschan lura utilisar effects da sinergia e reducir sche pussaivel ils custs per l'administraziun federala en general. + +=== Obligaziun da publicaziun tar l'acquist da software + +Sche las pretensiuns inditgeschan in basegn d'adattaziun dal software u in basegn d'adattaziun posteriur pussaivel, è l'art. 9 EMBAG relevant e la publicaziun è obligatorica per quellas parts, uschenavant che nagina da las duas excepziuns na vala. Tar l'acquist d'ina soluziun open source fiss ina tala publicaziun gia cuverta tras ina contribuziun al project open source. Era sche l'acquist pertutga mo la licenziaziun da software standard u in acquist TIC che croda sut in'excepziun, ston svilups supplementars fundamentalmain vegnir publitgads; quai sto vegnir reflectà en ils documents d'acquist ed en la sbozza da contract. + +*L'obligaziun da publicaziun tenor l'art. 9 EMBAG è perquai relevanta per mintga acquist, tar il qual in svilup agen u in svilup vinavant è probabel* (vesair era _[KBB-MB]_). + +== Creation: concurs per software e prestaziuns cun connex a l'artitgel 9 EMBAG + +Quest chapitel tracta las consequenzas da l'art. 9 EMBAG per concurs per software e prestaziuns che pon cumpigliar la creaziun u la midada da software. + +El vala tant per l'administraziun federala centrala sco er per quella decentralisada. Excepziuns da questa obligaziun èn fixadas en l'ordinaziun davart la digitalisaziun _[DigiV]_. + +=== Relevanza da l'artitgel 9 EMBAG per la creaziun da software + +In vorgang croda en il champ d'applicaziun da l'art. 9 EMBAG, sch'el croda sut la categoria relevanta da la tabella 1. La decisiun make-or-buy resta centrala per l'acquist. L'analisa dals differents cas d'applicaziun mussa che fundamentalmain l'art. 9 EMBAG è relevant en tut ils cas, ordaifer sche software gia existent vegn acquistà (p.ex. puras licenzas). Il chapitel II.4 da la _directiva Open Source en l'acquist [BBL-WL]_ exponta il proceder strategic, e l'agiunta VII.A descriva en detagl, tge che vala sco software. Ina repartiziun detagliada da la decisiun strategica sa chatta en la tabella 1. + +[cols="3,2,4",options="header"] +|=== +|Cas d'applicaziun |Make or buy |Obligaziun da publicaziun tenor l'art. 9 al. 1 EMBAG + +|Sviluppar software entaifer l'administraziun federala +|Make +|Gea, obligaziun da publicaziun + +|Far sviluppar software tras terzas persunas +|Buy sco contract da prestaziuns informaticas + +|Gea, obligaziun da publicaziun + +|Acquistar software existent +|Buy +a|Fundamentalmain na, ma examinar, sch'i existan obligaziuns da publicaziun per parts da sviluppar. Spezialmain relevant è il tractament dals dretgs da terzas persunas (vesair link:em002-3.pdf[Em002-3 Guida da licenzas OSS]). + +|Surpigliar software dad auters posts publics +|Make u buy +a|– Entaifer l'administraziun federala: obligaziun da publicaziun da l'unitad administrativa che dat vinavant. + +– Auters: examinar en il cas singul, sch'adattaments tras l'administraziun federala chaschunan in'obligaziun da publicaziun, almain per quellas parts. + +|Acquistar resursas da svilup +|Make +|Gea, obligaziun da publicaziun (ils contracts ston permetter la publicaziun) + +|Collavurar cun auters posts publics tar il svilup da software +|Make +|Gea, obligaziun da publicaziun (ils contracts ston permetter la publicaziun), en spezial tar contribuziuns da svilup essenzialas tras u per la Confederaziun +|=== + +_Tabella 1: Classificaziun da l'obligaziun da publicaziun e da la decisiun make-or-buy (en adherenza ad ina tabella da Rika Koch, BFH)_ + +Indicaziun: L'art. 9 EMBAG sto era vegnir resguardà tar software existent e SaaS, sche il software duai vegnir sviluppà vinavant u adattà per la Confederaziun. Era sche la probabladad è pitschna, duess quai vegnir tractà en il process d'acquist. + +Nua ch'i dat basegn da sclerida, vegn recumandà link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source] sco referenza. Las glistas da controlla duessan vegnir *emplenidas provisoricamain uschè baud sco pussaivel* per projects potenzialmain relevants. Era la _glista da controlla excepziun integrala art. 9 EMBAG [BBL-CL]_ po vegnir duvrada per quai. + +=== Preparar in acquist tenor l'artitgel 9 EMBAG + +Supplementarmain als pass da preparaziun usitads duessan ils suandants dus documents adina vegnir consultads, sch'in acquist cumpiglia cumponentas da software: + +* _fegl d'infurmaziun davart l'acquist da software e l'art. 9 EMBAG [KBB-MB] e_ +* _directiva Open Source en l'acquist [BBL-WL]_. + +Nua che l'art. 9 EMBAG è cleramain relevant, duess l'unitad administrativa avair: + +* emplenì provisoricamain las glistas da controlla link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Evaluaziun preliminara OSS] fin link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Relaschada e publicaziun OSS]; +* prendì ina decisiun fundamentala, sch'ina licenza copyleft u permissiva vegn duvrada;footnote:[In'analisa pli profunda po vegnir fatga pli tard sche necessari cun agid da _Em002-3 Guida da licenzas OSS_.] +* tschertgà eventualas alternativas open source (u projects da basa potenzials per contributions/collaboration) tenor link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source], cun utilisar ils utensilis inditgads là per la retschertga e l'analisa dal martgà;footnote:[Vesair era link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala], chapitel 7.] +* scleri la structura d'ina eventuala communitad (link:em002-4.pdf[Em002-4 Guida da communitads OSS] e link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla Communitad OSS]). + +Sch'in project OSS existent duai vegnir duvrà, sustegnì u duai servir sco basa per ina collaboration, ston vegnir legids ils chapitels 5, 6, 8 e 9 da quest document. + +=== Creation via contracts da prestaziuns existents + +Sche la creation ha lieu via contracts da partenariat existents, sto la publicaziun OSS vegnir garantida il pli tard tar il mini-concurs, uschenavant che nagina da las duas excepziuns na vala. + +Novs concurs da prestaziuns duessan adina cuntegnair ina pretensiun da publicaziun tenor l'art. 9 EMBAG (vesair _[BBL-WL] e_ _[KBB-MB])_. + +=== Construir ina communitad + +Construir e tgirar ina communitad maximescha il profit dal software open source, ma è era collià cun ina lavur considerabla. + +Nua ch'ina communitad ed ina collaboration èn sensadas, ha quai consequenzas per l'acquist dal cumenzament. La link:em002-4-1-checklist-oss-community.pdf[glista da controlla Em002-4.1 Communitad OSS] duess perquai vegnir emplenida sin la basa da la link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +Sche l'autoritad federala duai surpigliar in rol impurtant en la communitad (p.ex. in rol da governanza) u sch'ina collavuraziun è planisada (vesair chapitel 8), po l'acquist da prestaziuns supplementaras esser necessari: construcziun da la communitad, consolidaziun da las pretensiuns, direcziun dal svilup vinavant. + +=== Criteris models ed elements contractuals per l'acquist informatic + +Il CCA maina in model da criteris d'acquist pussaivels sco er in model per in chapitel da contract da rom per concurs cun connex a software _[KBB-KV]_. + +Il CCA ha publitgà sin Perimap.admin.ch dus models che mussan, co che las pretensiuns minimalas per ina attribuziun conforma al dretg d'acquist tenor l'art. 9 EMBAG pon vegnir ademplidas. [KBB-KV] + +. https://perimap.admin.ch/goto_perimap_file_47064_download.html[Criteris models – Acquist EMBAG ed open source] +. https://perimap.admin.ch/goto_perimap_file_47059_download.html[Texts da contract models – Svilup da software] + +== Consumption: acquist da software: tractanda eguala dal software open source + +Quest chapitel tracta l'acquist e l'utilisaziun (consumption) da software open source e relevescha ils aspects strategics centrals. +I vegn ultra da quai renvià a _[BBL-WL] e_ _[KBB-MB]_. + +*Actualmain n'exista nagina preferenza prescritta da la lescha per software open source en l'acquist.* + +Tar concurs per applicaziuns informaticas vegnan resguardads tut ils tips da licenza ed ils models da fatschenta. Per ademplir las pretensiuns fixadas pon ils purschiders purscher soluziuns da software sin la basa da software open source nunmidà, closed source u proprietar, u sin la basa da cumbinaziuns da models da licenza e prestaziuns cun plivalur resp. abunaments. + +Ils suandants punctsfootnote:[Ils documents da referenza determinants per l'acquist èn quels publitgads da l'UFCL e dal CCA sin las plattafurmas correspundentas.] ston vegnir resguardads da las autoritads federalas: + +* Independentamain da la soluziun e dal model da licenza sto il purschider da prestaziuns inditgar en sia offerta, *tge cundiziuns da licenza che il recepient da prestaziuns sto observar tar l'utilisaziun da la prestaziun*. +* Il purschider da prestaziuns è *liber en la tscherna da la soluziun* cun la quala el vul ademplir las pretensiuns messas a concurs, sco era en la furma da la recumpensa ch'el vul survegnir (taxas da licenza, da mantenziun u d'abunament), uschenavant che quai è tecnicamain realisabel ed economicamain raschunaivel. +* L'entir *ciclus da vita* duess vegnir resguardà en las specificaziuns ed en la fixaziun dals pretschs. + +Quai pussibilitescha a l'administraziun federala da far valair ses interess areguard la proprietad intellectuala, la garanzia e la responsabladad – independentamain dal model da software u da licenza – sin il nivel da las cundiziuns generalas applitgablas e da las ancorar en il contract. + +Sche *adattaments dal software* vegnan fatgs per incumbensa u en adempliment d'in contract cun l'autoritad federala, vala l'art. 9 EMBAG. +Per precauziun duess il permiss da publicaziun vegnir pretendì gia en il concurs, perquai che l'experientscha mussa che adattaments daventan pli baud u pli tard necessaris, era sch'els n'èn betg previsibels al mument dal concurs. + +Sche il recepient da prestaziuns obtegna *prestaziuns cun plivalur* d'in purschider ultra dal software, porschan furniturs OSS savens in model d'abunament che porscha in post da contact local cun garanzias da garanzia e da responsabladad, supplementarmain a la relaziun directa cun ils possessurs dals dretgs immaterials sin las cumponentas OSS (che han savens lur sedia a l'exteriur e ch'èn en part nunenconuschents). + +=== L'OSS sco criteri strategic d'acquist + +Sch'ina autoritad federala vul acquistar software open source per motivs strategics, èn plirs scenaris pussaivels: + +* Concurs funcziunal senza criteris specifics per l'OSS. +Perquai che quai na porta naginas restricziuns, n'è necessaria nagina motivaziun speziala. +* Concurs funcziunal cun criteri d'aptitude, criteris tecnics e criteris d'attribuziun che pretendan open source, access cumplet al code da funtauna u experientscha cumprovabla cun publicaziuns open source. + +*Ina preferenza per l'open source è permessa dal puntg da vista dal dretg d'acquist, sche cun quai sa laschan ademplir (meglier) ils basegns concrets dal post che attribuescha*.footnote:[Vesair [BBL-WL\], [BBL-CL\], [KBB-MB\], [KBB-KV\]] + +In ulteriur motiv per preferir l'OSS – ultra da la suveranitad digitala – è che tar adattaments considerabels dal software tras l'administraziun ston quels vegnir publitgads tenor l'art. 9 EMBAG. +Ina publicaziun è il pli simpel, sche l'entir product è adina stà open source e sch'adattaments pon en part vegnir fatgs directamain en il product. Uschiglio sto vegnir definida in'excepziun e ston sche necessari parts dal code vegnir isoladas e tuttina relaschadas. + +=== L'utilisaziun gratuita da l'OSS na suttastat betg al dretg d'acquist. + +L'OSS po savens vegnir telechargià ed utilisà directamain. Il dretg d'acquist vala mo, sche prestaziuns vegnan obtegnidas da terzas persunas cunter pajament (inclusiv cuntraprestaziuns betg pecuniaras). + +Il telechargiar e l'utilisar gratuit da l'OSS na represchentan per sasez nagin acquist. + +Igl è era pussaivel d'acquistar pli tard las prestaziuns necessarias per OSS telechargià, uschenavant che quai na capita betg abusivamain.footnote:[Analogia: Ina vischnanca po utilisar agen lain e dar en incumbensa la construcziun d'in atgnadi cun quest lain – ella na sto betg acquistar sezza il lain.] + +Prestaziuns da mantenziun, da support e da svilup vinavant per il product vegnan lura messas a concurs separadamain tenor il dretg d'acquist. + +I dat gia exempels d'OSS che vegn duvrà gratuitamain sin las plazzas da lavur standard da l'administraziun federala e che na vegn perquai betg acquistà.footnote:[Exempels d'OSS cun potenzial da standardisaziun: Gimp, FileZilla, VLC Media Player e 7-zip sco products Shell 2 (tenor [A029\]) che pon vegnir duvrads, perquai che l'installaziun è gratuita. Il 2024 ha l'UFIT designà Red Hat OpenShift sco product strategic per tscherts secturs d'applicaziun pervia da sias caracteristicas tecnicas unicas. OpenShift è actualmain la plattafurma strategica per containers e sistems da manaschi.] + +=== Accordar las pretensiuns cun auters participants + +Ina applicaziun spezialisada pretenda adina ina purtadra dal basegn (per ordinari in uffizi federal). Per ordinari è sensa che il post cun il basegn accordia sias pretensiuns cun quellas dad auters posts administrativs – internamain u en il rom d'ina collaboration (vesair chapitel 8) – uschenavant ch'in product dal martgà disponibel u in svilup cuminaivel è profitabel per il svilup e l'introducziun. + +Sche blers participants han las medemas u sumegliantas pretensiuns, po valair la paina da cuvrir quests basegns sin ina basa cuminaivla. Quai vala per tuttas furmas da software. + +Dus aspects èn da resguardar: Sche adattaments vegnan fatgs pli tard d'ina autoritad federala sin giavisch da terzas persunas, vala puspè l'art. 9 EMBAG – quai è dentant senza problems, sche software open source vegn duvrà. + +Tar l'OSS ston las pretensiuns eventualmain vegnir accordadas pli activamain da l'autoritad federala, perquai ch'ina forza motrica sco in purschider commerzial che vul manar e sviluppar ses agen product po mancar. + +=== Resguardar ulteriurs acturs publics pussaivels tar l'acquist + +L'exempel ZenDiSfootnote:[https://www.zendis.de/en[https://www.zendis.de/] ZenDiS s'ha mess la finamira da liberar l'administraziun da dependenzas criticas da singuls purschiders da tecnologia.] mussa ch'i po esser tant realisabel sco era profitabel da far in concurs a medem temp sur tut ils nivels federals. + +*Ina concurrenza gista sto adina vegnir mantegnida.* Tar concurs sto adina vegnir examinà, sche la soluziun pudess vegnir acquistada sensadamain era per auters posts. + +Sche quai è il cas, ston quests auters clients potenzials vegnir contactads e ston lur basegns vegnir reflectads en ils documents dal concurs, en spezial en las pretensiuns. Ina tscherta flexibilitad en las pretensiuns è impurtanta en tals cas. + +Exempel: eOperations Svizra SA (http://www.eoperations.ch[www.eoperations.ch]) po vegnir duvrada per talas collavuraziuns. eOperations consolidescha las pretensiuns da differents posts ed exequescha sezza l'acquist, senza duvrar necessariamain il product sezza. Quai po era esser in model util per l'acquist da l'OSS. + +== Consumption: acquist da support e da mantenziun per l'OSS + +L'administraziun publica po utilisar software open source en differentas modas, dal simpel telechargiar ed installar fin a l'acquist formal (vesair chapitel 6.2). + +Sche l'OSS vegn duvrà en secturs critics, èn necessaris standards cuntinuadamain auts da segirezza,footnote:[Vesair era link:em002-6.pdf[Em002-6 FAQ-OSS], chapitel 5.3] da mantenziun e da svilup vinavant. Tar l'acquist regular da software vegn quai usitadamain cuvert dal concurs. Las pretensiuns valan tant per il software sez sco er per las bibliotecas ed ils frameworks utilisads. Il support e la mantenziun merita ina attenziun speziala, perquai che il svilup vinavant è savens cuvert dal medem contract e represchenta tuttina creation e croda uschia en il champ d'applicaziun da l'art. 9 EMBAG. + +Questas prestaziuns intensivas en lavur surpassan bunamain adina, quintadas sur l'entir ciclus da vita da l'applicaziun, il valur da sava tenor la lescha federala davart l'acquist public (LAPub). Sch'ellas vegnan obtegnidas da terzas persunas, sto vegnir observà il dretg d'acquist. Excepziuns pon valair, sco l'acquist entaifer il stadi tar in'autra incumbensadra publica,footnote:[Art. 10 al. 3 lit. b LAPub.] u en cas excepziunals l'acquist liber da prestaziuns spezialas.footnote:[Art. 21 al. 2 lit. c LAPub.] + +La tabella suandanta mussa las distincziuns dals cas per l'acquist da prestaziuns sco il support. + +[cols="1,1,1,2"] +|=== +2+h|Situaziun da partenza 2+h|Resultats + +h|Custs dal ciclus da vita + +→ valur da sava OMC?footnote:[Custs interns pon vegnir exclus. L'entir ciclus da vita sto vegnir resguardà.] +h|Entaifer il stadi?footnote:[L'acquist entaifer il stadi n'è betg suttamess al concurs: purtadras statalas èn necessarias, nagina participaziun al martgà. Vala mo entaifer il sectur public svizzer.] +h|Concurs OMC necessari?footnote:[Las directivas d'acquist da la Confederaziun valan adina, uschespert ch'in pajament vegn fatg.] +h|Remartgas + +|Na +|Na +|Na footnote:[Software cun support surpassa per ordinari il valur da sava LAPub; «na» vala mo en cas rars (p.ex. finanziaziun d'ina suletta funcziun per in project OSS existent).] +.2+|Darar in pachet da software cumplet cun support – per ordinari in pitschen support e singulas funcziuns. + +|Na +|Gea +|Na + +|Gea +|Na +|Gea +|Mo il volum vers terzas persunas è determinant. + +|Gea +|Gea +|Na +|Il concurs è vegnì fatg da l'auter post public. +|=== + +_Tabella 2: Distincziun dals cas – acquist da support_ + +=== Support e mantenziun fan adina part dal software + +Support e mantenziun èn indispensabels per il manaschi persistent da software en il rom d'autoritads. En in mund da zero-day-exploitsfootnote:[In zero-day-exploit designescha l'exploataziun d'ina largia da segirezza, per la quala i n'è anc disponibel nagin patch dal sviluppader da la cumponenta.] è in installar svelt e professiunal da patchs decisiv. Questa «infrastructura» sto vegnir finanziada – tant pli che l'administraziun ha pretensiuns pli autas ch'in consument privat. + +*La dumonda n'è perquai betg, SCHE support e mantenziun èn necessaris, mabain CO ch'els vegnan furnids.* + +L'autoritad federala sto determinar sin la basa da sias pretensiuns a la qualitad da la prestaziun, tge dimensiun da support, mantenziun, garanzia e responsabladad ch'ella dovra. + +Impurtant è ch'in purschider da prestaziuns per la mantenziun ed il support possia cumprovar ina experientscha suffizienta cun il product u cun la communitad open source pertutgada – mo lura vegn el ad esser abel da ademplir effizientamain questas incumbensas (vesair era _[KBB-MB]_, II.5).footnote:[Il contract da prestaziuns sto eventualmain era cuvrir il transferiment pussaivel da savida ad ina organisaziun successura.] + +Support e mantenziun ston era vegnir finanziads sin il nivel dal product. Sche nagin na contribuescha (il problem dal free ridingfootnote:[https://de.wikipedia.org/wiki/Trittbrettfahrerproblem]), è il futur dal project en privel ed uschia era ses diever en l'administraziun federala. Vista sia grondezza po vegnir spetgà raschunaivlamain da l'administraziun federala ch'ella sa participeschia als custs dal software ch'ella duvra strategicamain. + +=== Organisaziuns che pon furnir support + +La qualitad dal support ha in effect direct sin la cuntentientscha e la productivitad dals utilisaders finals. In sistem da support structurà cun temps da reacziun sperts e cun ina vaira cumpetenza tecnica garantescha che ils utilisaders e las administraturas ed ils administraturs survegnian soluziuns effizientas per lur problems, quai che spargna temp da lavur a l'incumbensadra e promova l'acceptanza da la soluziun da software. + +Per observar ils temps da reacziun convegnids contractualmain en ils service level agreements (SLA), sto il purschider disponer da persunal qualifitgà cun la savida necessaria. + +Funtaunas da support pussaivlas èn: + +*Intern*: + +* Uffizis federals +* Purschiders da prestaziuns + +*Entaifer il stadi*: + +* Autras incumbensadras publicas en Svizra +* Prestaziuns acquistadas dad autras incumbensadras publicas en Svizra + +*Terzas persunas*: + +* Prestaziun acquistada + +=== Svilup vinavant per funcziuns specificas + +Sch'ina autoritad federala dovra mo in dumber limità d'extensiuns specificas ad in software open source, po quai capitar cun resursas internas u cun prestaziuns acquistadas. + +Tals svilups vinavant duessan esser orientads a vegnir purschids al project original ed integrads en quel. Quai va betg mo a bun a l'ecosistem dal project, mabain garantescha che las extensiuns vegnian tgiradas vinavant en il project. Uschiglio po mintga nova versiun dal project original pretender ina actualisaziun manuala dal svilup individual (vesair era chapitel 8). + +=== Abunament + +Bleras interpresas e projects en il rom da l'open source porschan entaifer tschertas limitas in support gratuit che vegn furnì voluntarmain da tut ils utilisaders, principalmain via chanals averts sco forums e sistems da tickets publics. Questa purschida gratuita n'è betg concepida per utilisaders professiunals cun pretensiuns SLA specificas. + +Per utilisaders professiunals sco autoritads federalas èn savens disponibels abunaments OSS che cumpiglian garanzia, mantenziun e support. + +Tscherts purschiders porschan ultra da quai spezialas «versiuns enterprise» che n'ademplan betg pli ils criteris open source da l'OSI. + +Exempels d'abunaments: OpenShift da Red Hat, openDesk da ZenDiS + +=== Certificaziuns en il sectur open source ed OpenChain + +Sco tar software proprietar existan era en il sectur open source differentas certificaziuns. Per l'administraziun po valair la paina d'examinar avant in concurs, sch'i existan certificaziuns relevantas en il sectur pertutgà. + +*OpenChain* è ina norma ISO davart il svilup open source e la cumpatibilitad da las licenzas (vesair sutvart). + +Sch'i existan certificaziuns relevantas e sch'ellas èn determinantas per la prestaziun, ston ellas vegnir resguardadas en la giudicaziun dals purschiders. Impurtant è che la certificaziun sezza vala sco expressiva e ch'ils purschiders possian cumprovar ch'els èn abels da furnir la prestaziun era senza certificaziun. + +Vista la cumplexitad colliada cun quai n'è betg recumandabel da pretender certificaziuns sco criteri d'aptitude. Sco criteri d'attribuziun – cun la pussaivladad da cumprovar l'observaziun dals cuntegns da la certificaziun cun referenzas – pon ellas esser adequatas tut tenor il product OSS, uschenavant ch'igl è permess da duvrar referenzas per cumprovar l'adempliment dals criteris da certificaziun.footnote:[Indicaziun: Sch'ina certificaziun vegn pretendida ch'è exageradas u inadattada per l'object dal concurs, maina quai inevitablamain ad offertas main concurrenzialas.] + +Ina autocertificaziun tenor OpenChain po al pli servir sco substitut, sche nagina autra certificaziun n'exista. Referenzas che cuvran ils criteris determinants pon era remplazzar certificaziuns mancantas. + +*Certificaziun d'interpresas partenarias* + +Tscherts sviluppaders e projects open sourcefootnote:[sco Nextcloud u Univention] certifitgeschan interpresas partenarias cun las qualas els collavuran. Talas certificaziuns pon cumprovar ina relaziun existenta tranter il purschider ed il sviluppader dal software. Da resguardar è che blers projects OSS na porschan betg talas certificaziuns. Ina collavuraziun cumprovada en projects da referenza è in indicatur medemamain valid – e main restrictiv – per la qualitad giavischada. + +*Certificaziun da collaboraturs* + +Tscherts fabricants u communitads open sourcefootnote:[sco LibreOffice u RedHat] certifitgeschan persunas singulas cun savida speziala davart il software pertutgà. Sch'in purschider da prestaziuns occupa persunal certifitgà, po quai cumprovar savida tar la publicaziun upstream d'adattaments e da patchs sco er tar la furnitura d'in support da terz nivel da buna qualitad – en spezial sche plirs collaboraturs lavuran cun il product. Quai dependa era da la structura da l'ecosistem dal project OSS. + +Sco alternativa a certificaziuns po era ina experientscha da project cumprovabla en referenzas davart l'object d'acquist servir sco criteri da distincziun. + +*Standard OpenChain* + +Il standard OpenChain represchenta tant ina best practice per la cumpatibilitad da las licenzas sco era ina certificaziun interessanta per ils posts che acquistan. + +La norma ISO/IEC 5230 «OpenChain» sa concentrescha sin las chadainas da furniziun da software, sin in acquist sveltì e sin la conformitad da las licenzas. Il standard OpenChain po vegnir attribuì d'in post da certificaziun accredità u vegnir obtegnì cun ina autocertificaziun. Questa certificaziun è adattada per cumprovar en general ch'in purschider s'ha gia occupà a fund cun las pretensiuns da las licenzas open source e cun las particularitads da l'ecosistem open source. +Perquai che l'elavuraziun d'ina Software Bill of Materials (SBOM) fa part dal standard, cumprova questa certificaziun era l'engaschament d'in furnitur per la segirezza da la chadaina da furniziun tras il sustegn da cumponentas fundamentalas. + +=== Ulteriuras pussaivladads per acquistar prestaziuns da mantenziun, support u svilup vinavant + +Igl è sensa da tractar las prestaziuns da svilup vinavant en il medem contract sco il support e la mantenziun, perquai che la delimitaziun n'è betg adina clera ed è savens betg practicabla en il context dal software open source. Svilups vinavant finanziads d'ina autoritad federala crodan en il champ d'applicaziun da l'art. 9 EMBAG. + +Actualmain existan las suandantas pussaivladasfootnote:[Ulteriuras pussaivladads, pli nischadas, pon era exister.] per acquistar prestaziuns da support, da mantenziun e/u da svilup vinavant per l'OSS: + +* Intern, cun construcziun da cumpetenza: duvrar atgnas resursas da svilup +* Acquist: tenor il volum e cun observar la LAPub. Quai po era capitar via contracts da prestaziuns gia mess a concurs. Per che partenaris strategics possian metter a disposiziun sviluppaders centrals experimentads per projects OSS ch'èn centrals per l'administraziun federala, po esser sensa da permetter incumbensas en sutincumbensa u da pretender la savida correspundenta en tscherts concurs. +* Cunvegnas da cooperaziun cun terzas persunas per mantenziun, support u svilup vinavant: senza problems, uschè ditg che mintga partida porta ses agens custs. +* Participaziun da la Confederaziun ad organisaziuns: senza problems, uschè ditg che mintga partida porta ses agens custs. + +== Collaboration: aspects dal dretg d'acquist da la creaziun, mantenziun e dal support cuminaivels da l'OSS + +Ils custs dal software open source sa reduceschan, sch'el vegn sviluppà cuminaivlamain, saja quai informalmain u en ina furma structurada. La link:em002-4.pdf[Em002-4 Guida da communitads OSS] exponta ils proceders relevants. + +La collavuraziun cun autras incumbensadras publicas u cun terzas persunas è senza problems dal puntg da vista dal dretg d'acquist, uschè ditg che mintga partida porta ses agens custs. Difficultads nascha, sche da la collavuraziun na resulta nagin OSS, perquai che l'administraziun federala è liada a l'art. 9 EMBAG. + +Ina tala cooperaziun è permessa tenor l'art. 4 EMBAG. + +Da sclerir è la dumonda, co ch'i sto vegnir tractà cun custs generals u cun ina structura centrala: La structura dovra ina finanziaziun suffizienta per purtar il project era tras temps difficils. Ina alternativa è ina suletta partenaria manadra (p.ex. sch'in post participà è avunda grond per surpigliar il rol da coordinaziun). Sche l'autoritad federala surpiglia quest rol, ston las prestaziuns correspundentas vegnir furnidas internamain u vegnir messas a concurs sin la via usitada, sche terzas persunas duain vegnir integradas. + +Sin il nivel contractual vala per collavuraziuns quai che suonda: + +* Sche nagin daner na flueschia e sche naginas obligaziuns formalas n'èn necessarias, è in Memorandum of Understanding sin il nivel da l'uffizi federal u da la Chanzlia federala pussaivel. +* La creaziun d'ina structura cuminaivla – sco in'associaziun u ina corporaziun da dretg public – è fundamentalmain pussaivla, ma sto vegnir giuditgada en il cas singul. Sche la structura cuminaivla duai sezza acquistar prestaziuns da terzas persunas, sto vegnir reglada l'applicaziun dal dretg d'acquist. + +La commembranza po en tscherts cas vegnir exercitada via autras organisaziuns sco eOperations u eCH. + +*Collavuraziun cun l'exteriur* + +La collavuraziun cun autoritads a l'exteriur è senza problems, uschè ditg che nagin daner na flueschia e che naginas obligaziuns da tge gener ch'i saja na vegnan surpigliadas. + +Cunvegnas da cooperaziun sin il nivel adattà èn fundamentalmain pussaivlas, ma ston vegnir giuditgadas en il cas singul. +Da contracts internaziunals è d'evitar vista las autas savas, schebain ch'els fissan fundamentalmain era pussaivels. + +I existan dus cas spezialsfootnote:[https://www.eda.admin.ch/deza/de/home/partnerschaften/auftraege-beitraege/auftraege/anforderungen/rechtlich.html] en ils quals ina collavuraziun fiss gia cuverta: + +* Incumbensas attribuidas en il rom d'ina cunvegna internaziunala per la realisaziun cuminaivla d'in project tras stadis signatars. +* Incumbensas attribuidas tenor las proceduras u cundiziuns spezialas d'ina organisaziun internaziunala. + +== Contribution: contribuziuns a projects OSS + +La gronda part da las caracteristicas e da las reflexiuns giuridicas davart las contribuziuns vegnan tractadas en la link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +Dal puntg da vista dal dretg d'acquist èn las contribuziuns fundamentalmain senza problems, perquai che las prestaziuns vegnan furnidas per sviluppar code per in project ch'è u directamain relevant per l'autoritad u ch'è gia vegnì tractà dal puntg da vista dal dretg d'acquist. + +*Contribuziuns da terzas persunas a projects OSS d'autoritads federalas èn era senza problems dal puntg da vista dal dretg d'acquist, uschè ditg che nagin daner na flueschia.* + +Indicaziun: Perquai che l'autoritad federala è obligada da publitgar il software ch'ella sviluppa, sto ella era garantir ch'el restia publitgà. Sch'in project OSS vegn stizzà da ses manaders, sto l'autoritad federala en il pes cas il publitgar danovamain independentamain. En la pratica resta il code da funtauna tipicamain disponibel (p.ex. sco archiv), il project vegn manà vinavant sco fork, u il project – ed uschia il code da funtauna – n'è simplamain betg pli relevant. + +== Agiunta A: Referenzas: + +Ina part considerabla da las referenzas è _gia inditgada en Em002 Directivas strategicas per software open source en l'administraziun federala_. + +include::partials/references.rm.adoc[tags=ref-em002-7] + +== Agiunta B: Glossari + +Quest glossari tracta terms specifics davart temas d'acquist. + +Il glossari general per la seria da documents Em002 sa chatta en Em002-6 OSS-FAQ. + +Ulteriurs terms sa chattan en la https://www.bk.admin.ch/bk/de/home/dokumentation/sprachen/termdat.html[banca da datas terminologica TERMDAT da l'administraziun federala]. + +include::partials/glossary.rm.adoc[tags=gloss-em002-7] +endif::[] diff --git a/docs/em002.adoc b/docs/em002.adoc new file mode 100644 index 0000000..e6fd90c --- /dev/null +++ b/docs/em002.adoc @@ -0,0 +1,1335 @@ +:lang: en +ifeval::["{lang}" == "en"] += Em002 Strategic Guidelines for Open Source Software in the Federal Administration +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Em002 Linee guida strategiche per il software open source nell'Amministrazione federale +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Em002 Directivas strategicas per software open source en l'administraziun federala +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// The Confederation logo in colour. open-govpress falls back to `black` for any +// value it does not recognise, `colour` being the one synonym it takes, so the +// spelling here is the whole of the choice. +:title-logo-base: color +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// The repository, written as `{url-repo}` throughout the body. open-govpress +// reads nothing here; this is its own documented idiom for an author-defined +// attribute that saves repetition (see the `showcase.adoc` it ships). +:url-repo: https://github.com/swiss/opensource-guidelines +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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:{url-repo}/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.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. + +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/four-cs/four-cs.en.svg[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.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. + +*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.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.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. + +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.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.pdf[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. + +include::partials/document-map.en.adoc[] + +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 overview 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. + +A) Compliance with legal requirements (EMOTA):: +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:: +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:: +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:: +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:: +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 link:em002-1.pdf[Em002-1]_.:: +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.pdf[EM002-6 FAQ about Publishing OSS (OSS-FAQ)] are available. + +Measure 2: Implement the Instructions for Publishing Open Source Software link:em002-2.pdf[Em002-2] 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 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. ++ +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:: +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.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:: +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.pdf[Em002-4 OSS Community Guidelines.]] + +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 repository (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 '`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 references list the documents relating to the document set for link:em002.pdf[Em002 Tools for Open Source Software] in the Federal Administration. + +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. {url-repo} + +include::partials/references.en.adoc[tags=ref-em002-tools] + +Visual overview of OSS tools: + +include::partials/document-map.en.adoc[] + +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*]. + +include::partials/references.en.adoc[tags=ref-em002-general] + +=== 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.pdf[Em002-6 FAQ about Publishing OSS]. + +[horizontal] +include::partials/abbreviations.en.adoc[tags=abbr-em002] +endif::[] + +ifeval::["{lang}" == "de"] +NOTE: 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 link:{url-repo}/tree/main[README]. + +''' + +== Einleitung + +=== Ziel und Zweck + +Nach Artikel 9 Absatz 1 des Bundesgesetzes vom 17. März 2023footnote:[SR 172.019] über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) müssen Behörden den Quellcode von Software offenlegen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen, sofern nicht Rechte Dritter oder sicherheitsrelevante Gründe dies ausschliessen oder einschränken. Damit entfällt die Rechtsunsicherheit bei der Veröffentlichung von Software durch Bundesbehörden. + +In den vergangenen Jahren hat sich gezeigt, dass die Bedeutung von Open-Source-Software (OSS) in der Bundesverwaltung insgesamt weiter zugenommen hat. + +Diese strategischen Leitlinien beschreiben die Grundlagen von Open-Source-Software und den Umgang damit in der Bundesverwaltung. Das Dokument legt sechs Ziele fest und schlägt neun Massnahmen zu deren Erfüllung vor. + +Es verweist zudem auf weitere relevante Strategien der öffentlichen Hand zum Thema Open Source. + +=== Ausgangslage + +2005 veröffentlichte das Informatiksteuerungsorgan des Bundes (ISB) die erste Fassung einer OSS-Strategie für die Bundesverwaltung. Als wichtigster Grundsatz wurde damals die Gleichbehandlung von OSS mit Closed-Source-Software bei der Beschaffung festgelegt. + +Seit der Veröffentlichung 2005 hat die Verbreitung von Open-Source-Software stetig zugenommen. Heute nutzt gemäss dem Bericht «Open Source Studie Schweiz 2024» eine deutliche Mehrheit der Unternehmen und Behörden Open-Source-Software in vielen unterschiedlichen Bereichen. In der Softwarebranche gibt es nur sehr wenige Unternehmen, die nicht mit Open-Source-Werkzeugen und -Komponenten arbeiten. + +Am 1. Februar 2019 traten diese Strategischen Leitlinien für Open-Source-Software in der Bundesverwaltung sowie der Praxisleitfaden als Version 1.0 in Kraft. Mit dem Erlass des EMBAG und den neuen Pflichten nach Artikel 9 wurde es notwendig, beide Dokumente auf den neuen Stand zu bringen und zusätzliche Hilfsmittel für die Bundesbehörden zu schaffen. + +=== Vorgehen + +Für die Umsetzung des EMBAG sind die Bundesämter selbst verantwortlich. Angesichts der wachsenden Bedeutung von Open Source wurde jedoch entschieden, den Praxisleitfaden _link:em002-1.pdf[Em002-1]_ gemeinsam mit allen Anspruchsgruppen zu überarbeiten. Zudem wurden zusätzliche Hilfsmittel für die Umsetzung des EMBAG ergänzt. + +Der Praxisleitfaden definiert die notwendigen Begriffe, legt die Konstellationen für den Einsatz von Open-Source-Software dar, zeigt, wo und wie Alternativen zu bestehender kommerzieller Software gefunden werden können, wie Open Source beschafft werden soll, welche Geschäftsmodelle es für Open Source gibt und welche Supportmodelle beim Einsatz von Open Source möglich sind. Die weiteren Hilfsmittel beantworten häufig gestellte Fragen und geben Anleitung zur Freigabe von Open-Source-Software nach EMBAG. Sie behandeln sämtliche Fragen rund um OSS-Lizenzen und zeigen, wie eine Community um eine Software aufgebaut werden kann. Mehrere Checklisten zur Orientierung und Dokumentation stehen den Bundesbehörden ebenfalls zur Verfügung. + +Auch die Dokumente zur Beschaffung wurden angepasst, und es wurden ein zusätzliches Merkblatt [KBB-MB], eine Wegleitung [BBL-WL] sowie eine Checkliste [BBL-CL] erarbeitet. + +Bestehende Unsicherheiten werden mit diesen strategischen Leitlinien, dem begleitenden Praxisleitfaden und den Handlungsempfehlungen sowie den zusätzlichen Hilfsmitteln so weit wie möglich ausgeräumt. + +== Bezug zu anderen Strategien + +Diese Strategischen Leitlinien für Open-Source-Software in der Bundesverwaltung sind auf vier aktuelle Strategien der öffentlichen Hand und auf das EMBAG abgestimmt.footnote:[SR 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/de] Diese enthalten einen direkten oder indirekten Bezug zum Thema Open-Source-Software und zur IT-Zusammenarbeit zwischen öffentlichen Institutionen: + +Die *Strategie Digitale Bundesverwaltung* [SB001] legt acht Grundsätze und vier Schwerpunkte fest. Mit dem Einsatz von Open-Source-Software leistet die Bundesverwaltung einen Beitrag zum Schwerpunkt 4 «Digitale Souveränität stärken». Eine Open-Source-Lösung kann beliebig oft wiederverwendet und aufgrund ihres offenen Quellcodes an die individuellen Bedürfnisse der Bundesverwaltung angepasst werden. + +Der Gedanke der digitalen Nachhaltigkeit und der digitalen Souveränität kommt auch in der **Strategie Digitale Verwaltung Schweiz 2024–2027**footnote:[Strategie Digitale Verwaltung Schweiz 2024–2027: https://www.digital-public-services-switzerland.ch/strategy] zum Tragen. Bund und Kantone schaffen für diese Mehrfachnutzung geeignete Rahmenbedingungen. Basismodule für den Ausbau von E-Government werden «einmal umgesetzt und gemeinsam genutzt». Die Wahl von Open-Source-Software erleichtert die Wiederverwendung von IT-Lösungen. + +Gemäss der **Strategie Digitale Schweiz**footnote:[https://digital.swiss/de/] ist es für den Erfolg der Schweiz im digitalen Raum entscheidend, die Vernetzung der föderalen Ebenen zu stärken. Besonderes Augenmerk ist daher auf die Koordination zwischen Bund, Kantonen und Gemeinden sowie auf die Zusammenarbeit zwischen den schweizweit im Bereich der Digitalisierung tätigen Organisationen zu legen. Der Bundesrat mass zudem der digitalen Souveränität der Schweiz als Fokusthema 2023 besondere Bedeutung bei.footnote:[https://digital.swiss/de/strategie/fokusthemen/digitale-souveraenitaet] + +In der **Strategie Open Government Data Schweiz (2019–2023)**footnote:[Strategie Open Government Data 2019 – 2023] hält der Bundesrat fest, dass Daten der Bundesverwaltung, die nicht personenbezogen und nicht sicherheitskritisch sind, nach dem Grundsatz Open by Default veröffentlicht werden sollen. Die Bundesverwaltung hat hierfür das Portal opendata.swiss lanciert.footnote:[https://opendata.swiss/de] Bundesämter, Kantone, Städte und weitere öffentliche Organisationen haben dort derzeit über 11 700 Datensätze veröffentlicht. + +Der Masterplan Open Government Data 2024–2027footnote:[https://www.bfs.admin.ch/asset/de/28425806] setzt den Grundsatz Open by Default um. + +== Governance und Hilfsmittel + +Wenn von Open-Source-Software die Rede ist, muss zwischen *Consuming* (Nutzen), *Contributing* (Beitragen zu bestehendem Code) und *Creating* (also neuen Projekten) unterschieden werden. + +image::./assets/four-cs/four-cs.de.svg[Die 4 C im Kontext von OSS] + +Abbildung 1: Die 4 C im Kontext von OSS + +*Collaboration* ist zudem stets im Hintergrund denkbar. Beim Creating muss sie von der Bundesverwaltung angestossen werden, beim Contributing besteht sie bereits, und beim Consuming kann sie ebenfalls hilfreich sein (z. B. Anwendergruppe). + +Beim *Consuming* von Open-Source-Software soll diese gleichwertig zu proprietärer Software behandelt und bewertet werden. + +Beim *Entwickeln* von Software ist die Open-Source-Freigabe grundsätzlich obligatorisch, vorbehältlich der in Art. 9 EMBAG festgelegten Ausnahmen (Rechte Dritter und sicherheitsrelevante Gründe). + +Diese Ausnahmen werden in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] behandelt. + +Die Bundesbehörden, also die Verwaltungseinheiten der Bundesverwaltung, sind selbst für die korrekte Einhaltung verantwortlich; es gibt keine zentrale Zuständigkeit. + +Die *Veröffentlichung* bringt insbesondere dann Mehrwert, wenn eine *Community* von Interessierten entsteht und gemeinsam an der Software arbeitet. Arbeitet die Community an einem Projekt mit und lässt die Bundesverwaltung diese Beiträge zu, so entstehen wirtschaftlicher Nutzen und Synergieeffekte.footnote:[https://test.bitkom.org/sites/main/files/2023-03/BitkomLeitfadenOpenSourceSoftware31.pdf, Kapitel 4] + +In der Praxis umfasst die Freigabe oft nicht nur den Quellcode, sondern auch alle weiteren Aspekte (Dokumentation, Governance, Build-Anleitungen usw.). + +Grundsätzlich besteht für die Bundesverwaltung keine Pflicht, Communities aufzubauen; der gesetzliche Auftrag verlangt lediglich die Veröffentlichung des Quellcodes. Die Bundesverwaltung sollte vorrangig dort in Communities investieren, wo der Nutzen für den Bund und für Dritte gross und der Aufwand möglichst gering ist. + +Derzeit gibt es keine gemeinsame Plattform des Bundes für das *Entwickeln und Veröffentlichen von Quellcode*. Jede Behörde muss daher selbst eine Plattform (Repository) für die Veröffentlichung wählen. Der Praxisleitfaden in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] und die zugehörigen Checklisten legen fest, wie mit einer Plattform zu arbeiten ist und welche Eigenschaften sie erfüllen muss. + +Die *Lizenzwahl* wird im Leitfaden OSS-Lizenzierung link:em002-3.pdf[Em002-3]) behandelt, der eine Auswahl von Standardlizenzen vorstellt und deren Einsatz erläutert. Eigene Lizenztexte soll die Bundesverwaltung nur in begründeten Fällen nach Art. 9 Abs. 4 EMBAG verwenden. + +Beim Einsatz und bei der Entwicklung von OSS ist der **Support**footnote:[Mindestens während des Lebenszyklus mittels Verträgen oder einer Community.] stets zu regeln (auch wenn darauf verzichtet wird). Die zuständige Verwaltungseinheit regelt dies im Freigabeprozess oder bei der Definition der Community. Das EMBAG macht hierzu keine Vorgaben, und es werden keine zusätzlichen Finanzmittel oder Personalressourcen für den Support bereitgestellt. Es kann sinnvoll sein, Support und gemeinsame Weiterentwicklung einzubeziehen, wo der Nutzen für Schweizer Behörden oder die Schweizer Wirtschaft als ausreichend gross erachtet wird (Ökosystemkosten) und/oder eine Kostenteilung oder Zusammenarbeit angestrebt wird. Übernimmt dies der Lieferant, so können seine Supportkosten von den Nutzenden getragen werden. + +Die *Beschaffung von OSS* erfolgt über den regulären Beschaffungsprozess der Bundesverwaltung. Das BBL stellt die entsprechenden Dokumente und Hilfsmittel bereit. + +Zusätzlich steht ein _Merkblatt zur Softwarebeschaffung und Art. 9 EMBAG_ zur Verfügungfootnote:[Verfügbar unter: https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html und https://perimap.admin.ch/goto_perimap_file_46835_download.html] _[KBB-MB]_ (siehe Abbildung 2). + +Rechtliche und praktische Überlegungen führen dazu, dass die Pflicht zur OSS-Freigabe unter Umständen an einen Lieferanten übertragen werden kann (bei der Ausschreibung oder im Betrieb). Die Beschaffungshilfsmittel und der Freigabeprozess bestimmen, wie dies mit dem Lieferanten anzugehen ist. Dies wird grösstenteils durch Ergänzungen bestehender Prozesse, Vertragsentwürfe und Hilfsmittel erreicht. + +Das organisatorische Vorgehen ist in link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software] und den zugehörigen Hilfsmitteln geregelt. + +*OSS wird beschaffungsrechtlich gleich behandelt wie proprietäre Software.* Da für OSS nach der Definition der Open Source Initiative (OSI) keine Lizenzgebühren anfallen, kann Software grundsätzlich ohne Ausschreibung heruntergeladen und genutzt werden. Nur die von Unternehmen zu erbringenden Leistungen (z. B. Support, Engineering) unterstehen dann dem Beschaffungsrecht und müssen ausgeschrieben werden. + +Wo nötig, werden die relevanten Aspekte aus den Hilfsmitteln in die Projektmanagementprozesse des Bundes (also HERMES) integriert. + +Open Development (direkte offene Entwicklung auf einem öffentlich zugänglichen Repository) und die Beteiligung an bestehenden Projekten (Contribution) werden ebenfalls in den Erläuterungen in link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] behandelt. + +=== Übersicht über die OSS-Dokumente + +Die folgende Grafik gibt einen Überblick über die für OSS relevanten Dokumente in der Bundesverwaltung. + +include::partials/document-map.de.adoc[] + +Abbildung 2: Dokumente im Zusammenhang mit Art. 9 EMBAG + +== Ziele + +Die folgenden übergeordneten, langfristigen Ziele zeigen, wie die Bundesverwaltung das Potenzial von Open-Source-Software nutzt und die Risiken und Herausforderungen angeht: + +A) Einhaltung der gesetzlichen Vorgaben (also des EMBAG):: Die Freigabe von Open-Source-Software richtet sich nach Artikel 9 EMBAG. Die Einhaltung dieser gesetzlichen Vorgabe ist ein zentraler Aspekt dieser Leitlinien und der zugehörigen Dokumente. Die Bundesbehörden sollen diesen Artikel einhalten und den Nutzen für die Bundesverwaltung und die Schweiz maximieren. Für die Umsetzung sind die Organisationseinheiten selbst verantwortlich. + +B) Innovation und Effizienz steigern:: Open-Source-Software bildet heute die Grundlage moderner IT. Aufbauend auf den Millionen frei verfügbarer Komponenten und Lösungen lassen sich eigenständige Anwendungen rasch entwickeln und betreiben. Die damit verbundenen Zeit- und Ressourceneinsparungen sowie die mit Open-Source-Software verbundenen Architekturprinzipien wie Interoperabilität, Agilität und Microservices steigern die Innovationsfähigkeit und Effizienz der Softwareentwicklung. Dies wiederum beschleunigt die Digitalisierung der Bundesverwaltung. Durch die Freigabe von Open-Source-Software kann die Übernahme digitaler Lösungen im Bundesumfeld beschleunigt und können Synergieeffekte genutzt werden. + +C) Eine Kultur der Zusammenarbeit fördern:: Open-Source-Software fördert durch das Teilen von Quellcode, offene Kommunikation und Praktiken der gemeinsamen Weiterentwicklung eine Kultur der Zusammenarbeit in der IT. Diese Grundsätze lassen sich anwenden, um die Zusammenarbeit in der IT innerhalb der Bundesverwaltung, mit den Kantonen und mit weiteren öffentlichen Institutionen zu verstärken. Dies stärkt die digitale Souveränität und verringert Abhängigkeiten von Softwareanbietern. + +D) Klarheit schaffen und Risiken minimieren:: Informationen zu häufig verwendeten Open-Source-Lizenzen sollen es der Bundesverwaltung ermöglichen, die richtigen Lizenzen auszuwählen. Dies minimiert rechtliche Risiken. Technische und rechtliche Empfehlungen befähigen die Bundesverwaltung, Open-Source-Software zu nutzen und freizugeben. + +E) Übersicht schaffen, um Synergien zu nutzen:: Open-Source-Software wird derzeit an zahlreichen Stellen innerhalb der Bundesverwaltung auf unterschiedliche Weise eingesetzt. Es ist viel Wissen und Erfahrung vorhanden, doch die Synergien lassen sich noch nicht nutzen, da eine Übersicht über die eingesetzten Open-Source-Lösungen fehlt. Eine solche Übersicht und die gemeinsame Beschaffung von Leistungen werden es ermöglichen, das Potenzial von Open-Source-Software besser auszuschöpfen, was Ressourcen spart und Synergien schafft. + +F) Attraktivität als IT-Arbeitgeber steigern:: Open-Source-Software ist bei vielen hoch qualifizierten IT-Fachpersonen beliebt. Der Einsatz moderner Open-Source-Technologien und die Anwendung von Open-Source-Entwicklungsmethoden motivieren viele Mitarbeitende und steigern die Attraktivität der Bundesverwaltung als Arbeitgeberin. Für den Einsatz von Open-Source-Software benötigt der Bund Fachpersonen mit Wissen und Erfahrung im Bereich Open-Source-Software; bei der Rekrutierung von Fachpersonen sollte daher darauf hingewirkt werden, das interne Open-Source-Know-how auszubauen. + +== Massnahmen + +Die folgenden Massnahmen sollen zur Erreichung der oben dargelegten Ziele beitragen. Die Massnahmen werden zu gegebener Zeit ergänzt oder ersetzt und an veränderte Gegebenheiten angepasst. + +Die folgende Übersicht veranschaulicht, wie die Ziele mit den entsprechenden Massnahmen verknüpft sind. Diese unterstützen die Umsetzung der jeweiligen Ziele, können sich aber auch auf andere Ziele auswirken. + +A) Einhaltung der gesetzlichen Vorgaben (EMBAG):: +1) Den _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung link:em002-1.pdf[Em002-1]_ umsetzen + +2) Die _Anleitung zur Veröffentlichung von Open-Source-Software link:em002-2.pdf[Em002-2]_ und die daraus abgeleiteten Hilfsmittel umsetzen. + +3) Die Beschaffungsstellen bauen Open-Source-Know-how auf und unterstützen damit die Bundesverwaltung. + +B) Innovation und Effizienz steigern:: +1) Den _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung link:em002-1.pdf[Em002-1]_ umsetzen + +3) Die Beschaffungsstellen können mit Open Source umgehen und Art. 9 EMBAG optimal unterstützen. + +8) Den Aufbau von Communities fördern + +C) Eine Kultur der Zusammenarbeit fördern:: +1) Den _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung link:em002-1.pdf[Em002-1]_ umsetzen + +4) Den Wissens- und Erfahrungsaustausch fördern + +8) Den Aufbau von Communities fördern + +9) Die Möglichkeit einer eigenen Veröffentlichungsplattform prüfen; Open Development fördern + +D) Klarheit schaffen und Risiken minimieren:: +1) Den _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung link:em002-1.pdf[Em002-1]_ umsetzen + +2) Die _Anleitung zur Veröffentlichung von Open-Source-Software link:em002-2.pdf[Em002-2]_ und die daraus abgeleiteten Hilfsmittel umsetzen. + +E) Übersicht schaffen, um Synergien zu nutzen:: +6) Die gemeinsame Beschaffung von Leistungen umsetzen + +7) Eine Übersicht über eingesetzte, freigegebene und mitentwickelte Open-Source-Software schaffen + +8) Den Aufbau von Communities fördern + +F) Attraktivität als IT-Arbeitgeber steigern:: +5) Eine Open-Source-Kultur fördern und kommunizieren + +8) Den Aufbau von Communities fördern + +=== Beschreibung der Massnahmen + +Massnahme 1: Den _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung link:em002-1.pdf[Em002-1]_ umsetzen.:: +Obwohl der Begriff Open-Source-Software bereits über 20 Jahre alt ist, führen die stetige Verbreitung von Open-Source-Software und die laufende Entwicklung von Anwendungsszenarien fortwährend zu neuen Praktiken und Fragen. Neu- und Weiterentwicklungen von Open-Source-Lösungen bilden zudem immer häufiger vollwertige Alternativen zu proprietärer Software. Mit dem EMBAG kommt die Pflicht zur Veröffentlichung von Eigenentwicklungen hinzu. ++ +Der _Praxisleitfaden für Open-Source-Software in der Bundesverwaltung_ gibt einen Überblick und eine Einführung in das Thema, zeigt die Vor- und Nachteile von Open-Source-Software auf und erläutert alle weiteren Hilfsmittel. Er enthält zudem Best Practices, bewährte Alternativen und praktische Empfehlungen dazu, wie die Bundesverwaltung mit Open-Source-Software umgehen soll. ++ +Dieser Praxisleitfaden und die weiteren Hilfsmittel sollen von den Bundesbehörden im Umgang mit Open-Source-Software und Freigaben genutzt und umgesetzt werden. ++ +Als kurze Einführung in das Thema stehen ein _Merkblatt zur Anwendung von Art. 9 EMBAG_ sowie link:em002-6.pdf[Em002-6 FAQ zur Veröffentlichung von OSS (OSS-FAQ)] zur Verfügung. + +Massnahme 2: Die Anleitung zur Veröffentlichung von Open-Source-Software link:em002-2.pdf[Em002-2] und die daraus abgeleiteten Hilfsmittel umsetzen.:: +Der effiziente Einsatz von OSS in der Softwareentwicklung erfordert oft Beiträge in Form von Fehlerbehebungen und funktionalen Erweiterungen. Mit dem EMBAG besteht zudem eine Pflicht zur Freigabe selbst erstellter Software. Die nötige Orientierung bieten verschiedene Hilfsmittel. ++ +Die Checklisten sind Teil der Anleitung zur Veröffentlichung von OSS. Sie sollen ergänzend zu den entsprechenden Richtlinien der Verwaltungseinheiten vor und während der Entwicklung eingesetzt werden. ++ +Behandelt wird auch der Umgang mit Legacy-Code nach Art. 9 EMBAG. Ziel ist es, pragmatische Lösungen zu finden und umzusetzen. ++ +Lizenzen sind im OSS-Umfeld besonders wichtig. Bei der Freigabe, Beschaffung und Nutzung von Software müssen die Lizenzen auf das rechtlich Machbare und die gewünschte Wirkung abgestimmt werden. Das nötige Wissen und die entsprechenden Entscheide sollen dokumentiert werden. In diesem Zusammenhang werden auch die erforderlichen Zusatzdokumente wie das Contributor Licence Agreement (CLA) bereitgestellt. ++ +Um die Anwendung von Art. 9 EMBAG zu erleichtern, werden Ergänzungen an der Projektmanagementmethode des Bundes (HERMES) vorgenommen. Die Verwaltungseinheiten sollen die notwendigen Hilfsmittel im regulären Prozess vorfinden. + +Massnahme 3: Die Beschaffungsstellen bauen Open-Source-Know-how auf und unterstützen damit die Bundesverwaltung.:: +Für die Beschaffungsaspekte wurde das neue link:em002-7.pdf[Em002-7 Strategische Aspekte der Beschaffung und OSS] erstellt. ++ +Zur Sicherstellung eines breiten Wettbewerbs verlangt die Beschaffung, dass Open- und Closed-Source-Software gleich behandelt werden. Die erhöhten Anforderungen im Zusammenhang mit Art. 9 EMBAG bezüglich der für die Softwareveröffentlichung zu beschaffenden Mittel sind zu berücksichtigen. ++ +Das Kompetenzzentrum Beschaffungswesen Bund (KBB) hat unter folgendem Link ein Merkblatt zur Softwarebeschaffung und Art. 9 EMBAG [KBB-MB] veröffentlicht: link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html]. ++ +Weitere Unterstützung steht im BBL-Intranet (nur aus dem Bundesnetz zugänglich) mit der link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[Wegleitung Open Source in der Beschaffung] [BBL-WL] und der 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[Checkliste Integral-Ausnahme Art. 9 EMBAG] [BBL-CL] zur Verfügung. + +Massnahme 4: Den Wissens- und Erfahrungsaustausch fördern:: +Das Erstellen und Nutzen von Open-Source-Software erfordert vertieftes, spezialisiertes Know-how. Gleichzeitig entwickeln sich Open-Source-Lösungen laufend weiter und es werden neue Open-Source-Projekte lanciert. Es ist daher eine Herausforderung, einen umfassenden Überblick über aktuelle Trends und Technologien zu behalten. ++ +Um den professionellen Einsatz von Open Source zu fördern und den Wissens- und Erfahrungsaustausch zu erleichtern, sollen Informationen innerhalb einer erweiterten Interessengemeinschaft geteilt und die Mitarbeitenden innerhalb der Bundesverwaltung kompetent unterstützt werden. + +Massnahme 5: Eine Open-Source-Kultur fördern und kommunizieren:: +Die fortschreitende Digitalisierung hat den Fachkräftemangel in der IT weiter verschärft. Dies erschwert auch den Leistungserbringern der Bundesverwaltung die Rekrutierung von qualifiziertem IT-Personal. Der Einsatz von Open-Source-Software und die damit verbundene Entwicklerkultur sind bekanntermassen ein Argument für Fachpersonen, sich auf solche Stellen zu bewerben. ++ +Um in der Öffentlichkeit als «Open-Source-freundliche» Arbeitgeberin wahrgenommen zu werden, sollen die verschiedenen Massnahmen und die eingesetzten Open-Source-Lösungen aktiv in Form eines Technologieradars kommuniziert werden.footnote:[Technologieradare sollen möglichst breit eingesetzt werden. Das heisst, wenn möglich auf Stufe der Bundesbehörden oder gar der Bundesverwaltung.] Für die Arbeitgeberattraktivität ist es zudem wichtig, Bundesangestellten zu erlauben, zu bestehender Open-Source-Software beizutragen. + +Massnahme 6: Die gemeinsame Beschaffung von Leistungen umsetzen:: +Wartung und Support von Open-Source-Software werden derzeit von internen Mitarbeitenden der Bundesverwaltung erbracht, während externe Lieferanten für bestimmte Open-Source-Lösungen Leistungen anbieten. Diese Leistungen werden häufig von den jeweiligen Ämtern eigenständig beschafft, was zu Doppelspurigkeiten und den damit verbundenen finanziellen Einbussen führen kann. ++ +Die gemeinsame Beschaffung von Leistungen für Open-Source-Software soll die Zuverlässigkeit von Wartung und Support im Betrieb erhöhen und den Einsatz von Open-Source-Lösungen vereinfachen. Auf Basis des Technologieradars (siehe Massnahme 5) sollen Leistungen für die am weitesten verbreiteten Open-Source-Systeme und -Technologien zentral beschafft werden. Diese Leistungen können anschliessend von allen Ämtern nach Bedarf bezogen werden.footnote:[Dies betrifft den Support für die eingesetzte Software. Support durch Dritte für nach EMBAG freigegebene Software ist möglich und kann verrechnet werden. Dies wird in link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] behandelt.] + +Massnahme 7: Eine Übersicht über eingesetzte, freigegebene und mitentwickelte Open-Source-Software schaffen.:: +Da beim Einsatz von Open-Source-Software keine Lizenzen gekauft werden müssen, entfällt oft der aufwendige Beschaffungsprozess. ++ +Dies erschwert die Nachverfolgung, wo die Bundesverwaltung welche Open-Source-Software einsetzt. Dadurch kann das Potenzial von Open-Source-Software – etwa die Nutzung von Synergien, die Bildung von Communities für den Erfahrungsaustausch usw. – nicht voll ausgeschöpft werden. ++ +Ein Technologieradar innerhalb der Bundesverwaltung soll einen Überblick darüber geben, wo welche Open-Source-Software eingesetzt wird und wer über welches Know-how verfügt. + +Massnahme 8: Den Aufbau von Communities fördern:: +Der Aufbau von und die Beteiligung an Communities für die Projektentwicklung sind für OSS sehr wichtig. Daraus ergeben sich erhebliche Synergien. Es kann sein, dass das Projekt bereits besteht und der Bund sich lediglich beteiligt, oder der Bund kann das Projekt leiten, oder es kann sich auch um eine Zusammenarbeit handeln. Auf eine Community zu verzichten, ist ebenfalls ein wichtiger Entscheid. Die direkte Entwicklung auf einem offenen Repository (ohne nachträgliche Freigabe) kann weitere Effizienzgewinne bringen und die gemeinsame Entwicklung fördern. Em002-4 bietet Orientierung und Motivation für den Aufbau von Communities durch die Bundesbehörden. + +Massnahme 9: Die Möglichkeit einer eigenen Veröffentlichungsplattform prüfen; Open Development fördern:: +Der Aufbau und Betrieb einer internen oder schweizerischen Veröffentlichungsplattform wird geprüft und nach einem entsprechenden Entscheid umgesetzt. ++ +Ziel einer eigenständigen Plattform für die Bundesverwaltung ist die Wahrung der digitalen Souveränität und Unabhängigkeit. Die Zusammenarbeit wird vereinfacht und gleichzeitig entsteht eine Übersicht über die Aktivitäten. ++ +Eine föderale Zusammenarbeit über alle Behörden der Schweiz hinweg (ähnlich opencode.de) wird geprüft (z. B. DVS oder eOperations Schweiz). + +== Anhänge + +=== Änderungen gegenüber der Vorversion + +* Kleinere redaktionelle Änderungen und Verbesserungen. +* Das Faktenblatt Em002-5 wurde durch das Merkblatt OSS-Hilfsmittel ersetzt. +* Neu hinzugekommen ist das Dokument «`link:em002-7.pdf[Em002-7 Beschaffung und OSS]`». +* Neue Grafik mit den 4 C im Kontext von OSS (Ergänzung um «Collaboration»). +* Neue Verweise auf BBL und KBB. + +=== Referenzen zu den OSS-Hilfsmitteln + +Die folgende Referenzliste führt die Dokumente zum Dokumentensatz link:em002.pdf[Em002 Hilfsmittel für Open-Source-Software] in der Bundesverwaltung auf. + +NOTE: Die Hilfsmittel und insbesondere die Checklisten beruhen teilweise auf den *OSS-Dokumenten des Kantons Bern*, die unter einer BSD3-Lizenz veröffentlicht sind (link:https://github.com/kanton-bern/oss[https://github.com/kanton-bern/oss]). + +Die aktuellen Em002-Dokumente werden auf der Seite OSS-Hilfsmittel der Bundeskanzlei veröffentlicht. https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html. + +Die Dokumente werden zudem auf GitHub veröffentlicht. Dort kann auch Rückmeldung gegeben werden. {url-repo} + +include::partials/references.de.adoc[tags=ref-em002-tools] + +Visuelle Übersicht über die OSS-Hilfsmittel: + +include::partials/document-map.de.adoc[] + +Abbildung 3: Dokumente im Zusammenhang mit Art. 9 EMBAG + +=== Allgemeine Referenzen + +Alle Referenzen zum Em002-Dokumentensatz finden sich hier *in Em002 Strategische Leitlinien [Em002*]. + +include::partials/references.de.adoc[tags=ref-em002-general] + +=== Abkürzungen + +Dieses Abkürzungsverzeichnis enthält alle im OSS-Dokumentensatz Em002 verwendeten Abkürzungen. Ein Glossar findet sich in link:em002-6.pdf[Em002-6 FAQ zur Veröffentlichung von OSS]. + +[horizontal] +include::partials/abbreviations.de.adoc[tags=abbr-em002] +endif::[] + +ifeval::["{lang}" == "fr"] +NOTE: 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 link:{url-repo}/tree/main[README] principal. + +''' + +== Introduction + +=== But et objet + +Conformément à l'article 9, alinéa 1, de la loi fédérale du 17 mars 2023footnote:[RS 172.019] sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA), les autorités doivent publier le code source des logiciels qu'elles développent ou font développer pour accomplir leurs tâches, pour autant que des droits de tiers ou des motifs relevant de la sécurité ne l'excluent ou ne le restreignent. L'insécurité juridique entourant la publication de logiciels par les autorités fédérales est ainsi levée. + +Ces dernières années ont montré que l'importance des logiciels open source (OSS) au sein de l'administration fédérale n'a globalement cessé de croître. + +Les présentes lignes directrices stratégiques décrivent les fondements des logiciels open source et la manière dont ceux-ci sont traités au sein de l'administration fédérale. Le document fixe six objectifs et propose neuf mesures pour les atteindre. + +Il renvoie en outre à d'autres stratégies pertinentes du secteur public en matière d'open source. + +=== Contexte + +En 2005, l'Unité de pilotage informatique de la Confédération (USIC) a publié la première version d'une stratégie OSS pour l'administration fédérale. Le principe le plus important défini à l'époque était l'égalité de traitement entre les OSS et les logiciels propriétaires lors des acquisitions. + +Depuis cette publication de 2005, la diffusion des logiciels open source n'a cessé de croître. Aujourd'hui, selon le rapport « Étude Open Source Suisse 2024 », une nette majorité des entreprises et des autorités utilisent des logiciels open source dans de très nombreux domaines. Dans le secteur du logiciel, très peu d'entreprises ne travaillent pas avec des outils et des composants open source. + +Le 1er février 2019, les présentes Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale ainsi que le guide pratique sont entrés en vigueur en version 1.0. Avec l'adoption de la LMETA et les nouvelles obligations découlant de son article 9, il est devenu nécessaire d'actualiser ces deux documents et de créer des outils supplémentaires pour les autorités fédérales. + +=== Procédure + +La mise en œuvre de la LMETA incombe aux offices fédéraux eux-mêmes. Compte tenu de l'importance croissante de l'open source, il a toutefois été décidé de réviser le guide pratique _link:em002-1.pdf[Em002-1]_ en concertation avec toutes les parties prenantes. Des outils supplémentaires pour la mise en œuvre de la LMETA ont en outre été ajoutés. + +Le guide pratique définit les notions nécessaires, expose les constellations d'utilisation des logiciels open source, indique où et comment trouver des alternatives aux logiciels commerciaux existants, comment acquérir de l'open source, quels modèles d'affaires existent pour l'open source et quels modèles de support sont possibles lors de son utilisation. Les autres outils répondent aux questions fréquentes et donnent des indications sur la publication de logiciels open source conformément à la LMETA. Ils traitent de toutes les questions relatives aux licences OSS et montrent comment constituer une communauté autour d'un logiciel. Plusieurs listes de contrôle destinées à l'orientation et à la documentation sont également mises à la disposition des autorités fédérales. + +Les documents relatifs aux acquisitions ont eux aussi été adaptés, et un aide-mémoire supplémentaire [KBB-MB], des directives [BBL-WL] et une liste de contrôle [BBL-CL] ont été élaborés. + +Les incertitudes existantes sont levées dans toute la mesure du possible par les présentes lignes directrices stratégiques, le guide pratique qui les accompagne et les recommandations d'action, ainsi que par les outils supplémentaires. + +== Lien avec d'autres stratégies + +Les présentes Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale sont alignées sur quatre stratégies actuelles du secteur public et sur la LMETA.footnote:[RS 172.019 : https://www.fedlex.admin.ch/eli/cc/2023/682/fr] Celles-ci comportent un lien direct ou indirect avec le thème des logiciels open source et de la collaboration informatique entre institutions publiques : + +La *Stratégie Administration fédérale numérique* [SB001] fixe huit principes et quatre priorités. En utilisant des logiciels open source, l'administration fédérale contribue à la priorité 4, « Renforcer la souveraineté numérique ». Une solution open source peut être réutilisée un nombre illimité de fois et adaptée aux besoins propres de l'administration fédérale grâce à son code source ouvert. + +L'idée de durabilité numérique et de souveraineté numérique se retrouve également dans la **Stratégie Administration numérique suisse 2024–2027**footnote:[Stratégie Administration numérique suisse 2024–2027 : https://www.digital-public-services-switzerland.ch/strategy]. La Confédération et les cantons créent des conditions-cadres appropriées pour cette utilisation multiple. Les modules de base destinés au développement de la cyberadministration sont « réalisés une fois et utilisés en commun ». Le choix de logiciels open source facilite la réutilisation des solutions informatiques. + +Selon la **Stratégie Suisse numérique**footnote:[https://digital.swiss/fr/], il est déterminant pour le succès de la Suisse dans l'espace numérique de renforcer la mise en réseau des niveaux fédéraux. Une attention particulière doit donc être portée à la coordination entre la Confédération, les cantons et les communes ainsi qu'à la coopération entre les organisations actives dans le domaine de la numérisation dans toute la Suisse. Le Conseil fédéral a en outre accordé une importance particulière à la souveraineté numérique de la Suisse en tant que thème prioritaire pour 2023.footnote:[https://digital.swiss/fr/strategie/themes-prioritaires/souverainete-numerique] + +Dans la **Stratégie Open Government Data Suisse (2019–2023)**footnote:[Stratégie Open Government Data 2019 – 2023], le Conseil fédéral retient que les données de l'administration fédérale qui ne sont ni personnelles ni critiques pour la sécurité doivent être publiées selon le principe Open by Default. L'administration fédérale a lancé à cet effet le portail opendata.swiss.footnote:[https://opendata.swiss/fr] Des offices fédéraux, des cantons, des villes et d'autres organisations publiques y ont actuellement publié plus de 11 700 jeux de données. + +Le plan directeur Open Government Data 2024–2027footnote:[https://www.bfs.admin.ch/asset/fr/28425806] met en œuvre le principe Open by Default. + +== Gouvernance et outils + +Lorsqu'il est question de logiciels open source, il convient de distinguer entre *consuming* (utiliser), *contributing* (contribuer à du code existant) et *creating* (c'est-à-dire de nouveaux projets). + +image::./assets/four-cs/four-cs.fr.svg[Les 4 C dans le contexte de l'OSS] + +Figure 1 : Les 4 C dans le contexte de l'OSS + +La *collaboration* est en outre toujours envisageable en arrière-plan. Dans le cas du creating, elle doit être initiée par l'administration fédérale ; dans celui du contributing, elle existe déjà ; et dans celui du consuming, elle peut également être utile (p. ex. groupe d'utilisateurs). + +Lors du *consuming* de logiciels open source, ceux-ci doivent être traités et évalués à égalité avec les logiciels propriétaires. + +Lors du *développement* de logiciels, la publication en open source est en principe obligatoire, sous réserve des exceptions prévues à l'art. 9 LMETA (droits de tiers et motifs relevant de la sécurité). + +Ces exceptions sont traitées dans link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS]. + +Les autorités fédérales, c'est-à-dire les unités administratives de l'administration fédérale, sont elles-mêmes responsables du respect correct de ces règles ; il n'existe aucune compétence centralisée. + +La *publication* apporte une plus-value en particulier lorsqu'une *communauté* de personnes intéressées se forme et travaille en commun sur le logiciel. Si la communauté collabore à un projet et que l'administration fédérale admet ces contributions, il en résulte des bénéfices économiques et des effets de synergie.footnote:[https://test.bitkom.org/sites/main/files/2023-03/BitkomLeitfadenOpenSourceSoftware31.pdf, chapitre 4 (en allemand)] + +Dans la pratique, la publication ne porte souvent pas seulement sur le code source, mais aussi sur tous les autres aspects (documentation, gouvernance, instructions de compilation, etc.). + +En principe, l'administration fédérale n'a aucune obligation de constituer des communautés ; le mandat légal exige uniquement la publication du code source. L'administration fédérale devrait investir en priorité dans les communautés là où le bénéfice pour la Confédération et pour des tiers est important et où la charge est la plus faible possible. + +Il n'existe actuellement aucune plateforme fédérale commune pour le *développement et la publication de code source*. Chaque autorité doit donc choisir elle-même une plateforme (dépôt) pour la publication. Le guide pratique figurant dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source] et les listes de contrôle correspondantes définissent comment travailler avec une plateforme et quelles caractéristiques celle-ci doit présenter. + +Le *choix de la licence* est traité dans le link:em002-3.pdf[Em002-3 Guide de licences OSS]), qui présente une sélection de licences standard et explique leurs usages. L'administration fédérale ne devrait utiliser ses propres textes de licence que dans des cas justifiés, conformément à l'art. 9, al. 4, LMETA. + +Lors de l'utilisation et du développement d'OSS, le **support**footnote:[Au moins pendant le cycle de vie, au moyen de contrats ou d'une communauté.] doit toujours être réglé (même s'il y est renoncé). L'unité administrative compétente règle ce point dans le processus de publication ou lors de la définition de la communauté. La LMETA ne prévoit rien à ce sujet, et aucun financement ni personnel supplémentaire ne sera mis à disposition pour le support. Il peut être judicieux d'inclure le support et le développement commun là où le bénéfice pour les autorités suisses ou l'économie suisse est jugé suffisamment important (coûts d'écosystème) et/ou lorsqu'un partage des coûts ou une coopération est recherché. Si le fournisseur s'en charge, ses coûts de support peuvent être supportés par les utilisateurs. + +L'*acquisition d'OSS* s'effectue via le processus d'acquisition ordinaire de l'administration fédérale. L'OFCL met à disposition les documents et outils correspondants. + +Un _aide-mémoire sur l'acquisition de logiciels et l'art. 9 LMETA_ est en outre disponiblefootnote:[Disponible ici (en allemand) : https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html et https://perimap.admin.ch/goto_perimap_file_46835_download.html] _[KBB-MB]_ (voir figure 2). + +Des considérations juridiques et pratiques font que l'obligation de publier en OSS peut, dans certaines circonstances, être transférée à un fournisseur (lors de l'appel d'offres ou en exploitation). Les outils d'acquisition et le processus de publication déterminent comment aborder ce point avec le fournisseur. Cela est réalisé pour l'essentiel en complétant les processus, les projets de contrat et les outils existants. + +La procédure organisationnelle est réglée dans link:em002-2.pdf[Em002-2 Instructions pour la publication de logiciels open source] et dans les outils correspondants. + +*Du point de vue du droit des marchés publics, les OSS sont traités à égalité avec les logiciels propriétaires.* Comme aucune redevance de licence n'est due pour les OSS selon la définition de l'Open Source Initiative (OSI), un logiciel peut en principe être téléchargé et utilisé sans appel d'offres. Seules les prestations à fournir par des entreprises (p. ex. support, ingénierie) sont alors soumises au droit des marchés publics et doivent faire l'objet d'un appel d'offres. + +Là où c'est nécessaire, les aspects pertinents des outils sont intégrés dans les processus de gestion de projet de la Confédération (c'est-à-dire HERMES). + +L'open development (développement ouvert directement sur un dépôt librement accessible) et la participation à des projets existants (contribution) sont également traités dans les explications figurant dans link:em002-4.pdf[Em002-4 Guide des communautés OSS]. + +=== Vue d'ensemble des documents OSS + +Le schéma suivant donne une vue d'ensemble des documents pertinents pour l'OSS au sein de l'administration fédérale. + +include::partials/document-map.fr.adoc[] + +Figure 2 : Documents en lien avec l'art. 9 LMETA + +== Objectifs + +Les objectifs transversaux et à long terme suivants montrent comment l'administration fédérale exploite le potentiel des logiciels open source et répond aux risques et aux défis : + +A) Respect des exigences légales (c'est-à-dire de la LMETA):: La publication de logiciels open source est régie par l'article 9 LMETA. Le respect de cette exigence légale est un aspect central des présentes lignes directrices et des documents qui s'y rapportent. Les autorités fédérales doivent respecter cet article et maximiser le bénéfice pour l'administration fédérale et pour la Suisse. La mise en œuvre incombe aux unités d'organisation elles-mêmes. + +B) Accroître l'innovation et l'efficience:: Les logiciels open source constituent aujourd'hui le socle de l'informatique moderne. En s'appuyant sur les millions de composants et de solutions librement disponibles, des applications autonomes peuvent être développées et exploitées rapidement. Les économies de temps et de ressources qui en découlent, ainsi que les principes d'architecture associés aux logiciels open source tels que l'interopérabilité, l'agilité et les microservices, accroissent la capacité d'innovation et l'efficience du développement logiciel. Cela accélère à son tour la numérisation de l'administration fédérale. La publication de logiciels open source permet d'accélérer l'adoption de solutions numériques dans l'environnement fédéral et d'exploiter des effets de synergie. + +C) Promouvoir une culture de la collaboration:: Les logiciels open source favorisent une culture de la collaboration en informatique grâce au partage du code source, à une communication ouverte et à des pratiques de développement commun. Ces principes peuvent être appliqués pour renforcer la collaboration informatique au sein de l'administration fédérale, avec les cantons et avec d'autres institutions publiques. Cela renforce la souveraineté numérique et réduit les dépendances vis-à-vis des fournisseurs de logiciels. + +D) Créer de la clarté et minimiser les risques:: Les informations sur les licences open source fréquemment utilisées doivent permettre à l'administration fédérale de choisir les bonnes licences. Cela minimise les risques juridiques. Des recommandations techniques et juridiques permettent à l'administration fédérale d'utiliser et de publier des logiciels open source. + +E) Créer une vue d'ensemble pour exploiter les synergies:: Les logiciels open source sont actuellement utilisés de diverses manières à de nombreux endroits au sein de l'administration fédérale. Beaucoup de savoir et d'expérience sont disponibles, mais les synergies ne peuvent pas encore être exploitées faute d'une vue d'ensemble des solutions open source utilisées. Une telle vue d'ensemble et l'acquisition commune de prestations permettront de mieux exploiter le potentiel des logiciels open source, ce qui économise des ressources et crée des synergies. + +F) Accroître l'attractivité en tant qu'employeur informatique:: Les logiciels open source sont appréciés par de nombreux spécialistes informatiques hautement qualifiés. L'utilisation de technologies open source modernes et l'application de méthodes de développement open source motivent de nombreux collaborateurs et accroissent l'attractivité de l'administration fédérale en tant qu'employeur. Pour utiliser des logiciels open source, la Confédération a besoin de spécialistes disposant de connaissances et d'expérience dans ce domaine ; il convient donc, lors du recrutement de spécialistes, de veiller à développer le savoir-faire interne en matière d'open source. + +== Mesures + +Les mesures suivantes doivent contribuer à atteindre les objectifs exposés ci-dessus. Elles seront complétées ou remplacées en temps voulu et adaptées à l'évolution des circonstances. + +La liste suivante illustre les liens entre les objectifs et les mesures correspondantes. Celles-ci soutiennent la mise en œuvre des objectifs concernés, mais peuvent aussi avoir un effet sur d'autres objectifs. + +A) Respect des exigences légales (LMETA):: +1) Mettre en œuvre le _Guide pratique pour les logiciels open source dans l'administration fédérale link:em002-1.pdf[Em002-1]_ + +2) Mettre en œuvre les _Instructions pour la publication de logiciels open source link:em002-2.pdf[Em002-2]_ et les outils qui en découlent. + +3) Les services d'achat développent un savoir-faire en matière d'open source et soutiennent ainsi l'administration fédérale. + +B) Accroître l'innovation et l'efficience:: +1) Mettre en œuvre le _Guide pratique pour les logiciels open source dans l'administration fédérale link:em002-1.pdf[Em002-1]_ + +3) Les services d'achat savent gérer l'open source et soutenir de manière optimale l'art. 9 LMETA. + +8) Promouvoir la constitution de communautés + +C) Promouvoir une culture de la collaboration:: +1) Mettre en œuvre le _Guide pratique pour les logiciels open source dans l'administration fédérale link:em002-1.pdf[Em002-1]_ + +4) Promouvoir l'échange de savoir et d'expérience + +8) Promouvoir la constitution de communautés + +9) Examiner la possibilité d'une plateforme de publication propre ; promouvoir l'open development + +D) Créer de la clarté et minimiser les risques:: +1) Mettre en œuvre le _Guide pratique pour les logiciels open source dans l'administration fédérale link:em002-1.pdf[Em002-1]_ + +2) Mettre en œuvre les _Instructions pour la publication de logiciels open source link:em002-2.pdf[Em002-2]_ et les outils qui en découlent. + +E) Créer une vue d'ensemble pour exploiter les synergies:: +6) Mettre en œuvre l'acquisition commune de prestations + +7) Créer une vue d'ensemble des logiciels open source utilisés, publiés et codéveloppés + +8) Promouvoir la constitution de communautés + +F) Accroître l'attractivité en tant qu'employeur informatique:: +5) Promouvoir et communiquer une culture open source + +8) Promouvoir la constitution de communautés + +=== Description des mesures + +Mesure 1 : Mettre en œuvre le _Guide pratique pour les logiciels open source dans l'administration fédérale link:em002-1.pdf[Em002-1]_.:: +Bien que la notion de logiciel open source ait déjà plus de 20 ans, la diffusion constante de ces logiciels et l'évolution continue des scénarios d'application donnent sans cesse lieu à de nouvelles pratiques et questions. Les nouveaux développements et les développements ultérieurs de solutions open source constituent en outre de plus en plus souvent des alternatives à part entière aux logiciels propriétaires. Avec la LMETA s'ajoute l'obligation de publier les développements réalisés en interne. ++ +Le _Guide pratique pour les logiciels open source dans l'administration fédérale_ donne une vue d'ensemble et une introduction au sujet, expose les avantages et les inconvénients des logiciels open source et explique tous les autres outils. Il contient également des bonnes pratiques, des alternatives éprouvées et des recommandations pratiques sur la manière dont l'administration fédérale doit gérer les logiciels open source. ++ +Ce guide pratique et les autres outils doivent être utilisés et mis en œuvre par les autorités fédérales dans leur gestion des logiciels open source et des publications. ++ +En guise de brève introduction au sujet, un _aide-mémoire sur l'application de l'art. 9 LMETA_ et la link:em002-6.pdf[Em002-6 FAQ sur la publication d'OSS (FAQ-OSS)] sont disponibles. + +Mesure 2 : Mettre en œuvre les Instructions pour la publication de logiciels open source link:em002-2.pdf[Em002-2] et les outils qui en découlent.:: +L'utilisation efficiente des OSS dans le développement logiciel requiert souvent des contributions sous forme de corrections d'erreurs et d'extensions fonctionnelles. Avec la LMETA s'ajoute une obligation de publier les logiciels créés en propre. Les orientations nécessaires sont fournies par différents outils. ++ +Les listes de contrôle font partie des instructions pour la publication d'OSS. Elles doivent être utilisées en complément des directives correspondantes des unités administratives, avant et pendant le développement. ++ +Le traitement du code existant au sens de l'art. 9 LMETA est également abordé. L'objectif est de trouver et de mettre en œuvre des solutions pragmatiques. ++ +Les licences revêtent une importance particulière dans l'environnement OSS. Lors de la publication, de l'acquisition et de l'utilisation de logiciels, les licences doivent être alignées sur ce qui est juridiquement réalisable et sur l'effet recherché. Les connaissances nécessaires et les décisions correspondantes doivent être documentées. Dans ce contexte, les documents complémentaires nécessaires, tels que le Contributor Licence Agreement (CLA), sont également mis à disposition. ++ +Afin de faciliter l'application de l'art. 9 LMETA, des compléments seront apportés à la méthode de gestion de projet de la Confédération (HERMES). Les unités administratives doivent trouver les outils nécessaires dans le processus ordinaire. + +Mesure 3 : Les services d'achat développent un savoir-faire en matière d'open source et soutiennent ainsi l'administration fédérale.:: +Le nouveau document link:em002-7.pdf[Em002-7 Aspects stratégiques des achats et OSS] a été créé pour traiter les aspects liés aux acquisitions. ++ +Afin de garantir une large concurrence, les acquisitions exigent que les logiciels open source et propriétaires soient traités à égalité. Les exigences accrues liées à l'art. 9 LMETA concernant les moyens à acquérir pour la publication de logiciels doivent être prises en compte. ++ +Le Centre de compétence des marchés publics de la Confédération (CCMP) a publié un aide-mémoire sur l'acquisition de logiciels et l'art. 9 LMETA [KBB-MB] sous le lien suivant : link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html]. ++ +Une aide supplémentaire est disponible sur l'intranet de l'OFCL (accessible uniquement depuis le réseau fédéral) avec les link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[directives Open Source dans les acquisitions] [BBL-WL] et la 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[liste de contrôle pour l'exception forfaitaire selon l'art. 9 LMETA] [BBL-CL]. + +Mesure 4 : Promouvoir l'échange de savoir et d'expérience:: +La création et l'utilisation de logiciels open source requièrent un savoir-faire approfondi et spécialisé. Parallèlement, les solutions open source évoluent constamment et de nouveaux projets open source sont lancés. Il est donc difficile de conserver une vue d'ensemble complète des tendances et technologies actuelles. ++ +Afin de promouvoir l'utilisation professionnelle de l'open source et de faciliter l'échange de savoir et d'expérience, les informations doivent être partagées au sein d'une communauté d'intérêts élargie et les collaborateurs de l'administration fédérale doivent être soutenus avec compétence. + +Mesure 5 : Promouvoir et communiquer une culture open source:: +La numérisation croissante a encore aggravé la pénurie de personnel qualifié en informatique. Cela complique également le recrutement de personnel informatique qualifié pour les prestataires de l'administration fédérale. L'utilisation de logiciels open source et la culture de développement qui y est associée constituent, comme on le sait, un argument incitant les spécialistes à postuler à de tels postes. ++ +Pour être perçue par le public comme un employeur « favorable à l'open source », l'administration devrait communiquer activement sur les différentes mesures et sur les solutions open source utilisées, sous la forme d'un radar technologique.footnote:[Les radars technologiques doivent être utilisés aussi largement que possible, c'est-à-dire si possible au niveau des autorités fédérales, voire de l'administration fédérale.] Pour l'attractivité de l'employeur, il est en outre important de permettre aux employés de la Confédération de contribuer à des logiciels open source existants. + +Mesure 6 : Mettre en œuvre l'acquisition commune de prestations:: +La maintenance et le support des logiciels open source sont actuellement assurés par des collaborateurs internes de l'administration fédérale, tandis que des fournisseurs externes proposent des prestations pour certaines solutions open source. Ces prestations sont souvent acquises de manière autonome par les offices concernés, ce qui peut entraîner des doublons et les pertes financières qui en découlent. ++ +L'acquisition commune de prestations pour les logiciels open source doit accroître la fiabilité de la maintenance et du support en exploitation et simplifier l'utilisation de solutions open source. Sur la base du radar technologique (voir mesure 5), des prestations pour les systèmes et technologies open source les plus répandus doivent être acquises de manière centralisée. Ces prestations peuvent ensuite être obtenues par tous les offices selon leurs besoins.footnote:[Cela concerne le support du logiciel utilisé. Un support par des tiers pour des logiciels publiés selon la LMETA est possible et peut être facturé. Ce point est traité dans link:em002-4.pdf[Em002-4 Guide des communautés OSS].] + +Mesure 7 : Créer une vue d'ensemble des logiciels open source utilisés, publiés et codéveloppés.:: +Comme il n'est pas nécessaire d'acheter des licences lors de l'utilisation de logiciels open source, le processus d'acquisition, souvent lourd, disparaît fréquemment. ++ +Il devient dès lors difficile de savoir où l'administration fédérale utilise quels logiciels open source. De ce fait, le potentiel des logiciels open source — comme l'exploitation des synergies, la formation de communautés pour l'échange d'expériences, etc. — ne peut pas être pleinement mis à profit. ++ +Un radar technologique au sein de l'administration fédérale doit donner une vue d'ensemble indiquant où quels logiciels open source sont utilisés et qui dispose de quel savoir-faire. + +Mesure 8 : Promouvoir la constitution de communautés:: +La constitution de communautés pour le développement de projets et la participation à celles-ci sont très importantes pour l'OSS. Il en résulte des synergies considérables. Il se peut que le projet existe déjà et que la Confédération y participe seulement, ou que la Confédération dirige le projet, ou encore qu'il s'agisse d'une collaboration. Renoncer à une communauté est également une décision importante. Le développement direct sur un dépôt ouvert (sans publication ultérieure) peut apporter des gains d'efficience supplémentaires et favoriser le développement commun. Em002-4 fournit des orientations et des arguments en faveur de la constitution de communautés par les autorités fédérales. + +Mesure 9 : Examiner la possibilité d'une plateforme de publication propre ; promouvoir l'open development:: +La mise en place et l'exploitation d'une plateforme de publication interne ou suisse seront examinées et réalisées une fois la décision correspondante prise. ++ +L'objectif d'une plateforme indépendante pour l'administration fédérale est de préserver la souveraineté numérique et l'indépendance. La collaboration s'en trouve simplifiée et, dans le même temps, une vue d'ensemble des activités est créée. ++ +Une coopération fédérale entre toutes les autorités de Suisse (à l'instar d'opencode.de) est à l'examen (p. ex. ANS ou eOperations Suisse). + +== Annexes + +=== Modifications par rapport à la version précédente + +* Modifications et améliorations rédactionnelles mineures. +* La fiche d'information Em002-5 a été remplacée par l'aide-mémoire Outils OSS. +* Le document «`link:em002-7.pdf[Em002-7 Acquisitions et OSS]`» a été ajouté. +* Nouveau schéma représentant les 4 C dans le contexte de l'OSS (ajout de « collaboration »). +* Nouvelles références à l'OFCL et au CCMP. + +=== Références relatives aux outils OSS + +La liste de référence suivante recense les documents relatifs au jeu de documents link:em002.pdf[Em002 Outils pour les logiciels open source] dans l'administration fédérale. + +NOTE: Les outils et en particulier les listes de contrôle s'appuient en partie sur les *documents OSS du canton de Berne*, publiés sous licence BSD3 (link:https://github.com/kanton-bern/oss[https://github.com/kanton-bern/oss]). + +Les documents Em002 actuels sont publiés sur la page Outils OSS de la Chancellerie fédérale. https://www.bk.admin.ch/bk/fr/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html. + +Les documents sont en outre publiés sur GitHub. Il est également possible d'y donner son avis. {url-repo} + +include::partials/references.fr.adoc[tags=ref-em002-tools] + +Vue d'ensemble visuelle des outils OSS : + +include::partials/document-map.fr.adoc[] + +Figure 3 : Documents en lien avec l'art. 9 LMETA + +=== Références générales + +Toutes les références relatives au jeu de documents Em002 figurent ici *dans Em002 Lignes directrices stratégiques [Em002*]. + +include::partials/references.fr.adoc[tags=ref-em002-general] + +=== Abréviations + +La présente liste d'abréviations contient toutes les abréviations utilisées dans le jeu de documents OSS Em002. Un glossaire figure dans link:em002-6.pdf[Em002-6 FAQ sur la publication d'OSS]. + +[horizontal] +include::partials/abbreviations.fr.adoc[tags=abbr-em002] +endif::[] + +ifeval::["{lang}" == "it"] +NOTE: 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 link:{url-repo}/tree/main[README] principale. + +''' + +== Introduzione + +=== Scopo e obiettivo + +Secondo l'articolo 9 capoverso 1 della legge federale del 17 marzo 2023footnote:[RS 172.019] sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA), le autorità devono pubblicare il codice sorgente del software che sviluppano o fanno sviluppare per adempiere i loro compiti, sempre che diritti di terzi o motivi rilevanti per la sicurezza non lo escludano o lo limitino. Viene così eliminata l'incertezza giuridica riguardo alla pubblicazione di software da parte delle autorità federali. + +Negli ultimi anni è emerso che l'importanza del software open source (OSS) nell'Amministrazione federale ha complessivamente continuato a crescere. + +Le presenti linee guida strategiche descrivono i fondamenti del software open source e il modo in cui esso viene trattato nell'Amministrazione federale. Il documento fissa sei obiettivi e propone nove misure per conseguirli. + +Rinvia inoltre ad altre strategie rilevanti dell'ente pubblico in materia di open source. + +=== Situazione iniziale + +Nel 2005 l'Organo direzione informatica della Confederazione (ODIC) ha pubblicato la prima versione di una strategia OSS per l'Amministrazione federale. Il principio più importante definito all'epoca era la parità di trattamento tra OSS e software proprietario negli acquisti. + +Dalla pubblicazione del 2005 la diffusione del software open source è costantemente aumentata. Oggi, secondo il rapporto «Studio Open Source Svizzera 2024», una netta maggioranza delle imprese e delle autorità utilizza software open source in moltissimi ambiti. Nel settore del software sono pochissime le imprese che non lavorano con strumenti e componenti open source. + +Il 1° febbraio 2019 le presenti Linee guida strategiche per il software open source nell'Amministrazione federale e la guida pratica sono entrate in vigore nella versione 1.0. Con l'adozione della LMeCA e i nuovi obblighi secondo l'articolo 9 si è reso necessario aggiornare entrambi i documenti e creare strumenti supplementari per le autorità federali. + +=== Procedura + +L'attuazione della LMeCA compete agli uffici federali stessi. Vista la crescente importanza dell'open source si è tuttavia deciso di rielaborare la guida pratica _link:em002-1.pdf[Em002-1]_ insieme a tutte le parti interessate. Sono inoltre stati aggiunti strumenti supplementari per l'attuazione della LMeCA. + +La guida pratica definisce i concetti necessari, illustra le costellazioni d'impiego del software open source, indica dove e come trovare alternative al software commerciale esistente, come acquistare open source, quali modelli di business esistono per l'open source e quali modelli di supporto sono possibili nel suo impiego. Gli altri strumenti rispondono alle domande frequenti e forniscono indicazioni sulla pubblicazione di software open source secondo la LMeCA. Trattano tutte le questioni relative alle licenze OSS e mostrano come costituire una community attorno a un software. Diverse liste di controllo per l'orientamento e la documentazione sono parimenti messe a disposizione delle autorità federali. + +Anche i documenti relativi agli acquisti sono stati adeguati e sono stati elaborati un promemoria supplementare [KBB-MB], direttive [BBL-WL] e una lista di controllo [BBL-CL]. + +Le incertezze esistenti vengono eliminate per quanto possibile con le presenti linee guida strategiche, la guida pratica che le accompagna e le raccomandazioni d'azione, nonché con gli strumenti supplementari. + +== Rapporto con altre strategie + +Le presenti Linee guida strategiche per il software open source nell'Amministrazione federale sono allineate a quattro attuali strategie dell'ente pubblico e alla LMeCA.footnote:[RS 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/it] Esse contengono un riferimento diretto o indiretto al tema del software open source e della collaborazione informatica tra istituzioni pubbliche: + +La *Strategia Amministrazione federale digitale* [SB001] fissa otto principi e quattro priorità. Impiegando software open source l'Amministrazione federale contribuisce alla priorità 4 «Rafforzare la sovranità digitale». Una soluzione open source può essere riutilizzata un numero illimitato di volte e adattata alle esigenze specifiche dell'Amministrazione federale grazie al suo codice sorgente aperto. + +L'idea di sostenibilità digitale e di sovranità digitale emerge anche nella **Strategia Amministrazione digitale Svizzera 2024–2027**footnote:[Strategia Amministrazione digitale Svizzera 2024–2027: https://www.digital-public-services-switzerland.ch/strategy]. La Confederazione e i Cantoni creano condizioni quadro adeguate per questo utilizzo multiplo. I moduli di base per lo sviluppo del governo elettronico vengono «realizzati una volta e utilizzati in comune». La scelta di software open source facilita il riutilizzo delle soluzioni informatiche. + +Secondo la **Strategia Svizzera digitale**footnote:[https://digital.swiss/it/] è determinante per il successo della Svizzera nello spazio digitale rafforzare l'interconnessione dei livelli federali. Occorre pertanto prestare particolare attenzione al coordinamento tra Confederazione, Cantoni e Comuni nonché alla cooperazione tra le organizzazioni attive nel settore della digitalizzazione in tutta la Svizzera. Il Consiglio federale ha inoltre attribuito particolare importanza alla sovranità digitale della Svizzera quale tema prioritario per il 2023.footnote:[https://digital.swiss/it/strategia/temi-prioritari/sovranita-digitale] + +Nella **Strategia Open Government Data Svizzera (2019–2023)**footnote:[Strategia Open Government Data 2019 – 2023] il Consiglio federale stabilisce che i dati dell'Amministrazione federale non personali e non critici per la sicurezza devono essere pubblicati secondo il principio Open by Default. A tal fine l'Amministrazione federale ha lanciato il portale opendata.swiss.footnote:[https://opendata.swiss/it] Uffici federali, Cantoni, città e altre organizzazioni pubbliche vi hanno attualmente pubblicato oltre 11 700 set di dati. + +Il piano direttore Open Government Data 2024–2027footnote:[https://www.bfs.admin.ch/asset/it/28425806] attua il principio Open by Default. + +== Governance e strumenti + +Quando si parla di software open source occorre distinguere tra *consuming* (utilizzare), *contributing* (contribuire a codice esistente) e *creating* (ossia nuovi progetti). + +image::./assets/four-cs/four-cs.it.svg[Le 4 C nel contesto dell'OSS] + +Figura 1: Le 4 C nel contesto dell'OSS + +La *collaboration* è inoltre sempre ipotizzabile sullo sfondo. Nel caso del creating deve essere avviata dall'Amministrazione federale, nel caso del contributing esiste già e nel caso del consuming può parimenti risultare utile (p. es. gruppo di utenti). + +Nel *consuming* di software open source questo va trattato e valutato alla pari del software proprietario. + +Nello *sviluppo* di software la pubblicazione open source è in linea di principio obbligatoria, fatte salve le eccezioni previste dall'art. 9 LMeCA (diritti di terzi e motivi rilevanti per la sicurezza). + +Tali eccezioni sono trattate in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS]. + +Le autorità federali, ossia le unità amministrative dell'Amministrazione federale, sono esse stesse responsabili del corretto rispetto di queste regole; non esiste una competenza centralizzata. + +La *pubblicazione* apporta un valore aggiunto soprattutto quando si forma una *community* di persone interessate che lavora congiuntamente al software. Se la community collabora a un progetto e l'Amministrazione federale ammette tali contributi, ne derivano benefici economici ed effetti di sinergia.footnote:[https://test.bitkom.org/sites/main/files/2023-03/BitkomLeitfadenOpenSourceSoftware31.pdf, capitolo 4 (in tedesco)] + +Nella pratica la pubblicazione comprende spesso non soltanto il codice sorgente, ma anche tutti gli altri aspetti (documentazione, governance, istruzioni di build ecc.). + +In linea di principio l'Amministrazione federale non ha alcun obbligo di costituire community; il mandato legale richiede unicamente la pubblicazione del codice sorgente. L'Amministrazione federale dovrebbe investire prioritariamente nelle community laddove il beneficio per la Confederazione e per i terzi è elevato e l'onere è il più contenuto possibile. + +Attualmente non esiste una piattaforma comune della Confederazione per lo *sviluppo e la pubblicazione di codice sorgente*. Ogni autorità deve quindi scegliere autonomamente una piattaforma (repository) per la pubblicazione. La guida pratica contenuta in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source] e le relative liste di controllo stabiliscono come lavorare con una piattaforma e quali caratteristiche essa deve soddisfare. + +La *scelta della licenza* è trattata nella link:em002-3.pdf[Em002-3 Guida alle licenze OSS]), che presenta una selezione di licenze standard e ne illustra gli impieghi. L'Amministrazione federale dovrebbe utilizzare testi di licenza propri soltanto in casi motivati, conformemente all'art. 9 cpv. 4 LMeCA. + +Nell'impiego e nello sviluppo di OSS il **supporto**footnote:[Almeno durante il ciclo di vita, mediante contratti o una community.] va sempre disciplinato (anche se vi si rinuncia). L'unità amministrativa competente lo disciplina nel processo di pubblicazione o in sede di definizione della community. La LMeCA non prevede nulla al riguardo e non saranno messi a disposizione mezzi finanziari o risorse di personale supplementari per il supporto. Può essere opportuno includere il supporto e lo sviluppo congiunto laddove il beneficio per le autorità svizzere o per l'economia svizzera è ritenuto sufficientemente elevato (costi dell'ecosistema) e/o si mira a una ripartizione dei costi o a una cooperazione. Se se ne fa carico il fornitore, i suoi costi di supporto possono essere sostenuti dagli utenti. + +L'*acquisto di OSS* avviene tramite il normale processo d'acquisto dell'Amministrazione federale. L'UFCL mette a disposizione i relativi documenti e strumenti. + +È inoltre disponibile un _promemoria sull'acquisto di software e l'art. 9 LMeCA_footnote:[Disponibile qui (in tedesco): https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html e https://perimap.admin.ch/goto_perimap_file_46835_download.html] _[KBB-MB]_ (cfr. figura 2). + +Considerazioni giuridiche e pratiche fanno sì che l'obbligo di pubblicazione OSS possa in determinate circostanze essere trasferito a un fornitore (in sede di gara o durante l'esercizio). Gli strumenti d'acquisto e il processo di pubblicazione stabiliscono come affrontare la questione con il fornitore. Ciò avviene in gran parte integrando i processi, le bozze di contratto e gli strumenti esistenti. + +La procedura organizzativa è disciplinata in link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di software open source] e nei relativi strumenti. + +*Dal profilo del diritto degli acquisti pubblici l'OSS è trattato alla pari del software proprietario.* Poiché per l'OSS, secondo la definizione dell'Open Source Initiative (OSI), non sono dovute tasse di licenza, il software può in linea di principio essere scaricato e utilizzato senza gara pubblica. Soltanto le prestazioni che devono essere fornite da imprese (p. es. supporto, engineering) sottostanno quindi al diritto degli acquisti pubblici e devono essere messe a concorso. + +Ove necessario, gli aspetti rilevanti degli strumenti sono integrati nei processi di gestione dei progetti della Confederazione (ossia HERMES). + +L'open development (sviluppo aperto direttamente su un repository liberamente accessibile) e la partecipazione a progetti esistenti (contribution) sono parimenti trattati nelle spiegazioni contenute in link:em002-4.pdf[Em002-4 Guida alle community OSS]. + +=== Panoramica dei documenti OSS + +Il grafico seguente offre una panoramica dei documenti rilevanti per l'OSS nell'Amministrazione federale. + +include::partials/document-map.it.adoc[] + +Figura 2: Documenti in relazione all'art. 9 LMeCA + +== Obiettivi + +I seguenti obiettivi generali e a lungo termine mostrano come l'Amministrazione federale sfrutta il potenziale del software open source e affronta i rischi e le sfide: + +A) Rispetto delle prescrizioni legali (ossia della LMeCA):: La pubblicazione di software open source è retta dall'articolo 9 LMeCA. Il rispetto di questa prescrizione legale è un aspetto centrale delle presenti linee guida e dei documenti correlati. Le autorità federali devono rispettare tale articolo e massimizzare il beneficio per l'Amministrazione federale e per la Svizzera. L'attuazione compete alle unità organizzative stesse. + +B) Accrescere innovazione ed efficienza:: Il software open source costituisce oggi la base dell'informatica moderna. Sulla scorta dei milioni di componenti e soluzioni liberamente disponibili è possibile sviluppare ed esercire rapidamente applicazioni autonome. I conseguenti risparmi di tempo e risorse nonché i principi architetturali associati al software open source, quali interoperabilità, agilità e microservizi, accrescono la capacità innovativa e l'efficienza dello sviluppo software. Ciò accelera a sua volta la digitalizzazione dell'Amministrazione federale. Mediante la pubblicazione di software open source è possibile accelerare l'adozione di soluzioni digitali in ambito federale e sfruttare effetti di sinergia. + +C) Promuovere una cultura della collaborazione:: Il software open source promuove, attraverso la condivisione del codice sorgente, la comunicazione aperta e le pratiche di sviluppo congiunto, una cultura della collaborazione in ambito informatico. Questi principi possono essere applicati per rafforzare la collaborazione informatica all'interno dell'Amministrazione federale, con i Cantoni e con altre istituzioni pubbliche. Ciò rafforza la sovranità digitale e riduce le dipendenze dai fornitori di software. + +D) Creare chiarezza e ridurre al minimo i rischi:: Le informazioni sulle licenze open source di uso frequente devono consentire all'Amministrazione federale di scegliere le licenze giuste. Ciò riduce al minimo i rischi giuridici. Raccomandazioni tecniche e giuridiche mettono l'Amministrazione federale in condizione di utilizzare e pubblicare software open source. + +E) Creare una panoramica per sfruttare le sinergie:: Il software open source è attualmente impiegato in numerosi punti dell'Amministrazione federale in modi diversi. Vi sono molte conoscenze ed esperienze, ma le sinergie non possono ancora essere sfruttate poiché manca una panoramica delle soluzioni open source impiegate. Una simile panoramica e l'acquisto congiunto di prestazioni consentiranno di sfruttare meglio il potenziale del software open source, il che permette di risparmiare risorse e crea sinergie. + +F) Accrescere l'attrattiva quale datore di lavoro nel settore informatico:: Il software open source è apprezzato da molti specialisti informatici altamente qualificati. L'impiego di moderne tecnologie open source e l'applicazione di metodi di sviluppo open source motivano molti collaboratori e accrescono l'attrattiva dell'Amministrazione federale quale datore di lavoro. Per impiegare software open source la Confederazione necessita di specialisti con conoscenze ed esperienza in materia; nel reclutamento di specialisti occorre pertanto adoperarsi per ampliare il know-how interno in materia di open source. + +== Misure + +Le misure seguenti devono contribuire al conseguimento degli obiettivi sopra esposti. Saranno completate o sostituite a tempo debito e adeguate al mutare delle circostanze. + +L'elenco seguente illustra come gli obiettivi sono collegati alle misure corrispondenti. Queste sostengono l'attuazione dei rispettivi obiettivi, ma possono ripercuotersi anche su altri obiettivi. + +A) Rispetto delle prescrizioni legali (LMeCA):: +1) Attuare la _Guida pratica per il software open source nell'Amministrazione federale link:em002-1.pdf[Em002-1]_ + +2) Attuare le _Istruzioni per la pubblicazione di software open source link:em002-2.pdf[Em002-2]_ e gli strumenti che ne derivano. + +3) I servizi d'acquisto sviluppano know-how in materia di open source sostenendo così l'Amministrazione federale. + +B) Accrescere innovazione ed efficienza:: +1) Attuare la _Guida pratica per il software open source nell'Amministrazione federale link:em002-1.pdf[Em002-1]_ + +3) I servizi d'acquisto sanno gestire l'open source e sostenere in modo ottimale l'art. 9 LMeCA. + +8) Promuovere la costituzione di community + +C) Promuovere una cultura della collaborazione:: +1) Attuare la _Guida pratica per il software open source nell'Amministrazione federale link:em002-1.pdf[Em002-1]_ + +4) Promuovere lo scambio di conoscenze ed esperienze + +8) Promuovere la costituzione di community + +9) Esaminare la possibilità di una piattaforma di pubblicazione propria; promuovere l'open development + +D) Creare chiarezza e ridurre al minimo i rischi:: +1) Attuare la _Guida pratica per il software open source nell'Amministrazione federale link:em002-1.pdf[Em002-1]_ + +2) Attuare le _Istruzioni per la pubblicazione di software open source link:em002-2.pdf[Em002-2]_ e gli strumenti che ne derivano. + +E) Creare una panoramica per sfruttare le sinergie:: +6) Attuare l'acquisto congiunto di prestazioni + +7) Creare una panoramica del software open source impiegato, pubblicato e cosviluppato + +8) Promuovere la costituzione di community + +F) Accrescere l'attrattiva quale datore di lavoro nel settore informatico:: +5) Promuovere e comunicare una cultura open source + +8) Promuovere la costituzione di community + +=== Descrizione delle misure + +Misura 1: Attuare la _Guida pratica per il software open source nell'Amministrazione federale link:em002-1.pdf[Em002-1]_.:: +Sebbene il termine software open source abbia già oltre 20 anni, la costante diffusione di tale software e la continua evoluzione degli scenari applicativi danno luogo di continuo a nuove pratiche e questioni. Gli sviluppi nuovi e ulteriori di soluzioni open source costituiscono inoltre sempre più spesso alternative a pieno titolo al software proprietario. Con la LMeCA si aggiunge l'obbligo di pubblicare gli sviluppi realizzati internamente. ++ +La _Guida pratica per il software open source nell'Amministrazione federale_ offre una panoramica e un'introduzione al tema, illustra i vantaggi e gli svantaggi del software open source e spiega tutti gli altri strumenti. Contiene inoltre best practice, alternative collaudate e raccomandazioni pratiche su come l'Amministrazione federale deve gestire il software open source. ++ +Questa guida pratica e gli altri strumenti devono essere utilizzati e attuati dalle autorità federali nella gestione del software open source e delle pubblicazioni. ++ +Quale breve introduzione al tema sono disponibili un _promemoria sull'applicazione dell'art. 9 LMeCA_ e le link:em002-6.pdf[Em002-6 FAQ sulla pubblicazione di OSS (FAQ-OSS)]. + +Misura 2: Attuare le Istruzioni per la pubblicazione di software open source link:em002-2.pdf[Em002-2] e gli strumenti che ne derivano.:: +L'impiego efficiente dell'OSS nello sviluppo software richiede spesso contributi sotto forma di correzioni di errori ed estensioni funzionali. Con la LMeCA sussiste inoltre l'obbligo di pubblicare il software creato in proprio. L'orientamento necessario è fornito da diversi strumenti. ++ +Le liste di controllo fanno parte delle istruzioni per la pubblicazione di OSS. Devono essere utilizzate a complemento delle corrispondenti direttive delle unità amministrative, prima e durante lo sviluppo. ++ +Viene trattata anche la gestione del codice preesistente secondo l'art. 9 LMeCA. L'obiettivo è trovare e attuare soluzioni pragmatiche. ++ +Le licenze rivestono particolare importanza nell'ambiente OSS. In sede di pubblicazione, acquisto e utilizzo di software le licenze devono essere allineate a quanto è giuridicamente fattibile e all'effetto desiderato. Le conoscenze necessarie e le relative decisioni devono essere documentate. In tale contesto sono messi a disposizione anche i documenti supplementari necessari, come il Contributor Licence Agreement (CLA). ++ +Per agevolare l'applicazione dell'art. 9 LMeCA saranno apportati complementi al metodo di gestione dei progetti della Confederazione (HERMES). Le unità amministrative devono trovare gli strumenti necessari nel processo ordinario. + +Misura 3: I servizi d'acquisto sviluppano know-how in materia di open source sostenendo così l'Amministrazione federale.:: +Per gli aspetti relativi agli acquisti è stato creato il nuovo documento link:em002-7.pdf[Em002-7 Aspetti strategici degli acquisti e OSS]. ++ +Per garantire un'ampia concorrenza gli acquisti esigono che il software open source e quello proprietario siano trattati alla pari. Occorre tenere conto delle maggiori esigenze connesse all'art. 9 LMeCA riguardo ai mezzi da acquistare per la pubblicazione del software. ++ +Il Centro di competenza per gli acquisti pubblici della Confederazione (CCAP) ha pubblicato un promemoria sull'acquisto di software e l'art. 9 LMeCA [KBB-MB] al seguente link: link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html]. ++ +Ulteriore sostegno è disponibile sull'intranet dell'UFCL (accessibile soltanto dalla rete federale) con le link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[direttive Open Source negli acquisti] [BBL-WL] e la 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[lista di controllo per l'eccezione forfettaria secondo l'art. 9 LMeCA] [BBL-CL]. + +Misura 4: Promuovere lo scambio di conoscenze ed esperienze:: +La creazione e l'utilizzo di software open source richiedono un know-how approfondito e specialistico. Al tempo stesso le soluzioni open source evolvono costantemente e vengono lanciati nuovi progetti open source. È pertanto una sfida mantenere una panoramica completa delle tendenze e delle tecnologie attuali. ++ +Per promuovere l'impiego professionale dell'open source e agevolare lo scambio di conoscenze ed esperienze, le informazioni devono essere condivise in seno a una comunità d'interessi allargata e i collaboratori dell'Amministrazione federale devono essere sostenuti con competenza. + +Misura 5: Promuovere e comunicare una cultura open source:: +La digitalizzazione crescente ha ulteriormente acuito la carenza di personale qualificato nel settore informatico. Ciò rende difficile anche ai fornitori di prestazioni dell'Amministrazione federale reclutare personale informatico qualificato. L'impiego di software open source e la cultura di sviluppo che vi è associata costituiscono, com'è noto, un argomento che induce gli specialisti a candidarsi a tali posti. ++ +Per essere percepita dal pubblico quale datore di lavoro «favorevole all'open source», l'Amministrazione dovrebbe comunicare attivamente le diverse misure e le soluzioni open source impiegate sotto forma di un radar tecnologico.footnote:[I radar tecnologici devono essere impiegati il più ampiamente possibile, ossia se possibile a livello delle autorità federali o addirittura dell'Amministrazione federale.] Per l'attrattiva del datore di lavoro è inoltre importante consentire agli impiegati federali di contribuire a software open source esistente. + +Misura 6: Attuare l'acquisto congiunto di prestazioni:: +La manutenzione e il supporto del software open source sono attualmente assicurati da collaboratori interni dell'Amministrazione federale, mentre fornitori esterni offrono prestazioni per determinate soluzioni open source. Tali prestazioni sono spesso acquistate autonomamente dai rispettivi uffici, il che può comportare doppioni e le conseguenti perdite finanziarie. ++ +L'acquisto congiunto di prestazioni per il software open source deve accrescere l'affidabilità della manutenzione e del supporto in esercizio e semplificare l'impiego di soluzioni open source. Sulla base del radar tecnologico (cfr. misura 5) le prestazioni per i sistemi e le tecnologie open source più diffusi devono essere acquistate in modo centralizzato. Tali prestazioni possono poi essere ottenute da tutti gli uffici secondo il fabbisogno.footnote:[Ciò riguarda il supporto del software impiegato. Il supporto da parte di terzi per software pubblicato secondo la LMeCA è possibile e può essere fatturato. Questo aspetto è trattato in link:em002-4.pdf[Em002-4 Guida alle community OSS].] + +Misura 7: Creare una panoramica del software open source impiegato, pubblicato e cosviluppato.:: +Poiché nell'impiego di software open source non occorre acquistare licenze, viene spesso meno il dispendioso processo d'acquisto. ++ +Ciò rende difficile tracciare dove l'Amministrazione federale impiega quale software open source. Di conseguenza il potenziale del software open source — come lo sfruttamento delle sinergie, la formazione di community per lo scambio di esperienze ecc. — non può essere pienamente valorizzato. ++ +Un radar tecnologico in seno all'Amministrazione federale deve fornire una panoramica di dove viene impiegato quale software open source e di chi dispone di quale know-how. + +Misura 8: Promuovere la costituzione di community:: +La costituzione di community per lo sviluppo di progetti e la partecipazione ad esse sono molto importanti per l'OSS. Ne derivano sinergie considerevoli. Può darsi che il progetto esista già e che la Confederazione vi partecipi soltanto, oppure che la Confederazione diriga il progetto, o ancora che si tratti di una collaborazione. Anche rinunciare a una community è una decisione importante. Lo sviluppo diretto su un repository aperto (senza pubblicazione successiva) può apportare ulteriori guadagni di efficienza e promuovere lo sviluppo congiunto. Em002-4 fornisce orientamento e motivazione per la costituzione di community da parte delle autorità federali. + +Misura 9: Esaminare la possibilità di una piattaforma di pubblicazione propria; promuovere l'open development:: +La creazione e la gestione di una piattaforma di pubblicazione interna o svizzera saranno esaminate e attuate una volta presa la relativa decisione. ++ +L'obiettivo di una piattaforma autonoma per l'Amministrazione federale è preservare la sovranità e l'indipendenza digitali. La collaborazione viene semplificata e al tempo stesso si crea una panoramica delle attività. ++ +È allo studio una cooperazione federale tra tutte le autorità della Svizzera (analogamente a opencode.de), p. es. ADS o eOperations Svizzera. + +== Allegati + +=== Modifiche rispetto alla versione precedente + +* Modifiche e miglioramenti redazionali minori. +* La scheda informativa Em002-5 è stata sostituita dal promemoria Strumenti OSS. +* È stato aggiunto il documento «`link:em002-7.pdf[Em002-7 Acquisti e OSS]`». +* Nuovo grafico raffigurante le 4 C nel contesto dell'OSS (aggiunta di «collaboration»). +* Nuovi rinvii a UFCL e CCAP. + +=== Riferimenti agli strumenti OSS + +L'elenco di riferimento seguente elenca i documenti relativi alla serie link:em002.pdf[Em002 Strumenti per il software open source] nell'Amministrazione federale. + +NOTE: Gli strumenti e in particolare le liste di controllo si basano in parte sui *documenti OSS del Cantone di Berna*, pubblicati sotto licenza BSD3 (link:https://github.com/kanton-bern/oss[https://github.com/kanton-bern/oss]). + +Gli attuali documenti Em002 sono pubblicati sulla pagina Strumenti OSS della Cancelleria federale. https://www.bk.admin.ch/bk/it/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html. + +I documenti sono inoltre pubblicati su GitHub, dove è possibile fornire riscontri. {url-repo} + +include::partials/references.it.adoc[tags=ref-em002-tools] + +Panoramica visiva degli strumenti OSS: + +include::partials/document-map.it.adoc[] + +Figura 3: Documenti in relazione all'art. 9 LMeCA + +=== Riferimenti generali + +Tutti i riferimenti alla serie di documenti Em002 si trovano qui *in Em002 Linee guida strategiche [Em002*]. + +include::partials/references.it.adoc[tags=ref-em002-general] + +=== Abbreviazioni + +Il presente elenco contiene tutte le abbreviazioni utilizzate nella serie di documenti OSS Em002. Un glossario figura in link:em002-6.pdf[Em002-6 FAQ sulla pubblicazione di OSS]. + +[horizontal] +include::partials/abbreviations.it.adoc[tags=abbr-em002] +endif::[] + +ifeval::["{lang}" == "rm"] +NOTE: 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 link:{url-repo}/tree/main[README] principal. + +''' + +== Introducziun + +=== Finamira e intent + +Tenor l'artitgel 9 alinea 1 da la lescha federala dals 17 da mars 2023footnote:[CS 172.019] davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG) ston las autoritads publitgar il code da funtauna dal software ch'ellas sviluppan u fan sviluppar per ademplir lur incumbensas, uschenavant che dretgs da terzas persunas u motivs relevants per la segirezza n'excludan u na restrenschan betg quai. Uschia croda davent l'inscuritad giuridica tar la publicaziun da software tras autoritads federalas. + +Ils ultims onns ha mussà che l'impurtanza dal software open source (OSS) en l'administraziun federala è cuntinuadamain creschida. + +Questas directivas strategicas descrivan las basas dal software open source e co ch'i vegn tractà cun quel en l'administraziun federala. Il document fixescha sis finamiras e propona nov mesiras per las cuntanscher. + +El renviescha ultra da quai ad ulteriuras strategias relevantas dal maun public en il sectur open source. + +=== Situaziun da partenza + +Il 2005 ha l'Organ da direcziun d'informatica da la Confederaziun (ISB) publitgà l'emprima versiun d'ina strategia OSS per l'administraziun federala. Sco il princip il pli impurtant è vegnida fixada lura la tractanda eguala da l'OSS cun il software closed source tar l'acquist. + +Dapi la publicaziun dal 2005 è la derasaziun dal software open source creschida cuntinuadamain. Oz utilisescha, tenor il rapport «Studi Open Source Svizra 2024», ina cler maioritad da las interpresas e da las autoritads software open source en fitg blers secturs differents. En la branscha dal software datti mo fitg paucas interpresas che na lavuran betg cun utensilis e cumponentas open source. + +Il 1. da favrer 2019 èn questas Directivas strategicas per software open source en l'administraziun federala sco er la guida pratica entradas en vigur en la versiun 1.0. Cun il relasch da l'EMBAG e las novas obligaziuns tenor l'artitgel 9 è vegnì necessari d'actualisar omadus documents e da crear meds supplementars per las autoritads federalas. + +=== Proceder + +Per la realisaziun da l'EMBAG èn ils uffizis federals sezs responsabels. Vista l'impurtanza creschenta da l'open source è vegnì decidì da reelavurar la guida pratica _link:em002-1.pdf[Em002-1]_ ensemen cun tuttas gruppas d'interess. Ultra da quai èn vegnids agiuntads meds supplementars per la realisaziun da l'EMBAG. + +La guida pratica definescha ils concepts necessaris, exponta las constellaziuns per l'utilisaziun da software open source, mussa nua e co ch'i sa laschan chattar alternativas al software commerzial existent, co che l'open source duai vegnir acquistà, tge models da fatschenta ch'i dat per l'open source e tge models da support ch'èn pussaivels tar l'utilisaziun da l'open source. Ils ulteriurs meds respundan dumondas frequentas e dattan instrucziuns per relaschar software open source tenor l'EMBAG. Els tractan tuttas dumondas davart las licenzas OSS e mussan, co ch'ina communitad po vegnir construida enturn in software. Pliras glistas da controlla per l'orientaziun e la documentaziun stattan era a disposiziun a las autoritads federalas. + +Era ils documents davart l'acquist èn vegnids adattads, e i èn vegnids elavurads in fegl d'infurmaziun supplementar [KBB-MB], ina directiva [BBL-WL] sco er ina glista da controlla [BBL-CL]. + +Inscuritads existentas vegnan eliminadas uschè lunsch sco pussaivel cun questas directivas strategicas, la guida pratica accumpagnanta e las recumandaziuns d'acziun sco er cun ils meds supplementars. + +== Relaziun cun autras strategias + +Questas Directivas strategicas per software open source en l'administraziun federala èn accordadas cun quatter strategias actualas dal maun public e cun l'EMBAG.footnote:[CS 172.019: https://www.fedlex.admin.ch/eli/cc/2023/682/rm] Quellas cuntegnan ina relaziun directa u indirecta cun il tema dal software open source e cun la collavuraziun informatica tranter instituziuns publicas: + +La *Strategia Administraziun federala digitala* [SB001] fixescha otg princips e quatter accents. Cun l'utilisaziun da software open source contribuescha l'administraziun federala a l'accent 4 «Rinforzar la suveranitad digitala». Ina soluziun open source po vegnir reutilisada uschè savens sco ins vul e vegnir adattada als basegns individuals da l'administraziun federala grazia a ses code da funtauna avert. + +Il pensier da la persistenza digitala e da la suveranitad digitala vegn era en giu en la **Strategia Administraziun digitala Svizra 2024–2027**footnote:[Strategia Administraziun digitala Svizra 2024–2027: https://www.digital-public-services-switzerland.ch/strategy]. La Confederaziun ed ils chantuns creeschan cundiziuns basicas adattadas per questa utilisaziun multipla. Moduls da basa per il svilup dal cybergovern vegnan «realisads ina giada ed utilisads cuminaivlamain». La tscherna da software open source facilitescha la reutilisaziun da soluziuns informaticas. + +Tenor la **Strategia Svizra digitala**footnote:[https://digital.swiss/rm/] è decisiv per il success da la Svizra en il spazi digital da rinforzar la colliaziun dals nivels federals. Attenziun speziala sto perquai vegnir dada a la coordinaziun tranter Confederaziun, chantuns e vischnancas sco er a la collavuraziun tranter las organisaziuns activas en il sectur da la digitalisaziun en tut la Svizra. Il Cussegl federal ha ultra da quai dà ina impurtanza speziala a la suveranitad digitala da la Svizra sco tema d'accent 2023.footnote:[https://digital.swiss/rm/strategia/temas-d-accent/suveranitad-digitala] + +En la **Strategia Open Government Data Svizra (2019–2023)**footnote:[Strategia Open Government Data 2019 – 2023] tegna il Cussegl federal en scrit che datas da l'administraziun federala che n'èn betg persunalas e betg criticas per la segirezza duain vegnir publitgadas tenor il princip Open by Default. L'administraziun federala ha lantschà per quai il portal opendata.swiss.footnote:[https://opendata.swiss/rm] Uffizis federals, chantuns, citads ed ulteriuras organisaziuns publicas han publitgà là actualmain passa 11 700 sets da datas. + +Il plan directiv Open Government Data 2024–2027footnote:[https://www.bfs.admin.ch/asset/rm/28425806] realisescha il princip Open by Default. + +== Governanza e meds + +Sch'ins discurra da software open source, sto vegnir distinguì tranter *consuming* (utilisar), *contributing* (contribuir a code existent) e *creating* (pia novs projects). + +image::./assets/four-cs/four-cs.rm.svg[Ils 4 C en il context da l'OSS] + +Illustraziun 1: Ils 4 C en il context da l'OSS + +La *collaboration* è ultra da quai adina imaginabla en il fund. Tar il creating sto ella vegnir inizialisada da l'administraziun federala, tar il contributing exista ella gia, e tar il consuming po ella era esser d'agid (p.ex. gruppa d'utilisaders). + +Tar il *consuming* da software open source duai quel vegnir tractà e valità egualmain sco software proprietar. + +Tar il *svilup* da software è la relaschada open source fundamentalmain obligatorica, cun resalva da las excepziuns fixadas en l'art. 9 EMBAG (dretgs da terzas persunas e motivs relevants per la segirezza). + +Questas excepziuns vegnan tractadas en link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS]. + +Las autoritads federalas, pia las unitads administrativas da l'administraziun federala, èn sezzas responsablas per l'observaziun correcta; i n'exista nagina cumpetenza centrala. + +La *publicaziun* porta in plivalur en spezial, sch'ina *communitad* d'interessads nascha e lavura cuminaivlamain al software. Sche la communitad collavura ad in project e sche l'administraziun federala lascha vinavant questas contribuziuns, nascha in profit economic ed effects da sinergia.footnote:[https://test.bitkom.org/sites/main/files/2023-03/BitkomLeitfadenOpenSourceSoftware31.pdf, chapitel 4 (per tudestg)] + +En la pratica cumpiglia la relaschada savens betg mo il code da funtauna, mabain era tut ils auters aspects (documentaziun, governanza, instrucziuns da build etc.). + +Fundamentalmain n'exista per l'administraziun federala nagina obligaziun da construir communitads; l'incumbensa legala pretenda mo la publicaziun dal code da funtauna. L'administraziun federala duess investir prioritarmain en communitads, nua che il profit per la Confederaziun e per terzas persunas è grond e la lavur uschè pitschna sco pussaivel. + +Actualmain n'exista nagina plattafurma cuminaivla da la Confederaziun per il *svilup e la publicaziun da code da funtauna*. Mintga autoritad sto perquai tscherner sezza ina plattafurma (repositori) per la publicaziun. La guida pratica en link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source] e las glistas da controlla appartegnentas fixeschan, co ch'i sto vegnir lavurà cun ina plattafurma e tge caracteristicas ch'ella sto ademplir. + +La *tscherna da la licenza* vegn tractada en la link:em002-3.pdf[Em002-3 Guida da licenzas OSS]), che preschenta ina selecziun da licenzas standard ed explitgescha lur utilisaziun. Agens texts da licenza duai l'administraziun federala utilisar mo en cas motivads tenor l'art. 9 al. 4 EMBAG. + +Tar l'utilisaziun ed il svilup da l'OSS sto il **support**footnote:[Almain durant il ciclus da vita cun agid da contracts u d'ina communitad.] adina vegnir reglà (era sch'ins renunzia ad el). L'unitad administrativa cumpetenta reglescha quai en il process da relaschada u tar la definiziun da la communitad. L'EMBAG na fa naginas prescripziuns davart quai, ed i na vegnan messas a disposiziun naginas ulteriuras finanzas u resursas da persunal per il support. I po esser raschunaivel d'integrar il support ed il svilup vinavant cuminaivel, nua che il profit per las autoritads svizras u per l'economia svizra vegn considerà sco suffizientamain grond (custs d'ecosistem) e/u nua ch'ins aspira ina partiziun dals custs u ina collavuraziun. Sche il furnitur surpiglia quai, pon ses custs da support vegnir purtads dals utilisaders. + +L'*acquist da l'OSS* ha lieu via il process d'acquist regular da l'administraziun federala. L'UFCL metta a disposiziun ils documents ed ils meds correspundents. + +Supplementarmain stat a disposiziun in _fegl d'infurmaziun davart l'acquist da software e l'art. 9 EMBAG_footnote:[Disponibel qua (per tudestg): https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html e https://perimap.admin.ch/goto_perimap_file_46835_download.html] _[KBB-MB]_ (vesair illustraziun 2). + +Reflexiuns giuridicas e praticas mainan a quai che l'obligaziun da relaschar OSS po sut tschertas circumstanzas vegnir transferida ad in furnitur (tar il concurs u durant il manaschi). Ils meds d'acquist ed il process da relaschada determineschan, co ch'i sto vegnir procedì cun il furnitur. Quai vegn cuntanschì per gronda part cun cumplettar ils process, las sbozzas da contract ed ils meds existents. + +Il proceder organisatoric è reglà en link:em002-2.pdf[Em002-2 Instrucziuns per publitgar software open source] ed en ils meds appartegnents. + +*Dal puncta da vista dal dretg d'acquist vegn l'OSS tractà egualmain sco il software proprietar.* Perquai che per l'OSS, tenor la definiziun da l'Open Source Initiative (OSI), na vegnan incassadas naginas taxas da licenza, po software fundamentalmain vegnir telechargià ed utilisà senza concurs. Mo las prestaziuns che ston vegnir furnidas d'interpresas (p.ex. support, engineering) suttastattan lura al dretg d'acquist e ston vegnir messas a concurs. + +Nua ch'igl è necessari vegnan ils aspects relevants dals meds integrads en ils process da management da projects da la Confederaziun (pia HERMES). + +L'open development (svilup avert directamain sin in repositori accessibel publicamain) e la participaziun a projects existents (contribution) vegnan era tractads en las explicaziuns en link:em002-4.pdf[Em002-4 Guida da communitads OSS]. + +=== Survista dals documents OSS + +La grafica suandanta dat ina survista dals documents relevants per l'OSS en l'administraziun federala. + +include::partials/document-map.rm.adoc[] + +Illustraziun 2: Documents en connex cun l'art. 9 EMBAG + +== Finamiras + +Las suandantas finamiras surordinadas ed a lunga vista mussan, co che l'administraziun federala utilisescha il potenzial dal software open source ed affrunta ils ristgs e las sfidas: + +A) Observaziun da las prescripziuns legalas (pia da l'EMBAG):: La relaschada da software open source sa drizza tenor l'artitgel 9 EMBAG. L'observaziun da questa prescripziun legala è in aspect central da questas directivas e dals documents appartegnents. Las autoritads federalas duain observar quest artitgel e maximar il profit per l'administraziun federala e per la Svizra. Per la realisaziun èn las unitads d'organisaziun sezzas responsablas. + +B) Augmentar l'innovaziun e l'efficienza:: Il software open source furma oz la basa da l'informatica moderna. Sin la basa dals milliuns da cumponentas e soluziuns disponiblas libramain sa laschan sviluppar e manar rapidamain applicaziuns independentas. Las spargnas da temp e da resursas colliadas cun quai sco er ils princips d'architectura colliads cun il software open source, sco l'interoperabilitad, l'agilitad ed ils microservetschs, augmentan la capacitad d'innovaziun e l'efficienza dal svilup da software. Quai accelerescha puspè la digitalisaziun da l'administraziun federala. Cun relaschar software open source po vegnir accelerada la surpigliada da soluziuns digitalas en il rom federal e pon vegnir utilisads effects da sinergia. + +C) Promover ina cultura da la collavuraziun:: Il software open source promova, cun cundivider il code da funtauna, cun ina communicaziun averta e cun praticas dal svilup vinavant cuminaivel, ina cultura da la collavuraziun en l'informatica. Quests princips sa laschan applitgar per rinforzar la collavuraziun en l'informatica entaifer l'administraziun federala, cun ils chantuns e cun ulteriuras instituziuns publicas. Quai rinforza la suveranitad digitala e reducescha las dependenzas da purschiders da software. + +D) Crear claritad e reducir ils ristgs:: Infurmaziuns davart licenzas open source utilisadas savens duain pussibilitar a l'administraziun federala da tscherner las licenzas gistas. Quai reducescha ils ristgs giuridics. Recumandaziuns tecnicas e giuridicas abiliteschan l'administraziun federala d'utilisar e da relaschar software open source. + +E) Crear ina survista per utilisar sinergias:: Software open source vegn actualmain duvrà en numerus lieus entaifer l'administraziun federala en moda differenta. I dat blera savida ed experientscha, ma las sinergias na sa laschan anc betg utilisar, perquai ch'ina survista da las soluziuns open source duvradas manca. Ina tala survista e l'acquist cuminaivel da prestaziuns pussibiliteschan da meglier exquirir il potenzial dal software open source, quai che spargna resursas e crea sinergias. + +F) Augmentar l'attractivitad sco patrun en l'informatica:: Software open source è popular tar bleras persunas spezialisadas en informatica cun ina auta qualificaziun. L'utilisaziun da tecnologias open source modernas e l'applicaziun da metodas da svilup open source motiveschan blers collaboraturs ed augmentan l'attractivitad da l'administraziun federala sco patruna. Per utilisar software open source dovra la Confederaziun persunas spezialisadas cun savida ed experientscha en il sectur dal software open source; tar la reclutaziun da persunas spezialisadas duess ins perquai s'engaschar per ampliar la savida interna davart l'open source. + +== Mesiras + +Las suandantas mesiras duain contribuir a cuntanscher las finamiras exponidas survart. Las mesiras vegnan cumplettadas u remplazzadas a temp ed adattadas a circumstanzas midadas. + +La glista suandanta illustrescha, co che las finamiras èn colliadas cun las mesiras correspundentas. Quellas sustegnan la realisaziun da las finamiras respectivas, ma pon era avair effects sin autras finamiras. + +A) Observaziun da las prescripziuns legalas (EMBAG):: +1) Realisar la _Guida pratica per software open source en l'administraziun federala link:em002-1.pdf[Em002-1]_ + +2) Realisar las _Instrucziuns per publitgar software open source link:em002-2.pdf[Em002-2]_ ed ils meds che deriveschan da quellas. + +3) Ils posts d'acquist construeschan savida davart l'open source e sustegnan uschia l'administraziun federala. + +B) Augmentar l'innovaziun e l'efficienza:: +1) Realisar la _Guida pratica per software open source en l'administraziun federala link:em002-1.pdf[Em002-1]_ + +3) Ils posts d'acquist san tractar cun l'open source e sustegnair optimalmain l'art. 9 EMBAG. + +8) Promover la construcziun da communitads + +C) Promover ina cultura da la collavuraziun:: +1) Realisar la _Guida pratica per software open source en l'administraziun federala link:em002-1.pdf[Em002-1]_ + +4) Promover il barat da savida e d'experientscha + +8) Promover la construcziun da communitads + +9) Examinar la pussaivladad d'ina atgna plattafurma da publicaziun; promover l'open development + +D) Crear claritad e reducir ils ristgs:: +1) Realisar la _Guida pratica per software open source en l'administraziun federala link:em002-1.pdf[Em002-1]_ + +2) Realisar las _Instrucziuns per publitgar software open source link:em002-2.pdf[Em002-2]_ ed ils meds che deriveschan da quellas. + +E) Crear ina survista per utilisar sinergias:: +6) Realisar l'acquist cuminaivel da prestaziuns + +7) Crear ina survista dal software open source duvrà, relaschà e co-sviluppà + +8) Promover la construcziun da communitads + +F) Augmentar l'attractivitad sco patrun en l'informatica:: +5) Promover e communitgar ina cultura open source + +8) Promover la construcziun da communitads + +=== Descripziun da las mesiras + +Mesira 1: Realisar la _Guida pratica per software open source en l'administraziun federala link:em002-1.pdf[Em002-1]_.:: +Schebain che il term software open source ha gia passa 20 onns, mainan la derasaziun cuntinuanta da software open source ed il svilup permanent da scenaris d'applicaziun adina puspè a novas praticas e dumondas. Novs svilups e svilups vinavant da soluziuns open source furman ultra da quai adina pli savens alternativas cumplainas al software proprietar. Cun l'EMBAG s'agiunta l'obligaziun da publitgar ils agens svilups. ++ +La _Guida pratica per software open source en l'administraziun federala_ dat ina survista ed ina introducziun en il tema, mussa ils avantatgs ed ils dischavantatgs dal software open source ed explitgescha tut ils auters meds. Ella cuntegna ultra da quai best practices, alternativas cumprovadas e recumandaziuns praticas, co che l'administraziun federala duai tractar cun software open source. ++ +Questa guida pratica ed ils ulteriurs meds duain vegnir duvrads e realisads da las autoritads federalas en il tractament da software open source e da relaschadas. ++ +Sco curta introducziun en il tema stattan a disposiziun in _fegl d'infurmaziun davart l'applicaziun da l'art. 9 EMBAG_ sco er link:em002-6.pdf[Em002-6 FAQ davart la publicaziun da l'OSS (OSS-FAQ)]. + +Mesira 2: Realisar las Instrucziuns per publitgar software open source link:em002-2.pdf[Em002-2] ed ils meds che deriveschan da quellas.:: +L'utilisaziun efficienta da l'OSS en il svilup da software pretenda savens contribuziuns en furma da correcturas da sbagls e d'extensiuns funcziunalas. Cun l'EMBAG exista ultra da quai in'obligaziun da relaschar software creà sez. L'orientaziun necessaria vegn purschida da differents meds. ++ +Las glistas da controlla fan part da las instrucziuns per publitgar OSS. Ellas duain vegnir duvradas supplementarmain a las directivas correspundentas da las unitads administrativas, avant e durant il svilup. ++ +I vegn era tractà il tractament dal code existent tenor l'art. 9 EMBAG. La finamira è da chattar e da realisar soluziuns pragmaticas. ++ +Las licenzas èn spezialmain impurtantas en il rom da l'OSS. Tar la relaschada, l'acquist e l'utilisaziun da software ston las licenzas vegnir accordadas cun quai ch'è giuridicamain pussaivel e cun l'effect giavischà. La savida necessaria e las decisiuns correspundentas duain vegnir documentadas. En quest connex vegnan era mess a disposiziun ils documents supplementars necessaris sco il Contributor Licence Agreement (CLA). ++ +Per facilitar l'applicaziun da l'art. 9 EMBAG vegnan fatgas cumplettaziuns a la metoda da management da projects da la Confederaziun (HERMES). Las unitads administrativas duain chattar ils meds necessaris en il process regular. + +Mesira 3: Ils posts d'acquist construeschan savida davart l'open source e sustegnan uschia l'administraziun federala.:: +Per ils aspects d'acquist è vegnì creà il nov link:em002-7.pdf[Em002-7 Aspects strategics da l'acquist ed OSS]. ++ +Per garantir ina concurrenza ampla pretenda l'acquist che software open e closed source vegnian tractads egualmain. Las pretensiuns augmentadas en connex cun l'art. 9 EMBAG concernent ils meds da acquistar per la publicaziun da software ston vegnir resguardadas. ++ +Il Center da cumpetenza per l'acquist public da la Confederaziun (CCA) ha publitgà sut il suandant link in fegl d'infurmaziun davart l'acquist da software e l'art. 9 EMBAG [KBB-MB]: link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html]. ++ +Ulteriur sustegn stat a disposiziun en l'intranet da l'UFCL (accessibel mo ord la rait da la Confederaziun) cun la link:https://intranet.bbl.admin.ch/bbl_kp/de/home/informatik/beschaffung-buerotechnik-informatik-des-bbl/werkzeugkasten.html[directiva Open Source en l'acquist] [BBL-WL] e la 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[glista da controlla excepziun integrala art. 9 EMBAG] [BBL-CL]. + +Mesira 4: Promover il barat da savida e d'experientscha:: +Il crear e l'utilisar da software open source pretendan ina savida profunda e spezialisada. Al medem temp sa sviluppan las soluziuns open source cuntinuadamain vinavant e novs projects open source vegnan lantschads. Igl è perquai ina sfida da mantegnair ina survista cumplessiva davart las tendenzas e las tecnologias actualas. ++ +Per promover l'utilisaziun professiunala da l'open source e per facilitar il barat da savida e d'experientscha duain infurmaziuns vegnir cundivididas entaifer ina communitad d'interess ampliada ed ils collaboraturs entaifer l'administraziun federala vegnir sustegnids cumpetentamain. + +Mesira 5: Promover e communitgar ina cultura open source:: +La digitalisaziun che progredescha ha acutisà ulteriurmain il mancament da persunal qualifitgà en l'informatica. Quai grevescha era als purschiders da prestaziuns da l'administraziun federala la reclutaziun da persunal informatic qualifitgà. L'utilisaziun da software open source e la cultura da sviluppaders colliada cun quai èn sco enconuschent in argument per persunas spezialisadas da sa candidar per tals posts. ++ +Per vegnir percepì en il public sco patrun «amiaivel vers l'open source» duain las differentas mesiras e las soluziuns open source duvradas vegnir communitgadas activamain en furma d'in radar da tecnologia.footnote:[Radars da tecnologia duain vegnir duvrads uschè amplamain sco pussaivel. Quai vul dir, sche pussaivel sin il nivel da las autoritads federalas u schizunt da l'administraziun federala.] Per l'attractivitad dal patrun è ultra da quai impurtant da permetter als emploiads da la Confederaziun da contribuir a software open source existent. + +Mesira 6: Realisar l'acquist cuminaivel da prestaziuns:: +La mantenziun ed il support da software open source vegnan actualmain furnids da collaboraturs interns da l'administraziun federala, entant che furniturs externs porschan prestaziuns per tschertas soluziuns open source. Questas prestaziuns vegnan savens acquistadas independentamain dals respectivs uffizis, quai che po manar a dubladuras ed a las perditas finanzialas colliadas cun quai. ++ +L'acquist cuminaivel da prestaziuns per software open source duai augmentar la fidadadad da la mantenziun e dal support en il manaschi e simplifitgar l'utilisaziun da soluziuns open source. Sin la basa dal radar da tecnologia (vesair mesira 5) duain prestaziuns per ils sistems e las tecnologias open source ils pli derasads vegnir acquistads centralmain. Questas prestaziuns pon lura vegnir obtegnidas da tut ils uffizis tenor il basegn.footnote:[Quai pertutga il support per il software duvrà. Il support tras terzas persunas per software relaschà tenor l'EMBAG è pussaivel e po vegnir facturà. Quai vegn tractà en link:em002-4.pdf[Em002-4 Guida da communitads OSS].] + +Mesira 7: Crear ina survista dal software open source duvrà, relaschà e co-sviluppà.:: +Perquai che tar l'utilisaziun da software open source na ston vegnir cumpradas naginas licenzas, croda savens davent il process d'acquist custaivel. ++ +Quai grevescha il suandar, nua che l'administraziun federala duvra tge software open source. Uschia na po il potenzial dal software open source – sco l'utilisaziun da sinergias, la furmaziun da communitads per il barat d'experientschas etc. – betg vegnir exquirì cumplainamain. ++ +In radar da tecnologia entaifer l'administraziun federala duai dar ina survista, nua che tge software open source vegn duvrà e tgi che dispona da tge savida. + +Mesira 8: Promover la construcziun da communitads:: +La construcziun da e la participaziun a communitads per il svilup da projects èn fitg impurtantas per l'OSS. Da quai resultan sinergias considerablas. I po esser che il project exista gia e che la Confederaziun sa participescha mo, u che la Confederaziun maina il project, u ch'i sa tracta era d'ina collavuraziun. Da renunziar ad ina communitad è era ina decisiun impurtanta. Il svilup direct sin in repositori avert (senza relaschada posteriura) po purtar ulteriurs gudogns d'efficienza e promover il svilup cuminaivel. Em002-4 porscha orientaziun e motivaziun per la construcziun da communitads tras las autoritads federalas. + +Mesira 9: Examinar la pussaivladad d'ina atgna plattafurma da publicaziun; promover l'open development:: +La construcziun ed il manaschi d'ina plattafurma da publicaziun interna u svizra vegnan examinads e realisads suenter ina decisiun correspundenta. ++ +La finamira d'ina plattafurma independenta per l'administraziun federala è la mantegnida da la suveranitad e da l'independenza digitala. La collavuraziun vegn simplifitgada ed al medem temp nascha ina survista da las activitads. ++ +Ina collavuraziun federala sur tuttas autoritads da la Svizra (simil ad opencode.de) vegn examinada (p.ex. ADS u eOperations Svizra). + +== Agiuntas + +=== Midadas envers la versiun precedenta + +* Midadas e meglieraziuns redacziunalas pitschnas. +* Il fegl da fatgs Em002-5 è vegnì remplazzà tras il fegl d'infurmaziun Meds OSS. +* Nov è s'agiuntà il document «`link:em002-7.pdf[Em002-7 Acquist ed OSS]`». +* Nova grafica cun ils 4 C en il context da l'OSS (cumplettaziun cun «collaboration»). +* Novs renviaments a l'UFCL ed al CCA. + +=== Referenzas als meds OSS + +La glista da referenza suandanta renumbra ils documents da la seria link:em002.pdf[Em002 Meds per software open source] en l'administraziun federala. + +NOTE: Ils meds ed en spezial las glistas da controlla sa basan per part sin ils *documents OSS dal chantun Berna*, publitgads sut ina licenza BSD3 (link:https://github.com/kanton-bern/oss[https://github.com/kanton-bern/oss]). + +Ils documents Em002 actuals vegnan publitgads sin la pagina Meds OSS da la Chanzlia federala. https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/open_source_software.html. + +Ils documents vegnan ultra da quai publitgads sin GitHub. Là po era vegnir dà in resun. {url-repo} + +include::partials/references.rm.adoc[tags=ref-em002-tools] + +Survista visuala dals meds OSS: + +include::partials/document-map.rm.adoc[] + +Illustraziun 3: Documents en connex cun l'art. 9 EMBAG + +=== Referenzas generalas + +Tuttas referenzas a la seria da documents Em002 sa chattan qua *en Em002 Directivas strategicas [Em002*]. + +include::partials/references.rm.adoc[tags=ref-em002-general] + +=== Abreviaziuns + +Questa glista d'abreviaziuns cuntegna tuttas abreviaziuns duvradas en la seria da documents OSS Em002. In glossari sa chatta en link:em002-6.pdf[Em002-6 FAQ davart la publicaziun da l'OSS]. + +[horizontal] +include::partials/abbreviations.rm.adoc[tags=abbr-em002] +endif::[] 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 95a9d90..0000000 Binary files a/docs/en/Em002-2.1 Checklist OSS Preliminary Assessment.odt and /dev/null differ diff --git a/docs/en/Em002-2.2 Checklist OSS Analysis and Preparation.odt b/docs/en/Em002-2.2 Checklist OSS Analysis and Preparation.odt deleted file mode 100644 index fe270d5..0000000 Binary files a/docs/en/Em002-2.2 Checklist OSS Analysis and Preparation.odt and /dev/null differ 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 223a534..0000000 Binary files a/docs/en/Em002-2.3 Checklist OSS Release and Publication.odt and /dev/null differ 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 c455d36..0000000 Binary files a/docs/en/Em002-4.1 Checklist OSS Community.odt and /dev/null differ diff --git a/docs/en/assets/em002-1/media/image1.png b/docs/en/assets/em002-1/media/image1.png deleted file mode 100644 index 63b2b42..0000000 Binary files a/docs/en/assets/em002-1/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-1/media/image2.png b/docs/en/assets/em002-1/media/image2.png deleted file mode 100644 index 44adefe..0000000 Binary files a/docs/en/assets/em002-1/media/image2.png and /dev/null differ 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/assets/em002-2/media/image1.png b/docs/en/assets/em002-2/media/image1.png deleted file mode 100644 index 61ae0d4..0000000 Binary files a/docs/en/assets/em002-2/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-2/media/image2.png b/docs/en/assets/em002-2/media/image2.png deleted file mode 100644 index 09b0183..0000000 Binary files a/docs/en/assets/em002-2/media/image2.png and /dev/null differ diff --git a/docs/en/assets/em002-2/media/image3.png b/docs/en/assets/em002-2/media/image3.png deleted file mode 100644 index 01f26f2..0000000 Binary files a/docs/en/assets/em002-2/media/image3.png and /dev/null differ diff --git a/docs/en/assets/em002-2/media/image4.png b/docs/en/assets/em002-2/media/image4.png deleted file mode 100644 index 2ddca21..0000000 Binary files a/docs/en/assets/em002-2/media/image4.png and /dev/null differ diff --git a/docs/en/assets/em002-3/media/image1.png b/docs/en/assets/em002-3/media/image1.png deleted file mode 100644 index 70dfcc5..0000000 Binary files a/docs/en/assets/em002-3/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-3/media/image2.png b/docs/en/assets/em002-3/media/image2.png deleted file mode 100644 index a43675c..0000000 Binary files a/docs/en/assets/em002-3/media/image2.png and /dev/null differ diff --git a/docs/en/assets/em002-3/media/image3.png b/docs/en/assets/em002-3/media/image3.png deleted file mode 100644 index bc53488..0000000 Binary files a/docs/en/assets/em002-3/media/image3.png and /dev/null differ diff --git a/docs/en/assets/em002-3/media/image4.png b/docs/en/assets/em002-3/media/image4.png deleted file mode 100644 index 94b58e3..0000000 Binary files a/docs/en/assets/em002-3/media/image4.png and /dev/null differ diff --git a/docs/en/assets/em002-4/media/image1.png b/docs/en/assets/em002-4/media/image1.png deleted file mode 100644 index 461cf75..0000000 Binary files a/docs/en/assets/em002-4/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-4/media/image2.png b/docs/en/assets/em002-4/media/image2.png deleted file mode 100644 index ff7630d..0000000 Binary files a/docs/en/assets/em002-4/media/image2.png and /dev/null differ diff --git a/docs/en/assets/em002-5/media/image1.png b/docs/en/assets/em002-5/media/image1.png deleted file mode 100644 index 1681b3d..0000000 Binary files a/docs/en/assets/em002-5/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-5/media/image2.png b/docs/en/assets/em002-5/media/image2.png deleted file mode 100644 index 63b2b42..0000000 Binary files a/docs/en/assets/em002-5/media/image2.png and /dev/null differ diff --git a/docs/en/assets/em002-7/media/image1.png b/docs/en/assets/em002-7/media/image1.png deleted file mode 100644 index 56b66fd..0000000 Binary files a/docs/en/assets/em002-7/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002-7/media/image2.png b/docs/en/assets/em002-7/media/image2.png deleted file mode 100644 index 3197607..0000000 Binary files a/docs/en/assets/em002-7/media/image2.png and /dev/null differ diff --git a/docs/en/assets/em002-7/media/image3.png b/docs/en/assets/em002-7/media/image3.png deleted file mode 100644 index a1cf1ea..0000000 Binary files a/docs/en/assets/em002-7/media/image3.png and /dev/null differ diff --git a/docs/en/assets/em002-7/media/image4.png b/docs/en/assets/em002-7/media/image4.png deleted file mode 100644 index 96f3b44..0000000 Binary files a/docs/en/assets/em002-7/media/image4.png and /dev/null differ diff --git a/docs/en/assets/em002-7/media/image5.png b/docs/en/assets/em002-7/media/image5.png deleted file mode 100644 index 4337614..0000000 Binary files a/docs/en/assets/em002-7/media/image5.png and /dev/null differ diff --git a/docs/en/assets/em002/media/image1.png b/docs/en/assets/em002/media/image1.png deleted file mode 100644 index 748f8fd..0000000 Binary files a/docs/en/assets/em002/media/image1.png and /dev/null differ diff --git a/docs/en/assets/em002/media/image2.png b/docs/en/assets/em002/media/image2.png deleted file mode 100644 index 56b66fd..0000000 Binary files a/docs/en/assets/em002/media/image2.png and /dev/null differ 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.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.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.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.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.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.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.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.adoc b/docs/index.adoc new file mode 100644 index 0000000..f538ae7 --- /dev/null +++ b/docs/index.adoc @@ -0,0 +1,285 @@ +:lang: en +ifeval::["{lang}" == "en"] += Tools for Publishing Open Source Software +:title-logo-line1: Federal Chancellery FCh +:title-logo-line2: Digital Transformation and ICT Steering DTI +endif::[] +ifeval::["{lang}" == "de"] += Hilfsmittel zur Veröffentlichung von Open-Source-Software +:title-logo-line1: Bundeskanzlei BK +:title-logo-line2: Digitale Transformation und IKT-Lenkung DTI +endif::[] +ifeval::["{lang}" == "fr"] += Outils pour la publication de logiciels open source +:title-logo-line1: Chancellerie fédérale ChF +:title-logo-line2: Transformation numérique et gouvernance de l'informatique TNI +endif::[] +ifeval::["{lang}" == "it"] += Strumenti per la pubblicazione di software open source +:title-logo-line1: Cancelleria federale CaF +:title-logo-line2: Trasformazione digitale e governance delle TIC TDT +endif::[] +ifeval::["{lang}" == "rm"] += Meds per publitgar software open source +:title-logo-line1: Chanzlia federala ChF +:title-logo-line2: Transfurmaziun digitala e direcziun da las TIC TDT +endif::[] +:govpress-style: report +// Black, not the colour mark the guidelines carry: this page lists them and is +// not one of them. +:title-logo-base: black +// Deliberately empty: the document carries no classification mark. Omitting the +// line renders identically -- it is kept so the question is answered rather than +// left unasked. +:classification: +:revnumber: 2.0 +:revdate: 14.09.2026 +// Contents and numbering for the *web* view of this source. open-govpress sets +// all four itself for `:govpress-style: report` (styles/common.adoc and +// styles/report.adoc), so they change nothing in the PDF -- GitHub and GitLab +// render this file with plain Asciidoctor, which does not, and without them the +// web view loses its contents list and its section numbers. +:toc: +:toclevels: 3 +:sectnums: +:sectnumlevels: 3 + +ifeval::["{lang}" == "en"] +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:em002.pdf[Em002 Strategic 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:em002-2.pdf[Em002-2 Instructions for Publishing OSS] (05.05.2026) + +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Preliminary Assessment Checklist] (05.05.2026) + +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Analysis and Preparation Checklist] (05.05.2026) + +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Release and Publication Checklist] (05.05.2026) + +link:em002-3.pdf[Em002-3 OSS Licensing Guidelines] (05.05.2026) + +link:em002-4.pdf[Em002-4 OSS Community Guidelines] (05.05.2026) + +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 OSS Community Checklist] (05.05.2026) + +link:em002-5.pdf[Em002-5 EMOTA and OSS Factsheet] (06.05.2026) + +link:em002-6.pdf[Em002-6 FAQ on OSS and Art. 9 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 + +== 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] +endif::[] + +ifeval::["{lang}" == "de"] +Die Bundesbehörden sind verpflichtet, den Quellcode von Software offenzulegen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen. Sie müssen allen erlauben, die Software ohne Lizenzgebühren zu nutzen, weiterzuentwickeln und zu verbreiten. Diese Pflicht ergibt sich aus Artikel 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG). Die Verantwortung für die Umsetzung liegt bei den einzelnen Behörden. Die Bundeskanzlei stellt geeignete Hilfsmittel bereit, um die Bundesbehörden bei der Erfüllung dieser Pflicht zu unterstützen. + +== Worum geht es? + +Bei der Veröffentlichung von Open-Source-Software sind Fragen zu Recht, Lizenzen, Sicherheit, Organisation und Kosten zu klären. Je nach Anwendungsfall bestehen Varianten und Einschränkungen. Der für die Umsetzung der gesetzlichen Vorgabe erforderliche Wissensstand ist innerhalb der Bundesverwaltung je nach Erfahrung unterschiedlich. Aus diesem Grund hat die Bundeskanzlei Hilfsmittel und Checklisten erarbeitet, die Unterstützung und Orientierung bei der Entscheidfindung bieten. + +== Wer ist verantwortlich? + +Die Verantwortung für die Umsetzung liegt bei den einzelnen Behörden. Die Bundeskanzlei stellt geeignete Hilfsmittel bereit, um die Bundesbehörden dabei zu unterstützen. + +== Welche Hilfsmittel stehen zur Verfügung? + +Die folgenden Hilfsmittel stehen in Form von Leitlinien, Anleitungen, Checklisten, Merkblättern und FAQ zur Verfügung: + +link:em002.pdf[Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung] (05.05.2026) + +link:em002-1.pdf[Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung] (05.05.2026) + +link:em002-2.pdf[Em002-2 Anleitung zur Veröffentlichung von OSS] (05.05.2026) + +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Checkliste OSS-Vorabklärung] (05.05.2026) + +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung] (05.05.2026) + +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung] (05.05.2026) + +link:em002-3.pdf[Em002-3 Leitfaden OSS-Lizenzierung] (05.05.2026) + +link:em002-4.pdf[Em002-4 Leitfaden OSS-Community] (05.05.2026) + +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Checkliste OSS-Community] (05.05.2026) + +link:em002-5.pdf[Em002-5 Merkblatt EMBAG und OSS] (06.05.2026) + +link:em002-6.pdf[Em002-6 FAQ zu OSS und Art. 9 EMBAG] (05.05.2026) + +link:em002-7.pdf[Em002-7 Leitfaden OSS: Anwendung von Artikel 9 des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG)] (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) nur auf Deutsch, Französisch und Italienisch verfügbar + +== Weitere Informationen + +https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html[Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben EMBAG] nur auf Deutsch verfügbar + +http://www.opensource.admin.ch/[OSS-Katalog] +endif::[] + +ifeval::["{lang}" == "fr"] +Les autorités fédérales sont tenues de publier le code source des logiciels qu'elles développent ou font développer pour accomplir leurs tâches. Elles doivent permettre à quiconque d'utiliser, de développer et de diffuser ces logiciels sans percevoir de redevance de licence. Cette obligation découle de l'article 9 de la loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA). La responsabilité de la mise en œuvre incombe à chaque autorité. La Chancellerie fédérale met à disposition des outils appropriés pour aider les autorités fédérales à satisfaire à cette obligation. + +== De quoi s'agit-il ? + +La publication de logiciels open source soulève des questions juridiques, de licences, de sécurité, d'organisation et de coûts. Selon le cas d'application, il existe des variantes et des limites à prendre en compte. Le niveau de connaissances requis pour mettre en œuvre cette exigence légale varie au sein de l'administration fédérale en fonction de l'expérience. C'est pourquoi la Chancellerie fédérale a élaboré des outils et des listes de contrôle qui offrent un soutien et une orientation pour la prise de décision. + +== Qui est responsable ? + +La responsabilité de la mise en œuvre incombe à chaque autorité. La Chancellerie fédérale met à disposition des outils appropriés pour aider les autorités fédérales dans cette démarche. + +== Quels outils sont disponibles ? + +Les outils suivants sont disponibles sous forme de lignes directrices, d'instructions, de listes de contrôle, d'aide-mémoire et de FAQ : + +link:em002.pdf[Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale] (05.05.2026) + +link:em002-1.pdf[Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale] (05.05.2026) + +link:em002-2.pdf[Em002-2 Instructions pour la publication d'OSS] (05.05.2026) + +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Liste de contrôle Évaluation préalable OSS] (05.05.2026) + +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Liste de contrôle Analyse et préparation OSS] (05.05.2026) + +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Liste de contrôle Validation et publication OSS] (05.05.2026) + +link:em002-3.pdf[Em002-3 Guide de licences OSS] (05.05.2026) + +link:em002-4.pdf[Em002-4 Guide des communautés OSS] (05.05.2026) + +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Liste de contrôle Communauté OSS] (05.05.2026) + +link:em002-5.pdf[Em002-5 Aide-mémoire LMETA et OSS] (06.05.2026) + +link:em002-6.pdf[Em002-6 FAQ sur l'OSS et l'art. 9 LMETA] (05.05.2026) + +link:em002-7.pdf[Em002-7 Guide OSS : application de l'article 9 de la loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA)] (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) disponible uniquement en allemand, français et italien + +== Informations complémentaires + +https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html[Loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités LMETA] disponible uniquement en allemand + +http://www.opensource.admin.ch/[Catalogue OSS] +endif::[] + +ifeval::["{lang}" == "it"] +Le autorità federali sono tenute a pubblicare il codice sorgente del software che sviluppano o fanno sviluppare per adempiere i loro compiti. Esse devono consentire a chiunque di utilizzare, sviluppare ulteriormente e diffondere il software senza riscuotere tasse di licenza. Questo obbligo discende dall'articolo 9 della legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA). La responsabilità dell'attuazione spetta alle singole autorità. La Cancelleria federale mette a disposizione strumenti adeguati per sostenere le autorità federali nell'adempimento di questo obbligo. + +== Di cosa si tratta? + +La pubblicazione di software open source solleva questioni giuridiche, di licenza, di sicurezza, di organizzazione e di costi. A seconda del caso d'applicazione vi sono varianti e limiti da considerare. Il livello di conoscenze necessario per attuare la prescrizione legale varia all'interno dell'Amministrazione federale a seconda dell'esperienza. Per questo motivo la Cancelleria federale ha elaborato strumenti e liste di controllo che offrono sostegno e orientamento nel processo decisionale. + +== Chi è responsabile? + +La responsabilità dell'attuazione spetta alle singole autorità. La Cancelleria federale mette a disposizione strumenti adeguati per sostenere le autorità federali in questo processo. + +== Quali strumenti sono disponibili? + +Sono disponibili i seguenti strumenti sotto forma di linee guida, istruzioni, liste di controllo, promemoria e FAQ: + +link:em002.pdf[Em002 Linee guida strategiche per il software open source nell'Amministrazione federale] (05.05.2026) + +link:em002-1.pdf[Em002-1 Guida pratica per il software open source nell'Amministrazione federale] (05.05.2026) + +link:em002-2.pdf[Em002-2 Istruzioni per la pubblicazione di OSS] (05.05.2026) + +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Lista di controllo Valutazione preliminare OSS] (05.05.2026) + +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Lista di controllo Analisi e preparazione OSS] (05.05.2026) + +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS] (05.05.2026) + +link:em002-3.pdf[Em002-3 Guida alle licenze OSS] (05.05.2026) + +link:em002-4.pdf[Em002-4 Guida alle community OSS] (05.05.2026) + +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Lista di controllo Community OSS] (05.05.2026) + +link:em002-5.pdf[Em002-5 Promemoria LMeCA e OSS] (06.05.2026) + +link:em002-6.pdf[Em002-6 FAQ sull'OSS e l'art. 9 LMeCA] (05.05.2026) + +link:em002-7.pdf[Em002-7 Guida OSS: applicazione dell'articolo 9 della legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA)] (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) disponibile soltanto in tedesco, francese e italiano + +== Ulteriori informazioni + +https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html[Legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità LMeCA] disponibile soltanto in tedesco + +http://www.opensource.admin.ch/[Catalogo OSS] +endif::[] + +ifeval::["{lang}" == "rm"] +Las autoritads federalas èn obligadas da publitgar il code da funtauna dal software ch'ellas sviluppan u fan sviluppar per ademplir lur incumbensas. Ellas ston permetter a mintgin d'utilisar, da sviluppar vinavant e da derasar il software senza incassar taxas da licenza. Quest'obligaziun resulta da l'artitgel 9 da la lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG). La responsabladad per la realisaziun sa chatta tar las singulas autoritads. La Chanzlia federala metta a disposiziun meds adattads per sustegnair las autoritads federalas en l'adempliment da questa obligaziun. + +== Da tge sa tracta? + +Cun publitgar software open source ston vegnir scleridas dumondas giuridicas, da licenzas, da segirezza, d'organisaziun e da custs. Tut tenor il cas d'applicaziun datti variantas e restricziuns da resguardar. Il nivel da savida necessari per realisar la prescripziun legala è different entaifer l'administraziun federala tenor l'experientscha. Perquai ha la Chanzlia federala elavurà meds e glistas da controlla che porschan sustegn ed orientaziun tar il prender da decisiuns. + +== Tgi è responsabel? + +La responsabladad per la realisaziun sa chatta tar las singulas autoritads. La Chanzlia federala metta a disposiziun meds adattads per sustegnair las autoritads federalas en quest process. + +== Tge meds stattan a disposiziun? + +Ils suandants meds stattan a disposiziun en furma da directivas, instrucziuns, glistas da controlla, fegls d'infurmaziun e FAQ: + +link:em002.pdf[Em002 Directivas strategicas per software open source en l'administraziun federala] (05.05.2026) + +link:em002-1.pdf[Em002-1 Guida pratica per software open source en l'administraziun federala] (05.05.2026) + +link:em002-2.pdf[Em002-2 Instrucziuns per publitgar OSS] (05.05.2026) + +link:em002-2-1-checklist-oss-preliminary-assessment.pdf[Em002-2.1 Glista da controlla Evaluaziun preliminara OSS] (05.05.2026) + +link:em002-2-2-checklist-oss-analysis-and-preparation.pdf[Em002-2.2 Glista da controlla Analisa e preparaziun OSS] (05.05.2026) + +link:em002-2-3-checklist-oss-release-and-publication.pdf[Em002-2.3 Glista da controlla Relaschada e publicaziun OSS] (05.05.2026) + +link:em002-3.pdf[Em002-3 Guida da licenzas OSS] (05.05.2026) + +link:em002-4.pdf[Em002-4 Guida da communitads OSS] (05.05.2026) + +link:em002-4-1-checklist-oss-community.pdf[Em002-4.1 Glista da controlla Communitad OSS] (05.05.2026) + +link:em002-5.pdf[Em002-5 Fegl d'infurmaziun EMBAG ed OSS] (06.05.2026) + +link:em002-6.pdf[Em002-6 FAQ davart OSS e l'art. 9 EMBAG] (05.05.2026) + +link:em002-7.pdf[Em002-7 Guida OSS: applicaziun da l'artitgel 9 da la lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG)] (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) disponibel mo per tudestg, franzos ed talian + +== Ulteriuras infurmaziuns + +https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-98828.html[Lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads EMBAG] disponibel mo per tudestg + +http://www.opensource.admin.ch/[Catalog OSS] +endif::[] 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/) - diff --git a/docs/partials/abbreviations.de.adoc b/docs/partials/abbreviations.de.adoc new file mode 100644 index 0000000..27961ab --- /dev/null +++ b/docs/partials/abbreviations.de.adoc @@ -0,0 +1,65 @@ +// Siehe abbreviations.en.adoc für die Begründung dieser Aufteilung. +// tag::abbr-em002[] +AGB:: +Allgemeine Geschäftsbedingungen +// end::abbr-em002[] +// tag::abbr-em002-6[] +AO:: +Application Owner +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +BBL:: +Bundesamt für Bauten und Logistik +BGÖ:: +Öffentlichkeitsgesetz +CLA:: +Contributor Licence Agreement +DCO:: +Developer Certificate of Origin +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +DVS:: +Digitale Verwaltung Schweiz (www.digital-public-services-switzerland.ch/strategy) +// end::abbr-em002[] +// tag::abbr-em002-6[] +DÖDS:: +Digitale Öffentliche Dienste Schweiz (www.digital-public-services-switzerland.ch/strategy) +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +EMBAG:: +Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben +FSF:: +Free Software Foundation +HERMES:: +_Handbuch der Elektronischen Rechenzentren des Bundes_, eine Methode zur Systementwicklung (www.hermes.admin.ch) +ISB:: +Informatiksteuerungsorgan des Bundes (bis 2021) +KBB:: +Kompetenzzentrum Beschaffungswesen Bund +KI:: +Künstliche Intelligenz +LB:: +Leistungsbezüger +LE:: +Leistungserbringer +OE:: +Organisationseinheit (in der Regel ein Bundesamt) +OSI:: +Open Source Initiative +OSPO:: +Open Source Programme Office +OSS:: +Open-Source-Software +OSSD:: +Open-Source-Softwareentwicklung +SPDX:: +Software Package Data Exchange +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +AV:: +Applikationsverantwortliche bzw. Applikationsverantwortlicher +// end::abbr-em002[] diff --git a/docs/partials/abbreviations.en.adoc b/docs/partials/abbreviations.en.adoc new file mode 100644 index 0000000..89797b4 --- /dev/null +++ b/docs/partials/abbreviations.en.adoc @@ -0,0 +1,63 @@ +// The abbreviation list shared by Em002 and Em002-6. It was two hand-kept +// copies that had drifted: HERMES was italicised in one and upright in the +// other, OSSD was capitalised in one and not the other, and an organisational +// unit was "usually an office" in one and "usually a federal office" in the +// other. +// +// The English lists are identical, but the translations are not -- the two +// documents cite different things, and a translator picked a different +// abbreviation for the same concept (German AV vs AO, DVS vs DOEDS). So the +// entries are tagged per consuming document rather than included wholesale. +// The per-language entry counts differ on purpose; see TRANSLATING.adoc. +// +// `[horizontal]` stays in the including document, immediately before the +// include -- the block attribute carries across the include and across the +// leading tag comment, and leaving it here would double it up. +// +// A few entries are emitted twice, once per tag: the two documents sort them +// differently and no single order satisfies both. They collapse as soon as the +// source lists are alphabetised. +// tag::abbr-em002[] +// tag::abbr-em002-6[] +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 +// end::abbr-em002-6[] +// end::abbr-em002[] diff --git a/docs/partials/abbreviations.fr.adoc b/docs/partials/abbreviations.fr.adoc new file mode 100644 index 0000000..7874787 --- /dev/null +++ b/docs/partials/abbreviations.fr.adoc @@ -0,0 +1,87 @@ +// Voir abbreviations.en.adoc pour la justification de ce découpage. +// tag::abbr-em002[] +ANS:: +Administration numérique suisse (www.digital-public-services-switzerland.ch/strategy) +BP:: +Bénéficiaire de prestations +CG:: +Conditions générales +// end::abbr-em002[] +// tag::abbr-em002-6[] +AO:: +Application owner +CCMP:: +Centre de compétence des marchés publics de la Confédération +ChF:: +Chancellerie fédérale +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +CLA:: +Contributor Licence Agreement +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +CCMP:: +Centre de compétence des marchés publics de la Confédération +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +DCO:: +Developer Certificate of Origin +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +ANS:: +Administration numérique suisse (www.digital-public-services-switzerland.ch/strategy) +BP:: +Bénéficiaire de prestations +FP:: +Fournisseur de prestations +// end::abbr-em002-6[] +// tag::abbr-em002[] +FP:: +Fournisseur de prestations +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +FSF:: +Free Software Foundation +HERMES:: +_Handbuch der Elektronischen Rechenzentren des Bundes_, une méthode de développement de systèmes (www.hermes.admin.ch) +IA:: +Intelligence artificielle +LMETA:: +Loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités +LTrans:: +Loi sur la transparence +OFCL:: +Office fédéral des constructions et de la logistique +OSI:: +Open Source Initiative +OSPO:: +Open Source Programme Office +OSS:: +Logiciel open source +OSSD:: +Développement de logiciels open source +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +RA:: +Responsable de l'application +SPDX:: +Software Package Data Exchange +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +UO:: +Unité d'organisation (en règle générale un office fédéral) +USIC:: +Unité de pilotage informatique de la Confédération (jusqu'en 2021) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +SPDX:: +Software Package Data Exchange +// end::abbr-em002-6[] diff --git a/docs/partials/abbreviations.it.adoc b/docs/partials/abbreviations.it.adoc new file mode 100644 index 0000000..11ddb09 --- /dev/null +++ b/docs/partials/abbreviations.it.adoc @@ -0,0 +1,83 @@ +// Cfr. abbreviations.en.adoc per la motivazione di questa suddivisione. +// tag::abbr-em002[] +// tag::abbr-em002-6[] +ADS:: +Amministrazione digitale Svizzera (www.digital-public-services-switzerland.ch/strategy) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +BP:: +Beneficiario di prestazioni +// end::abbr-em002[] +// tag::abbr-em002[] +CG:: +Condizioni generali +// end::abbr-em002[] +// tag::abbr-em002-6[] +AO:: +Application owner +BP:: +Beneficiario di prestazioni +CaF:: +Cancelleria federale +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +CCAP:: +Centro di competenza per gli acquisti pubblici della Confederazione +CLA:: +Contributor Licence Agreement +DCO:: +Developer Certificate of Origin +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +FP:: +Fornitore di prestazioni +// end::abbr-em002-6[] +// tag::abbr-em002[] +FP:: +Fornitore di prestazioni +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +FSF:: +Free Software Foundation +HERMES:: +_Handbuch der Elektronischen Rechenzentren des Bundes_, un metodo per lo sviluppo di sistemi (www.hermes.admin.ch) +IA:: +Intelligenza artificiale +LMeCA:: +Legge federale concernente l'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità +LTras:: +Legge sulla trasparenza +ODIC:: +Organo direzione informatica della Confederazione (fino al 2021) +OSI:: +Open Source Initiative +OSPO:: +Open Source Programme Office +OSS:: +Software open source +OSSD:: +Sviluppo di software open source +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +RA:: +Responsabile dell'applicazione +SPDX:: +Software Package Data Exchange +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +UFCL:: +Ufficio federale delle costruzioni e della logistica +UO:: +Unità organizzativa (di regola un ufficio federale) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +SPDX:: +Software Package Data Exchange +// end::abbr-em002-6[] diff --git a/docs/partials/abbreviations.rm.adoc b/docs/partials/abbreviations.rm.adoc new file mode 100644 index 0000000..748bd59 --- /dev/null +++ b/docs/partials/abbreviations.rm.adoc @@ -0,0 +1,99 @@ +// Vesair abbreviations.en.adoc per la motivaziun da questa repartiziun. +// tag::abbr-em002[] +// tag::abbr-em002-6[] +ADS:: +Administraziun digitala Svizra (www.digital-public-services-switzerland.ch/strategy) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +AO:: +Application owner +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +CCA:: +Center da cumpetenza per l'acquist public da la Confederaziun +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +CGC:: +Cundiziuns generalas da contract +// end::abbr-em002[] +// tag::abbr-em002-6[] +ChF:: +Chanzlia federala +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +CLA:: +Contributor Licence Agreement +DCO:: +Developer Certificate of Origin +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +EMBAG:: +Lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +FSF:: +Free Software Foundation +HERMES:: +_Handbuch der Elektronischen Rechenzentren des Bundes_, ina metoda per il svilup da sistems (www.hermes.admin.ch) +IA:: +Intelligenza artifiziala +ISB:: +Organ da direcziun d'informatica da la Confederaziun (fin il 2021) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +LTr:: +Lescha davart la transparenza +// end::abbr-em002[] +// tag::abbr-em002-6[] +EMBAG:: +Lescha federala davart ils meds electronics per ademplir incumbensas d'autoritads +LTrans:: +Lescha davart la transparenza +PP:: +Purschider da prestaziuns +RP:: +Retratg da prestaziuns +// end::abbr-em002-6[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +OSI:: +Open Source Initiative +OSPO:: +Open Source Programme Office +OSS:: +Software open source +OSSD:: +Svilup da software open source +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002[] +PP:: +Purschider da prestaziuns +// end::abbr-em002[] +// tag::abbr-em002[] +RA:: +Responsabel da l'applicaziun +RP:: +Retratg da prestaziuns +SPDX:: +Software Package Data Exchange +// end::abbr-em002[] +// tag::abbr-em002[] +// tag::abbr-em002-6[] +UFCL:: +Uffizi federal per edifizis e logistica +UO:: +Unitad d'organisaziun (per ordinari in uffizi federal) +// end::abbr-em002-6[] +// end::abbr-em002[] +// tag::abbr-em002-6[] +SPDX:: +Software Package Data Exchange +// end::abbr-em002-6[] diff --git a/docs/partials/document-map.de.adoc b/docs/partials/document-map.de.adoc new file mode 100644 index 0000000..0444240 --- /dev/null +++ b/docs/partials/document-map.de.adoc @@ -0,0 +1,56 @@ +// Siehe document-map.en.adoc für die Begründung dieser Aufteilung. +[mermaid,align="center",alt="Übersicht über die OSS-Hilfsmittel im Zusammenhang mit Art. 9 EMBAG"] +.... +flowchart TD + subgraph FUND["Grundlagen (Sektor DTI)"] + EM0025["Em002-5
Merkblatt EMBAG
und OSS"] + EM002["Em002
Strategische
Leitlinien"] + EM0026["Em002-6
FAQ zu OSS und
Art. 9 EMBAG"] + end + + subgraph INTRO["Einführung und Anleitung (Sektor DTI)"] + EM0021["Em002-1
Praxis-
leitfaden"] + EM0023["Em002-3
Leitfaden
OSS-Lizenzierung"] + EM0027["Em002-7
Strategische Aspekte der
Beschaffung und OSS"] + end + + subgraph PUB["Hilfsmittel Veröffentlichung (Sektor DTI)"] + EM0022["Em002-2
Anleitung zur Ver-
öffentlichung von OSS"] + EM0024["Em002-4
Leitfaden
OSS-Community"] + CL21["Em002-2.1
Checkliste
OSS-
Vorabklärung"] + CL22["Em002-2.2
Checkliste
OSS-Analyse und
-Vorbereitung"] + CL23["Em002-2.3
Checkliste
OSS-Freigabe und
-Veröffentlichung"] + CL41["Em002-4.1
Checkliste
OSS-Community"] + end + + subgraph PROC["Hilfsmittel Beschaffung (BBL)"] + KBB["Merkblatt KBB
Beschaffung von Software
und Art. 9 EMBAG"] + ORI["Orientierung
Open Source und
Beschaffung"] + CLEX["Checkliste
Generelle Ausnahme
Art. 9 EMBAG"] + end + + HERMES["www.HERMES.admin.ch"] + FCHOSS["Internet:
OSS-Hilfsmittel
Bundeskanzlei"] + + EM002 --> EM0021 + EM0021 --> EM0023 + EM0021 --> EM0022 + EM0022 --> EM0024 + EM0022 --> CL21 + CL21 --> CL22 + CL22 --> CL23 + EM0024 --> CL41 + ORI --> CLEX + HERMES -->|"Referenz"| FCHOSS + + classDef fund fill:#f0f0f0,stroke:#000000,color:#000000 + classDef intro fill:#dae8fc,stroke:#000000,color:#000000 + classDef pub fill:#e1d5e7,stroke:#000000,color:#000000 + classDef check fill:#d5e8d4,stroke:#000000,color:#000000 + classDef proc fill:#f8cecc,stroke:#000000,color:#000000 + class EM002,EM0025,EM0026 fund + class EM0021,EM0023 intro + class EM0022,EM0024 pub + class CL21,CL22,CL23,CL41 check + class EM0027,KBB,ORI,CLEX proc +.... diff --git a/docs/partials/document-map.en.adoc b/docs/partials/document-map.en.adoc new file mode 100644 index 0000000..0d521c1 --- /dev/null +++ b/docs/partials/document-map.en.adoc @@ -0,0 +1,82 @@ +// The map of Art. 9 EMOTA documents, shared by Em002, Em002-1, Em002-5 and +// Em002-7. It lived as a PNG in three copies that had already drifted apart -- +// they disagreed about the checklist file format and about the whole right-hand +// column -- which is why it is one file per language now. The caption and its +// figure number stay in the including document, because the number differs per +// document and Em002 includes the map twice. +// +// Categories are carried by the subgraph names as well as the fills, so the +// diagram needs no colour key: a reader who cannot tell the fills apart still +// knows which group each document is in. +// +// The original's second key was shape, not colour: square corners meant the DTI +// sector was responsible, rounded corners the FOBL. That is what the "(DTI +// sector)" and "(FOBL)" halves of the group names carry. +// +// Em002-7 is therefore grouped with the guidance documents, which is the band +// the original draws it in, and keeps the red procurement fill the original +// gives it. Colour is its subject, the group is who answers for it; putting it +// in the FOBL group said both at once, and got the second one wrong. +// +// Titles are the short form on purpose. The full ones are in the prose around +// every inclusion, and a four-line node label makes the graph wider than the A4 +// content box. +// +// Do not add a `theme`, `themeVariables` or an `%%{init}%%` directive -- the +// palette comes from the document's own tokens. `classDef` is not a theme +// override and is fine. +[mermaid,align="center",alt="Overview of the OSS tools in connection with Art. 9 EMOTA"] +.... +flowchart TD + subgraph FUND["Fundamentals (DTI sector)"] + EM0025["Em002-5
EMOTA and OSS
Factsheet"] + EM002["Em002
Strategic
Guidelines"] + EM0026["Em002-6
FAQ on OSS and
Art. 9 EMOTA"] + end + + subgraph INTRO["Introduction and guidance (DTI sector)"] + EM0021["Em002-1
Practical
Guidelines"] + EM0023["Em002-3
OSS Licensing
Guidelines"] + EM0027["Em002-7
Strategic Aspects of
Procurement and OSS"] + end + + subgraph PUB["Publication tools (DTI sector)"] + EM0022["Em002-2
Instructions for
Publishing OSS"] + EM0024["Em002-4
OSS Community
Guidelines"] + CL21["Em002-2.1
Preliminary
Assessment
Checklist"] + CL22["Em002-2.2
Analysis and
Preparation
Checklist"] + CL23["Em002-2.3
Release and
Publication
Checklist"] + CL41["Em002-4.1
OSS Community
Checklist"] + end + + subgraph PROC["Procurement tools (FOBL)"] + KBB["Factsheet CCPP
Procurement of Software
and Art. 9 EMOTA"] + ORI["Orientation
Open Source and
Procurement"] + CLEX["Checklist
General Exception
Art. 9 EMOTA"] + end + + HERMES["www.HERMES.admin.ch"] + FCHOSS["Internet:
OSS tools
Federal Chancellery"] + + EM002 --> EM0021 + EM0021 --> EM0023 + EM0021 --> EM0022 + EM0022 --> EM0024 + EM0022 --> CL21 + CL21 --> CL22 + CL22 --> CL23 + EM0024 --> CL41 + ORI --> CLEX + HERMES -->|"reference"| FCHOSS + + classDef fund fill:#f0f0f0,stroke:#000000,color:#000000 + classDef intro fill:#dae8fc,stroke:#000000,color:#000000 + classDef pub fill:#e1d5e7,stroke:#000000,color:#000000 + classDef check fill:#d5e8d4,stroke:#000000,color:#000000 + classDef proc fill:#f8cecc,stroke:#000000,color:#000000 + class EM002,EM0025,EM0026 fund + class EM0021,EM0023 intro + class EM0022,EM0024 pub + class CL21,CL22,CL23,CL41 check + class EM0027,KBB,ORI,CLEX proc +.... diff --git a/docs/partials/document-map.fr.adoc b/docs/partials/document-map.fr.adoc new file mode 100644 index 0000000..3cb6433 --- /dev/null +++ b/docs/partials/document-map.fr.adoc @@ -0,0 +1,56 @@ +// Voir document-map.en.adoc pour la justification de ce découpage. +[mermaid,align="center",alt="Vue d'ensemble des outils OSS en lien avec l'art. 9 LMETA"] +.... +flowchart TD + subgraph FUND["Bases (secteur TNI)"] + EM0025["Em002-5
Aide-mémoire
LMETA et OSS"] + EM002["Em002
Lignes directrices
stratégiques"] + EM0026["Em002-6
FAQ sur les OSS et
l'art. 9 LMETA"] + end + + subgraph INTRO["Introduction et orientation (secteur TNI)"] + EM0021["Em002-1
Guide
pratique"] + EM0023["Em002-3
Guide de
licences OSS"] + EM0027["Em002-7
Aspects stratégiques des
achats et de l'OSS"] + end + + subgraph PUB["Outils de publication (secteur TNI)"] + EM0022["Em002-2
Instructions pour la
publication d'OSS"] + EM0024["Em002-4
Guide des
communautés OSS"] + CL21["Em002-2.1
Liste de contrôle
Évaluation
préalable OSS"] + CL22["Em002-2.2
Liste de contrôle
Analyse et
préparation OSS"] + CL23["Em002-2.3
Liste de contrôle
Validation et
publication OSS"] + CL41["Em002-4.1
Liste de contrôle
Communauté OSS"] + end + + subgraph PROC["Outils d'acquisition (OFCL)"] + KBB["Aide-mémoire CCMP
Acquisition de logiciels
et art. 9 LMETA"] + ORI["Orientation
Open source et
acquisitions"] + CLEX["Liste de contrôle
Exception générale
art. 9 LMETA"] + end + + HERMES["www.HERMES.admin.ch"] + FCHOSS["Internet :
outils OSS
Chancellerie fédérale"] + + EM002 --> EM0021 + EM0021 --> EM0023 + EM0021 --> EM0022 + EM0022 --> EM0024 + EM0022 --> CL21 + CL21 --> CL22 + CL22 --> CL23 + EM0024 --> CL41 + ORI --> CLEX + HERMES -->|"référence"| FCHOSS + + classDef fund fill:#f0f0f0,stroke:#000000,color:#000000 + classDef intro fill:#dae8fc,stroke:#000000,color:#000000 + classDef pub fill:#e1d5e7,stroke:#000000,color:#000000 + classDef check fill:#d5e8d4,stroke:#000000,color:#000000 + classDef proc fill:#f8cecc,stroke:#000000,color:#000000 + class EM002,EM0025,EM0026 fund + class EM0021,EM0023 intro + class EM0022,EM0024 pub + class CL21,CL22,CL23,CL41 check + class EM0027,KBB,ORI,CLEX proc +.... diff --git a/docs/partials/document-map.it.adoc b/docs/partials/document-map.it.adoc new file mode 100644 index 0000000..288b8ee --- /dev/null +++ b/docs/partials/document-map.it.adoc @@ -0,0 +1,56 @@ +// Cfr. document-map.en.adoc per la motivazione di questa suddivisione. +[mermaid,align="center",alt="Panoramica degli strumenti OSS in relazione all'art. 9 LMeCA"] +.... +flowchart TD + subgraph FUND["Basi (settore TDT)"] + EM0025["Em002-5
Promemoria
LMeCA e OSS"] + EM002["Em002
Linee guida
strategiche"] + EM0026["Em002-6
FAQ su OSS e
art. 9 LMeCA"] + end + + subgraph INTRO["Introduzione e guida (settore TDT)"] + EM0021["Em002-1
Guida
pratica"] + EM0023["Em002-3
Guida alle
licenze OSS"] + EM0027["Em002-7
Aspetti strategici degli
acquisti e dell'OSS"] + end + + subgraph PUB["Strumenti di pubblicazione (settore TDT)"] + EM0022["Em002-2
Istruzioni per la
pubblicazione di OSS"] + EM0024["Em002-4
Guida alle
community OSS"] + CL21["Em002-2.1
Lista di controllo
Valutazione
preliminare OSS"] + CL22["Em002-2.2
Lista di controllo
Analisi e
preparazione OSS"] + CL23["Em002-2.3
Lista di controllo
Rilascio e
pubblicazione OSS"] + CL41["Em002-4.1
Lista di controllo
Community OSS"] + end + + subgraph PROC["Strumenti d'acquisto (UFCL)"] + KBB["Promemoria CCAP
Acquisto di software
e art. 9 LMeCA"] + ORI["Orientamento
Open source e
acquisti"] + CLEX["Lista di controllo
Eccezione generale
art. 9 LMeCA"] + end + + HERMES["www.HERMES.admin.ch"] + FCHOSS["Internet:
strumenti OSS
Cancelleria federale"] + + EM002 --> EM0021 + EM0021 --> EM0023 + EM0021 --> EM0022 + EM0022 --> EM0024 + EM0022 --> CL21 + CL21 --> CL22 + CL22 --> CL23 + EM0024 --> CL41 + ORI --> CLEX + HERMES -->|"riferimento"| FCHOSS + + classDef fund fill:#f0f0f0,stroke:#000000,color:#000000 + classDef intro fill:#dae8fc,stroke:#000000,color:#000000 + classDef pub fill:#e1d5e7,stroke:#000000,color:#000000 + classDef check fill:#d5e8d4,stroke:#000000,color:#000000 + classDef proc fill:#f8cecc,stroke:#000000,color:#000000 + class EM002,EM0025,EM0026 fund + class EM0021,EM0023 intro + class EM0022,EM0024 pub + class CL21,CL22,CL23,CL41 check + class EM0027,KBB,ORI,CLEX proc +.... diff --git a/docs/partials/document-map.rm.adoc b/docs/partials/document-map.rm.adoc new file mode 100644 index 0000000..fd1418f --- /dev/null +++ b/docs/partials/document-map.rm.adoc @@ -0,0 +1,56 @@ +// Vesair document-map.en.adoc per la motivaziun da questa repartiziun. +[mermaid,align="center",alt="Survista dals meds OSS en connex cun l'art. 9 EMBAG"] +.... +flowchart TD + subgraph FUND["Basas (sectur TDT)"] + EM0025["Em002-5
Fegl d'infurmaziun
EMBAG ed OSS"] + EM002["Em002
Directivas
strategicas"] + EM0026["Em002-6
FAQ davart OSS
e l'art. 9 EMBAG"] + end + + subgraph INTRO["Introducziun e guida (sectur TDT)"] + EM0021["Em002-1
Guida
pratica"] + EM0023["Em002-3
Guida da
licenzas OSS"] + EM0027["Em002-7
Aspects strategics da
l'acquist e da l'OSS"] + end + + subgraph PUB["Meds da publicaziun (sectur TDT)"] + EM0022["Em002-2
Instrucziuns per
publitgar OSS"] + EM0024["Em002-4
Guida da
communitads OSS"] + CL21["Em002-2.1
Glista da controlla
Evaluaziun
preliminara OSS"] + CL22["Em002-2.2
Glista da controlla
Analisa e
preparaziun OSS"] + CL23["Em002-2.3
Glista da controlla
Relaschada e
publicaziun OSS"] + CL41["Em002-4.1
Glista da controlla
Communitad OSS"] + end + + subgraph PROC["Meds d'acquist (UFCL)"] + KBB["Fegl d'infurmaziun CCA
Acquist da software
e l'art. 9 EMBAG"] + ORI["Orientaziun
Open source ed
acquist"] + CLEX["Glista da controlla
Excepziun generala
art. 9 EMBAG"] + end + + HERMES["www.HERMES.admin.ch"] + FCHOSS["Internet:
meds OSS
Chanzlia federala"] + + EM002 --> EM0021 + EM0021 --> EM0023 + EM0021 --> EM0022 + EM0022 --> EM0024 + EM0022 --> CL21 + CL21 --> CL22 + CL22 --> CL23 + EM0024 --> CL41 + ORI --> CLEX + HERMES -->|"referenza"| FCHOSS + + classDef fund fill:#f0f0f0,stroke:#000000,color:#000000 + classDef intro fill:#dae8fc,stroke:#000000,color:#000000 + classDef pub fill:#e1d5e7,stroke:#000000,color:#000000 + classDef check fill:#d5e8d4,stroke:#000000,color:#000000 + classDef proc fill:#f8cecc,stroke:#000000,color:#000000 + class EM002,EM0025,EM0026 fund + class EM0021,EM0023 intro + class EM0022,EM0024 pub + class CL21,CL22,CL23,CL41 check + class EM0027,KBB,ORI,CLEX proc +.... diff --git a/docs/partials/glossary.de.adoc b/docs/partials/glossary.de.adoc new file mode 100644 index 0000000..7199154 --- /dev/null +++ b/docs/partials/glossary.de.adoc @@ -0,0 +1,123 @@ +// Siehe glossary.en.adoc für die Begründung dieser Aufteilung. +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Anwendungsbereich:: +Gemeint sind die Kategorien der Büroautomationssoftware (BA) nach [A029] und weitere Klassifizierungen. + +Branch:: +Ein Entwicklungszweig einer OSS. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Kollaboration:: +Der Begriff «Kollaboration» leitet sich vom lateinischen Wort «collaborare» ab, das «zusammenarbeiten» bedeutet. + +Er beschreibt eine Arbeitsweise, bei der mehrere Personen oder Teams gemeinsam auf ein Ziel hinarbeiten und dabei ihre Fähigkeiten und Ressourcen einbringen. Im Zentrum stehen gegenseitiger Austausch, Transparenz und das Teilen von Wissen. + +Nach dem Gabler Wirtschaftslexikon bezeichnet Kollaboration auch die «Zusammenarbeit eines Unternehmens mit seinen Kunden und Lieferanten unter Nutzung moderner Informationstechnologien zur Integration inner- und überbetrieblicher Geschäftsprozesse». + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +KBB:: +Kompetenzzentrum Beschaffungswesen Bund + +Collaboration:: +Der Begriff Collaboration stammt vom lateinischen Wort «collaborare» und bedeutet «zusammenarbeiten». +Er beschreibt eine Arbeitsweise, bei der mehrere Personen oder Teams gemeinsam auf ein Ziel hinarbeiten und ihre Fähigkeiten und Ressourcen einbringen. Im Zentrum stehen gegenseitiger Austausch, Transparenz und das Teilen von Wissen. + +Gemäss dem Gabler Wirtschaftslexikon bezeichnet Collaboration auch die «Zusammenarbeit zwischen einem Unternehmen und seinen Kunden und Lieferanten unter Einsatz moderner Informationstechnologien zur Integration inner- und überbetrieblicher Geschäftsprozesse». + +Committer:: +Ein Committer ist eine Person, die eine Änderung an Daten in einem Versionsverwaltungssystem einträgt. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Contribution:: +Eine OSS-Contribution ist ein Beitrag zur Entwicklung und Verbesserung von Open-Source-Software (OSS). Dies kann in Form von Code, Dokumentation, Tests, Rückmeldungen oder anderen Beitragsarten geschehen. (Google AI) + +Contributor Licence Agreement (CLA):: +Ein Contributor Licence Agreement (CLA), auch Contributor Agreement genannt, ist ein Dokument, das die Bedingungen festlegt, unter denen geistiges Eigentum zu einem Projekt oder einer Initiative beigetragen werden darf. Damit ist in der Regel ein Softwareprojekt unter einer Open-Source-Lizenz gemeint (Wikipedia). + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Core Developer:: +Entwicklerin oder Entwickler eines OSS-Projekts mit Committer-Zugriffsrechten auf das Repositorium. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +DTI:: +Sektor Digitale Transformation und IKT-Lenkung. Teil der Bundeskanzlei BK + +eOperations:: +eOperations Schweiz ermöglicht gemeinsame digitale öffentliche Dienstleistungen für Bund, Kantone und Gemeinden. https://www.eoperations.ch[www.eoperations.ch] + +ISB:: +Informatiksteuerungsorgan des Bundes. Vorgänger von BK-DTI + +BBL:: +Bundesamt für Bauten und Logistik + +Lebenszyklus:: +Ein Softwarelebenszyklus beschreibt den Prozess der Softwareentwicklung mit dem Ziel, dem Kunden Software bereitzustellen. In der Regel beginnt der Zyklus mit einem vom Kunden erkannten Problem und dessen Analyse und endet auf Kundenseite mit der Ablösung der Software durch eine Nachfolgelösung. + +Lock-in:: +Der Lock-in-Effekt bezeichnet eine enge Kundenbindung an Produkte/Dienstleistungen oder an einen Anbieter, die einen Produkt- oder Anbieterwechsel für die Kundschaft aufgrund der damit verbundenen Kosten und weiterer Hürden erschwert. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Marktanalyse:: +Eine spezifische Marktanalyse dient dazu, Informationen zum aktuellen und potenziellen Beschaffungsmarkt zu ermitteln und aufzubereiten. Zweck der Marktanalyse ist es, Marktstrukturen und insbesondere die Anbieterstruktur hinsichtlich aller massgebenden Merkmale zu ermitteln und zu verstehen: Preissituation (hoch, tief, Schwankungen); Marktgrösse; geografische Verteilung potenzieller Anbieter und Hauptakteure usw. (siehe https://perimap.admin.ch/goto_perimap_file_38221_download.html). + +Mögliche Quellen für OSS-Software finden sich in link:em002-1.pdf[Em002-1 Praxisleitfaden OSS] in Kapitel 7. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +OSS:: +Open-Source-Software + +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Produkt:: +Hier als Synonym für «Anwendung» verwendet. ++ +Der Begriff stammt aus ITIL. In ITIL (Information Technology Infrastructure Library) ist ein Produkt eine Konfiguration von Ressourcen, die darauf ausgelegt ist, einer Kundin oder einer Organisation Nutzen zu stiften. Anders als ein Service, der typischerweise ein laufender, interaktiver Prozess ist, ist ein Produkt eine statische Einheit. ++ +Produkte können Software, Hardware, Daten oder andere von der Organisation bereitgestellte Ressourcen sein. (Google AI) + +Produktstandardisierung:: +In diesem Dokument bezieht sich die Standardisierung in erster Linie auf SD120, den IKT-Standarddienst für die Büroautomation, sowie auf weitere Standardisierungen durch DTI. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Subscription:: +Beim Bezug von Software im Abonnement wird eine Subscription abgeschlossen. Das bedeutet, dass die Software nicht gekauft wird. + +In den meisten Fällen umfasst dies nicht nur die Erlaubnis zur Nutzung der Software, sondern auch alle relevanten Dienstleistungen und den Support. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +SBOM:: +Eine Software Bill of Materials (SBOM) ist eine Inventarliste aller Komponenten und Softwareabhängigkeiten, die Teil der Entwicklung und Bereitstellung einer Software sind. + +Subskription:: +Beim Abonnieren von Software wird eine Subskription abgeschlossen. Das bedeutet, dass die Software nicht gekauft wird. + +In den meisten Fällen umfasst dies nicht nur die Erlaubnis zur Nutzung der Software, sondern auch alle massgebenden Leistungen und den Support. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Upstream-Projekt:: +Upstream ist ein Begriff aus der verteilten Softwareentwicklung (oft Open Source) und bezeichnet die Richtung eines Patches zu seinem Ursprung (upstream), also zu den ursprünglichen Entwicklerinnen und Entwicklern bzw. Maintainern der Software oder zum ursprünglichen Projekt. Dabei kann es sich auch um Softwarebibliotheken handeln. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +ZenDiS:: +ZenDiS ist eine Gesellschaft mit beschränkter Haftung (GmbH) in öffentlicher Hand in Deutschland. Sie unterstützt Bund, Länder und Kommunen bei der Umsetzung der digitalen Souveränität. Mit opencode.de und container.gov.de bietet sie eine Plattform für sichere Open-Source-Entwicklung. (https://www.zendis.de[www.zendis.de]) + +Zero-Day-Exploit:: +Ein Zero-Day-Exploit bezeichnet die Ausnutzung einer Sicherheitslücke, für die noch kein Patch des Komponentenherstellers verfügbar ist. + +// end::gloss-em002-7[] diff --git a/docs/partials/glossary.en.adoc b/docs/partials/glossary.en.adoc new file mode 100644 index 0000000..18dfc6f --- /dev/null +++ b/docs/partials/glossary.en.adoc @@ -0,0 +1,131 @@ +// The glossary shared by Em002-6 and Em002-7. Em002-6 owns the general +// glossary -- Em002-7 says so in its own Annex B preamble -- and Em002-7 adds +// the procurement-specific terms on top, so the union is tagged per consuming +// document and Em002-6's wording wins wherever the two had drifted. +// +// Drift found: "Application area", "Branch", "Collaboration", "Market +// analysis" and "Product" disagreed in English, and rather more in the +// translations, mostly over hard breaks and list continuations. +// +// Where the two documents use different headwords for the same concept +// (German Kollaboration vs Collaboration, Subscription vs Subskription, and +// their French, Italian and Romansh equivalents), both entries survive, one +// per tag. Unifying them is a translation decision, not a formatting one. +// +// The preamble paragraphs -- the TERMDAT pointer and Em002-7's "see Em002-6" +// note -- stay in the including documents; they differ per document. +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +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. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +CCPP:: +Competence Centre for Federal Public Procurement + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +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.' + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +Committer:: +A committer is a person who enters a change to data in a version control system. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +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). + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Core developer:: +Developer of an OSS project who has committer access rights to the repository. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +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.eoperations.ch[www.eoperations.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. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +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.pdf[Em002-1 Practical Guidelines for OSS] in Section 7. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +OSS:: +Open source software + +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +// tag::gloss-em002-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. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +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. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +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. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +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 opencode.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. + +// end::gloss-em002-7[] diff --git a/docs/partials/glossary.fr.adoc b/docs/partials/glossary.fr.adoc new file mode 100644 index 0000000..8b27e52 --- /dev/null +++ b/docs/partials/glossary.fr.adoc @@ -0,0 +1,127 @@ +// Voir glossary.en.adoc pour la justification de ce découpage. +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Domaine d'application:: +Il s'agit des catégories de logiciels de bureautique (BA) telles que définies dans [A029] et d'autres classifications. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Branche:: +Une branche de développement d'un logiciel open source. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +Branch:: +Une branche de développement d'un OSS. + +CCMP:: +Centre de compétence des marchés publics de la Confédération + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Collaboration:: +Le terme «collaboration» dérive du mot latin «collaborare», qui signifie «travailler ensemble». + +Il décrit un mode de travail dans lequel plusieurs personnes ou équipes œuvrent ensemble à un objectif commun en y apportant leurs compétences et leurs ressources. L'échange mutuel, la transparence et le partage des connaissances sont au centre. + +Selon le Gabler Wirtschaftslexikon, la collaboration désigne aussi la «coopération d'une entreprise avec ses clients et ses fournisseurs, en recourant aux technologies modernes de l'information pour intégrer les processus d'affaires internes et interentreprises». + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +Committer:: +Un committer est une personne qui inscrit une modification de données dans un système de gestion de versions. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Contribution:: +Une contribution OSS est un apport au développement et à l'amélioration d'un logiciel open source (OSS). Cela peut prendre la forme de code, de documentation, de tests, de retours ou d'autres types de contributions. (Google AI) + +Contributor Licence Agreement (CLA):: +Un Contributor Licence Agreement (CLA), également appelé Contributor Agreement, est un document qui fixe les conditions auxquelles de la propriété intellectuelle peut être apportée à un projet ou à une initiative. Il s'agit généralement d'un projet logiciel sous licence open source (Wikipédia). + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Core developer:: +Développeur d'un projet open source disposant de droits d'accès de committer au dépôt. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +TNI:: +Secteur Transformation numérique et gouvernance de l'informatique. Fait partie de la Chancellerie fédérale ChF + +eOperations:: +eOperations Suisse permet des prestations publiques numériques communes pour la Confédération, les cantons et les communes. https://www.eoperations.ch[www.eoperations.ch] + +USIC:: +Unité de pilotage informatique de la Confédération. Prédécesseur de ChF-TNI + +OFCL:: +Office fédéral des constructions et de la logistique + +Cycle de vie:: +Un cycle de vie logiciel décrit le processus de développement logiciel visant à mettre un logiciel à disposition du client. En règle générale, le cycle commence par un problème identifié par le client et son analyse, et se termine du côté du client par le remplacement du logiciel par un successeur. + +Lock-in:: +L'effet de lock-in désigne une fidélisation étroite de la clientèle à des produits/services ou à un fournisseur, qui rend difficile pour le client un changement de produit ou de fournisseur en raison des coûts et des autres obstacles liés au changement. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Analyse de marché:: +Une analyse de marché spécifique sert à identifier et à traiter les informations relatives au marché d'acquisition actuel et potentiel. L'analyse de marché a pour but d'identifier et de comprendre les structures du marché et, en particulier, la structure des fournisseurs au regard de toutes les caractéristiques déterminantes : situation des prix (élevés, bas, fluctuations) ; taille du marché ; répartition géographique des fournisseurs potentiels et des acteurs principaux, etc. (voir https://perimap.admin.ch/goto_perimap_file_38221_download.html). + +Les sources possibles de logiciels OSS figurent dans link:em002-1.pdf[Em002-1 Guide pratique OSS], chapitre 7. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +OSS:: +Logiciel open source + +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Produit:: +Utilisé ici comme synonyme d'«application». ++ +Le terme provient d'ITIL. Dans ITIL (Information Technology Infrastructure Library), un produit est une configuration de ressources conçue pour apporter de la valeur à un client ou à une organisation. Contrairement à un service, qui est typiquement un processus interactif et continu, un produit est une entité statique. ++ +Les produits peuvent être des logiciels, du matériel, des données ou d'autres ressources fournies par l'organisation. (Google AI) + +Standardisation des produits:: +Dans le présent document, la standardisation se réfère principalement à SD120, le service standard TIC pour la bureautique, ainsi qu'à d'autres standardisations du secteur TNI. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Subscription:: +Lors de l'acquisition d'un logiciel par abonnement, une subscription est conclue. Cela signifie que le logiciel n'est pas acheté. + +Dans la plupart des cas, cela comprend non seulement l'autorisation d'utiliser le logiciel, mais aussi l'ensemble des prestations et du support pertinents. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +SBOM:: +Une Software Bill of Materials (SBOM) est une liste d'inventaire de tous les composants et dépendances logicielles qui font partie du développement et du déploiement d'un logiciel. + +Abonnement:: +Lors de l'abonnement à un logiciel, une souscription est conclue. Cela signifie que le logiciel n'est pas acheté. + +Dans la plupart des cas, cela comprend non seulement l'autorisation d'utiliser le logiciel, mais aussi toutes les prestations déterminantes et le support. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Projet upstream:: +Upstream est un terme issu du développement logiciel distribué (souvent open source) et désigne la direction d'un correctif vers son origine (upstream), c'est-à-dire vers les développeurs ou mainteneurs d'origine du logiciel, ou vers le projet d'origine. Il peut aussi s'agir de bibliothèques logicielles. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +ZenDiS:: +ZenDiS est une société à responsabilité limitée (GmbH) en mains publiques en Allemagne. Elle soutient la Fédération, les Länder et les communes dans la mise en œuvre de la souveraineté numérique. Avec opencode.de et container.gov.de, elle offre une plateforme pour un développement open source sécurisé. (https://www.zendis.de[www.zendis.de]) + +Exploit zero-day:: +Un exploit zero-day désigne l'exploitation d'une faille de sécurité pour laquelle aucun correctif n'est encore disponible auprès du fabricant du composant. + +// end::gloss-em002-7[] diff --git a/docs/partials/glossary.it.adoc b/docs/partials/glossary.it.adoc new file mode 100644 index 0000000..6591e64 --- /dev/null +++ b/docs/partials/glossary.it.adoc @@ -0,0 +1,130 @@ +// Cfr. glossary.en.adoc per la motivazione di questa suddivisione. +// tag::gloss-em002-6[] +Ambito di applicazione:: +Si intendono le categorie di software per l'automazione d'ufficio (BA) secondo [A029] e altre classificazioni. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +Ambito d'applicazione:: +Si intendono le categorie di software di automazione d'ufficio secondo [A029] e altre classificazioni. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Branch:: +Un ramo di sviluppo di un OSS. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Collaborazione:: +Il termine «collaborazione» deriva dalla parola latina «collaborare», che significa «lavorare insieme». + +Descrive un modo di lavorare in cui più persone o team operano insieme verso un obiettivo comune, apportando le proprie competenze e risorse. Al centro vi sono lo scambio reciproco, la trasparenza e la condivisione delle conoscenze. + +Secondo il Gabler Wirtschaftslexikon, la collaborazione indica anche la «cooperazione di un'impresa con i suoi clienti e fornitori, ricorrendo alle moderne tecnologie dell'informazione per integrare i processi aziendali interni e interaziendali». + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +CCAP:: +Centro di competenza per gli acquisti pubblici della Confederazione + +Collaboration:: +Il termine collaboration deriva dal latino «collaborare» e significa «lavorare insieme». +Descrive un modo di lavorare in cui più persone o team operano insieme verso un obiettivo comune, apportando le proprie capacità e risorse. Al centro figurano lo scambio reciproco, la trasparenza e la condivisione delle conoscenze. + +Secondo il Gabler Wirtschaftslexikon, collaboration designa anche la «cooperazione tra un'impresa e i suoi clienti e fornitori, ricorrendo alle moderne tecnologie dell'informazione per integrare i processi aziendali interni e interaziendali». + +Committer:: +Un committer è una persona che inserisce una modifica dei dati in un sistema di gestione delle versioni. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Contribution:: +Una contribution OSS è un contributo allo sviluppo e al miglioramento di software open source (OSS). Ciò può avvenire sotto forma di codice, documentazione, test, riscontri o altri tipi di contributi. (Google AI) + +Contributor Licence Agreement (CLA):: +Un Contributor Licence Agreement (CLA), noto anche come Contributor Agreement, è un documento che stabilisce le condizioni alle quali la proprietà intellettuale può essere apportata a un progetto o a un'iniziativa. Di regola si tratta di un progetto software sotto licenza open source (Wikipedia). + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Core developer:: +Sviluppatore di un progetto open source che dispone di diritti di accesso come committer al repository. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +TDI:: +Settore Trasformazione digitale e governance delle TIC. Parte della Cancelleria federale CaF + +eOperations:: +eOperations Svizzera consente prestazioni pubbliche digitali comuni per Confederazione, Cantoni e Comuni. https://www.eoperations.ch[www.eoperations.ch] + +ODIC:: +Organo direzione informatica della Confederazione. Predecessore di CaF-TDI + +UFCL:: +Ufficio federale delle costruzioni e della logistica + +Ciclo di vita:: +Un ciclo di vita del software descrive il processo di sviluppo software volto a mettere un software a disposizione del cliente. Di regola il ciclo inizia con un problema individuato dal cliente e la sua analisi e termina, dal lato del cliente, con la sostituzione del software con uno successivo. + +Lock-in:: +L'effetto lock-in designa uno stretto legame della clientela a prodotti/servizi o a un fornitore, che rende difficile al cliente cambiare prodotto o fornitore a causa dei costi e di altri ostacoli connessi al cambiamento. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Analisi di mercato:: +Un'analisi di mercato specifica serve a individuare ed elaborare informazioni sul mercato d'acquisto attuale e potenziale. Scopo dell'analisi di mercato è individuare e comprendere le strutture di mercato e in particolare la struttura dei fornitori riguardo a tutte le caratteristiche determinanti: situazione dei prezzi (alti, bassi, oscillazioni); dimensione del mercato; distribuzione geografica dei potenziali fornitori e degli attori principali ecc. (cfr. https://perimap.admin.ch/goto_perimap_file_38221_download.html). + +Possibili fonti di software OSS figurano in link:em002-1.pdf[Em002-1 Guida pratica OSS], capitolo 7. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +OSS:: +Software open source + +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Prodotto:: +Qui utilizzato come sinonimo di «applicazione». ++ +Il termine deriva da ITIL. In ITIL (Information Technology Infrastructure Library) un prodotto è una configurazione di risorse concepita per generare valore per un cliente o un'organizzazione. A differenza di un servizio, che è tipicamente un processo continuo e interattivo, un prodotto è un'entità statica. ++ +I prodotti possono essere software, hardware, dati o altre risorse messe a disposizione dall'organizzazione. (Google AI) + +Standardizzazione dei prodotti:: +Nel presente documento la standardizzazione si riferisce in primo luogo a SD120, il servizio standard TIC per l'automazione d'ufficio, nonché ad altre standardizzazioni del settore TDT. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Subscription:: +Acquisendo software in abbonamento si stipula una subscription. Ciò significa che il software non viene acquistato. + +Nella maggior parte dei casi ciò comprende non solo l'autorizzazione a utilizzare il software, ma anche tutte le prestazioni e il supporto pertinenti. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +SBOM:: +Una Software Bill of Materials (SBOM) è un elenco d'inventario di tutti i componenti e le dipendenze software che fanno parte dello sviluppo e della distribuzione di un software. + +Abbonamento:: +Abbonandosi a un software si sottoscrive una subscription. Ciò significa che il software non viene acquistato. + +Nella maggior parte dei casi ciò comprende non soltanto l'autorizzazione a utilizzare il software, ma anche tutte le prestazioni determinanti e il supporto. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Progetto upstream:: +Upstream è un termine dello sviluppo software distribuito (spesso open source) e indica la direzione di una patch verso la sua origine (upstream), ossia verso gli sviluppatori o i maintainer originari del software o verso il progetto originario. Può trattarsi anche di librerie software. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +ZenDiS:: +ZenDiS è una società a garanzia limitata (GmbH) in mano pubblica in Germania. Sostiene la Federazione, i Länder e i Comuni nell'attuazione della sovranità digitale. Con opencode.de e container.gov.de offre una piattaforma per uno sviluppo open source sicuro. (https://www.zendis.de[www.zendis.de]) + +Exploit zero-day:: +Un exploit zero-day designa lo sfruttamento di una falla di sicurezza per la quale non è ancora disponibile alcuna patch del fabbricante del componente. + +// end::gloss-em002-7[] diff --git a/docs/partials/glossary.rm.adoc b/docs/partials/glossary.rm.adoc new file mode 100644 index 0000000..72904c7 --- /dev/null +++ b/docs/partials/glossary.rm.adoc @@ -0,0 +1,126 @@ +// Vesair glossary.en.adoc per la motivaziun da questa repartiziun. +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Sectur d'applicaziun:: +Manegiadas èn las categorias dal software d'automatisaziun da biro (BA) tenor [A029] ed ulteriuras classificaziuns. + +Branch:: +Ina branca da svilup d'in OSS. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Collavuraziun:: +La noziun «collavuraziun» deriva dal pled latin «collaborare» che munta «lavurar ensemen». + +Ella descriva ina moda da lavurar, en la quala pliras persunas u teams lavuran ensemen vers ina finamira cuminaivla ed integreschan lur abilitads e resursas. En il center stattan il barat vicendaivel, la transparenza ed il cundivider da savida. + +Tenor il Gabler Wirtschaftslexikon designescha collavuraziun era la «collavuraziun d'ina interpresa cun ses clients e furniturs, cun utilisar modernas tecnologias d'infurmaziun per integrar process da fatschenta interns ed interinterpresarials». + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +CCA:: +Center da cumpetenza per l'acquist public da la Confederaziun + +Collaboration:: +Il term collaboration deriva dal latin «collaborare» e munta «lavurar ensemen». +El descriva ina moda da lavurar, tar la quala pliras persunas u teams lavuran ensemen vers ina finamira cuminaivla ed inducan lur abilitads e resursas. En il center stattan il barat vicendaivel, la transparenza ed il cundivider da savida. + +Tenor il Gabler Wirtschaftslexikon designescha collaboration era la «collavuraziun tranter ina interpresa e sias clientas e ses clients e furniturs cun utilisar modernas tecnologias d'infurmaziun per integrar process da fatschenta interns ed interinterpresarials». + +Committer:: +In committer è ina persuna che endatescha ina midada da datas en in sistem da gestiun da versiuns. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Contribution:: +Ina contribution OSS è ina contribuziun al svilup ed a la meglieraziun da software open source (OSS). Quai po capitar en furma da code, documentaziun, tests, resuns u auters geners da contribuziuns. (Google AI) + +Contributor Licence Agreement (CLA):: +In Contributor Licence Agreement (CLA), era numnà Contributor Agreement, è in document che fixescha las cundiziuns, sut las qualas proprietad intellectuala dastga vegnir contribuida ad in project u ad ina iniziativa. Per ordinari è manegià cun quai in project da software sut ina licenza open source (Wikipedia). + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Core developer:: +Sviluppadra u sviluppader d'in project OSS cun dretgs d'access sco committer al repositori. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +TDT:: +Sectur Transformaziun digitala e direcziun TIC. Part da la Chanzlia federala ChF + +eOperations:: +eOperations Svizra pussibilitescha prestaziuns publicas digitalas cuminaivlas per la Confederaziun, ils chantuns e las vischnancas. https://www.eoperations.ch[www.eoperations.ch] + +ISB:: +Organ da direcziun d'informatica da la Confederaziun. Predecessur da ChF-TDT + +UFCL:: +Uffizi federal per edifizis e logistica + +Ciclus da vita:: +In ciclus da vita da software descriva il process dal svilup da software cun la finamira da metter a disposiziun software al client. Da regla cumenza il ciclus cun in problem renconuschì dal client e sia analisa e finescha da la vart dal client cun la remplazzada dal software tras in successur. + +Lock-in:: +L'effect lock-in designescha ina stretga liaziun da la clientella a products/prestaziuns u ad in purschider, che renda difficil per la clientella ina midada da product u da purschider pervia dals custs e d'ulteriuras savas colliadas cun la midada. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Analisa dal martgà:: +Ina analisa dal martgà specifica serva ad eruir ed elavurar infurmaziuns davart il martgà d'acquist actual e potenzial. L'intent da l'analisa dal martgà è d'eruir e da chapir las structuras dal martgà ed en spezial la structura dals purschiders areguard tuttas caracteristicas determinantas: situaziun dals pretschs (auts, bass, fluctuaziuns); grondezza dal martgà; repartiziun geografica dals purschiders potenzials e dals acturs principals etc. (vesair https://perimap.admin.ch/goto_perimap_file_38221_download.html). + +Funtaunas pussaivlas per software OSS sa chattan en link:em002-1.pdf[Em002-1 Guida pratica OSS] en il chapitel 7. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +OSS:: +Software open source + +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Product:: +Qua duvrà sco sinonim per «applicaziun». ++ +La noziun deriva da ITIL. En ITIL (Information Technology Infrastructure Library) è in product ina configuraziun da resursas concepida per purtar valur ad ina clientella u ad ina organisaziun. Cuntrari ad in servetsch ch'è tipicamain in process current ed interactiv, è in product ina unitad statica. ++ +Products pon esser software, hardware, datas u autras resursas messas a disposiziun da l'organisaziun. (Google AI) + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-6[] +Standardisaziun da products:: +En quest document sa referescha la standardisaziun en emprima lingia a SD120, il servetsch standard TIC per l'automatisaziun da biro, sco era ad ulteriuras standardisaziuns dal sectur TDT. + +Subscription:: +Tar il retratg da software en abunament vegn serrada ina subscription. Quai munta che il software na vegn betg cumprà. + +En ils pli blers cas cumpiglia quai betg mo il permiss dad utilisar il software, mabain era tut las prestaziuns relevantas ed il support. + +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +Standardisaziun dals products:: +En quest document sa referescha la standardisaziun en emprima lingia a SD120, la prestaziun standard TIC per l'automatisaziun da biro, ed ad ulteriuras standardisaziuns dal sectur TDT. + +SBOM:: +Ina Software Bill of Materials (SBOM) è ina glista d'inventari da tuttas cumponentas e dependenzas da software che fan part dal svilup e da la messa a disposiziun d'in software. + +Abunament:: +Tar l'abunament d'in software vegn concludida ina subscripziun. Quai munta che il software na vegn betg cumprà. + +En la gronda part dals cas cumpiglia quai betg mo il permiss d'utilisar il software, mabain era tuttas prestaziuns determinantas ed il support. + +// end::gloss-em002-7[] +// tag::gloss-em002-6[] +// tag::gloss-em002-7[] +Project upstream:: +Upstream è ina noziun dal svilup da software repartì (savens open source) e designescha la direcziun d'in patch vers sia origin (upstream), pia vers las sviluppadras ed ils sviluppaders resp. maintainers originals dal software u vers il project original. I po sa tractar era da bibliotecas da software. + +// end::gloss-em002-7[] +// end::gloss-em002-6[] +// tag::gloss-em002-7[] +ZenDiS:: +ZenDiS è ina societad cun responsabladad limitada (GmbH) en maun public en Germania. Ella sustegna la Confederaziun, ils Länder e las vischnancas en la realisaziun da la suveranitad digitala. Cun opencode.de e container.gov.de porscha ella ina plattafurma per in svilup open source segir. (https://www.zendis.de[www.zendis.de]) + +Zero-day-exploit:: +In zero-day-exploit designescha l'exploataziun d'ina largia da segirezza, per la quala i n'è anc disponibel nagin patch dal fabricant da la cumponenta. + +// end::gloss-em002-7[] diff --git a/docs/partials/references.de.adoc b/docs/partials/references.de.adoc new file mode 100644 index 0000000..81ecc34 --- /dev/null +++ b/docs/partials/references.de.adoc @@ -0,0 +1,200 @@ +// Siehe references.en.adoc für die Begründung dieser Aufteilung. +// tag::ref-em002-tools[] +[Em002]:: +Em002 Strategische Leitlinien für Open-Source-Software in der Bundesverwaltung, Version 2.0, 2025 + +[Em002-1]:: +Em002-1 Praxisleitfaden für Open-Source-Software in der Bundesverwaltung, Version 2.0, 2025 + +[Em002-2]:: +Em002-2 Anleitung zur Veröffentlichung von Open-Source-Software, Version 2.0, 2025 + +[Em002-2.1]:: +Em002-2.1 Checkliste OSS-Vorabklärung, Version 2.0, 2025 + +[Em002-2.2]:: +Em002-2.2 Checkliste OSS-Analyse und -Vorbereitung, Version 2.0, 2025 + +[Em002-2.3]:: +Em002-2.3 Checkliste OSS-Freigabe und -Veröffentlichung, Version 2, 2025 + +[Em002-3]:: +Em002-3 Leitfaden OSS-Lizenzierung, Version 2.0, 2025 + +[Em002-4]:: +Em002-4 Leitfaden OSS-Community, Version 2.0, 2025 + +[Em002-4.1]:: +Em002-4.1 Checkliste OSS-Community, Version 2.0, 2025 + +[Em002-5]:: +Em002-5 Merkblatt OSS-Hilfsmittel, Version 2.0, 2025 + +[Em002-6]:: +Em002-6 Häufig gestellte Fragen zur Veröffentlichung von OSS (FAQ-OSS), Version 2.0, 2025 + +[Em002-7]:: +Em002-7 Strategische Aspekte der Beschaffung und Open-Source-Software, Version 2.0, 2025 + +[BBL-WZK]:: +Merkblätter für die BBL-Bedarfsstellen finden sich im entsprechenden Werkzeugkasten: 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]:: +AGB des Bundes. link:https://www.bkb.admin.ch/bkb/de/home/themen/agb.html[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] + +// end::ref-em002-tools[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[A029]:: +Produktstandard für Büroautomations-Clientsoftware (BAB) +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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-7[] +[BBL2015]:: +Merkblatt: Softwareausschreibungen: Sicherstellung eines breiten Wettbewerbs; 2015; nicht mehr in Kraft + +[BITKOM2024]:: +Leitfaden Open-Source-Software 2.0. Berlin: Bitkom e. V. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. BIT-KOM. 2024. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-Leitfaden-zu-Open-Source-Software-20.html + +// end::ref-em002-7[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[BöB]:: +Bundesgesetz über das öffentliche Beschaffungswesen (BöB) link:https://www.fedlex.admin.ch/eli/oc/2020/126/de[https://www.fedlex.admin.ch/eli/oc/2020/126/de] + +[DigiV]:: +Verordnung über digitale Dienstleistungen und die digitale Transformation in der Bundesverwaltung (DigiV) link:https://www.fedlex.admin.ch/eli/cc/2025/235/de[SR 172.019.1 – Verordnung vom 2. April 2025 | Fedlex] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[BBL-WL]:: +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[Wegleitung Open Source in der Beschaffung], BBL; 2025 + +Entscheidungshilfe für Einkäuferinnen und Einkäufer in Projekten mit möglicher OSS-Relevanz. Enthält Informationen zur korrekten Umsetzung in Ausschreibungen und Verträgen. (PDF) + +Nur für Bundesstellen im Bundesintranet zugänglich + +[BBL-CL]:: +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[Checkliste Integral-Ausnahme Art. 9 EMBAG], BBL, 2025, + +Hilft bei der Prüfung und Dokumentation, ob im Einzelfall auf die Veröffentlichung entwickelter Software verzichtet werden kann. (DOCX) + +Nur für Bundesstellen im Bundesintranet zugänglich + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-MB]:: +Merkblatt: Softwarebeschaffung und Art. 9 EMBAG, Kompetenzzentrum Beschaffungswesen Bund: + +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html] + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-general[] +[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 Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) 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, März 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, und Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4. Aufl. München: C.H.Beck. 2016 + +[KuWiSa2008]:: +Kuhn, Bradley M., Williamson, Aaron; und 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. und Oppermann, K.. Narratives of digital sovereignty in German political discourse', Governance, 36(3), S. 693–709. 2023. Verfügbar unter: link:https://doi.org/10.1111/gove.12690[https://doi.org/10.1111/gove.12690] + +[LaWu2022]:: +Laux, Christian und Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Version 1.0. Juli 2022 + +[Le2023]:: +Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Präsentation vom 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[Strategie Digitale Bundesverwaltung] und Transformationsplan. + +[Sc2024]:: +Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 + +[ScScPo2017]:: +Schlauri, Simon, Schweizer, Samuel, und 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. Zürich: 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, Bericht für das EDA. 2024 link:https://arxiv.org/abs/2406.03266[[2406.03266\] Technological Perspective on Digital Sovereignty (arxiv.org)] + +[StGa2018]:: +Stürmer, Matthias, und 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 und 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] + +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-KV]:: +Musterkriterien – Beschaffung und EMBAG. +https://perimap.admin.ch/goto_perimap_file_47064_download.html+ + +Mustervertragstexte – Softwareentwicklung +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] (Registrierung erforderlich) + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-7[] +[OSBA-VK]:: +Vergabekriterien für die nachhaltige Beschaffung von Open-Source-Software | OSBA – Open Source Business Alliance + +[Sto2024]:: +Fachausweis 3 zu beschaffungsrelevanten Kriterien im Zusammenhang mit dem neuen _Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) gestützt auf Art. 9 (Open-Source-Software)_ von Reto Stoll, 2024 + +[Stü2015]:: +Open-Source-Geschäftsmodell: Mehrwert des Subskriptionsangebots, 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 für die Beschaffung von Open-Source-Software: +https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/+, 2015 + +[W012]:: +W012 – Weisungen für die digitale Souveränität in der Bundesverwaltung, V1.0 2025 + +// end::ref-em002-7[] diff --git a/docs/partials/references.en.adoc b/docs/partials/references.en.adoc new file mode 100644 index 0000000..952ae1a --- /dev/null +++ b/docs/partials/references.en.adoc @@ -0,0 +1,231 @@ +// The reference list shared by Em002 and Em002-7. Three tags, not two: +// Em002 prints its references as two separate lists in two separate sections +// -- "References for OSS tools" and "General references" -- with the document +// map wedged between them, so one tag per list is the only way to reproduce +// it. Em002-7's Annex A is the third. +// +// The lists overlap more than they look: [A029], [BoeB] and [DigiV] are in +// both Em002's general list and Annex A, and [BBL-WL], [BBL-CL], [KBB-KV] and +// [KBB-Perimap] are in both Em002's tools list and Annex A. All seven had +// drifted, in the title and in the link form -- Em002 writes `link:url[text]`, +// Annex A writes `+url+`, which renders as inert text. +// +// [KBB-MB] and Annex A's [KKB-MB] were the same information sheet at the same +// URL under two keys, and are now one entry under [KBB-MB]. KBB is +// Kompetenzzentrum Beschaffungswesen Bund, and Annex A's own neighbours are +// [KBB-KV] and [KBB-Perimap], so [KKB-MB] was the typo. Annex A cited +// [KBB-MB] six times without defining it, and [KKB-MB] once. +// +// [BITKOM2023] (Em002) and [BITKOM2024] (Annex A) still look like one source +// under two names and are NOT merged here, because picking a year is the +// document owner's call: same Bitkom guide at the same URL, two years apart. +// +// The section text that follows [KBB-Perimap] in Em002 -- the document map and +// its caption -- is not part of the list and stays in Em002.adoc. +// tag::ref-em002-tools[] +[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): 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] + +// end::ref-em002-tools[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[A029]:: +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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-7[] +[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 + +// end::ref-em002-7[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[BBL-WL]:: +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]:: +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 + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-MB]:: +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] + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[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+ + +// end::ref-em002-7[] +// The two source documents label this entry differently: Em002 keeps the +// German platform name, Em002-7 translates it. Both are upstream wording, so +// each consuming document keeps its own. +[KBB-Perimap]:: +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[Lern und Vorlagenplattform KBB] (Registration is required) + +// end::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-Perimap]:: +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[CCPP learning and template platform] (Registration is required) + +// end::ref-em002-7[] +// tag::ref-em002-7[] +[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 + +// end::ref-em002-7[] diff --git a/docs/partials/references.fr.adoc b/docs/partials/references.fr.adoc new file mode 100644 index 0000000..7241b1b --- /dev/null +++ b/docs/partials/references.fr.adoc @@ -0,0 +1,200 @@ +// Voir references.en.adoc pour la justification de ce découpage. +// tag::ref-em002-tools[] +[Em002]:: +Em002 Lignes directrices stratégiques pour les logiciels open source dans l'administration fédérale, version 2.0, 2025 + +[Em002-1]:: +Em002-1 Guide pratique pour les logiciels open source dans l'administration fédérale, version 2.0, 2025 + +[Em002-2]:: +Em002-2 Instructions pour la publication de logiciels open source, version 2.0, 2025 + +[Em002-2.1]:: +Em002-2.1 Liste de contrôle Évaluation préalable OSS, version 2.0, 2025 + +[Em002-2.2]:: +Em002-2.2 Liste de contrôle Analyse et préparation OSS, version 2.0, 2025 + +[Em002-2.3]:: +Em002-2.3 Liste de contrôle Validation et publication OSS, version 2, 2025 + +[Em002-3]:: +Em002-3 Guide de licences OSS, version 2.0, 2025 + +[Em002-4]:: +Em002-4 Guide des communautés OSS, version 2.0, 2025 + +[Em002-4.1]:: +Em002-4.1 Liste de contrôle Communauté OSS, version 2.0, 2025 + +[Em002-5]:: +Em002-5 Aide-mémoire Outils OSS, version 2.0, 2025 + +[Em002-6]:: +Em002-6 Foire aux questions sur la publication d'OSS (FAQ-OSS), version 2.0, 2025 + +[Em002-7]:: +Em002-7 Aspects stratégiques des achats et des logiciels open source, version 2.0, 2025 + +[BBL-WZK]:: +Les aide-mémoire destinés aux services demandeurs de l'OFCL figurent dans la boîte à outils correspondante (en allemand) : 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]:: +CG de la Confédération. link:https://www.bkb.admin.ch/bkb/de/home/themen/agb.html[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] + +// end::ref-em002-tools[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[A029]:: +Standard de produit pour les logiciels clients de bureautique +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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-7[] +[BBL2015]:: +Aide-mémoire : appels d'offres de logiciels : garantir une large concurrence ; 2015 ; n'est plus en vigueur + +[BITKOM2024]:: +Leitfaden Open-Source-Software 2.0. 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 + +// end::ref-em002-7[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[BöB]:: +Loi fédérale sur les marchés publics (LMP) link:https://www.fedlex.admin.ch/eli/oc/2020/126/fr[https://www.fedlex.admin.ch/eli/oc/2020/126/fr] + +[DigiV]:: +Ordonnance sur les prestations numériques et la transformation numérique au sein de l'administration fédérale (ONum) link:https://www.fedlex.admin.ch/eli/cc/2025/235/fr[RS 172.019.1 – Ordonnance du 2 avril 2025 | Fedlex] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[BBL-WL]:: +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[Directives Open Source dans les acquisitions], OFCL ; 2025 + +Aide à la décision pour les acheteurs dans les projets présentant une possible pertinence OSS. Contient des informations sur la mise en œuvre correcte dans les appels d'offres et les contrats. (PDF) + +Accessible uniquement aux services fédéraux sur l'intranet de la Confédération + +[BBL-CL]:: +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[Liste de contrôle pour l'exception forfaitaire selon l'art. 9 LMETA], OFCL, 2025, + +Aide à examiner et à documenter si, dans un cas d'espèce, il est possible de renoncer à la publication d'un logiciel développé. (DOCX) + +Accessible uniquement aux services fédéraux sur l'intranet de la Confédération + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-MB]:: +Aide-mémoire : acquisition de logiciels et art. 9 LMETA, Centre de compétence des marchés publics de la Confédération : + +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html] + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-general[] +[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 Loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA) link:https://www.fedlex.admin.ch/eli/cc/2023/682/fr[https://www.fedlex.admin.ch/eli/cc/2023/682/fr] + +[Fr2012]:: +Fröhlich-Bleuler, Gianni. Open Source Compliance. Jusletter 12 novembre 2012. + +[Ga2021]:: +Gartner for Application and Software Engineering Leaders Tool: Open Source Software Governance Policy Template. Gartner, mars 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, et Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4e éd. Munich: C.H.Beck. 2016 + +[KuWiSa2008]:: +Kuhn, Bradley M., Williamson, Aaron; et 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. et Oppermann, K.. Narratives of digital sovereignty in German political discourse', Governance, 36(3), p. 693–709. 2023. Disponible à l'adresse : link:https://doi.org/10.1111/gove.12690[https://doi.org/10.1111/gove.12690] + +[LaWu2022]:: +Laux, Christian et Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Version 1.0. Juillet 2022 + +[Le2023]:: +Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Présentation du 18 septembre 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[Stratégie Administration fédérale numérique] et plan de transformation. + +[Sc2024]:: +Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 + +[ScScPo2017]:: +Schlauri, Simon, Schweizer, Samuel, et 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 août 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, rapport pour le DFAE. 2024 link:https://arxiv.org/abs/2406.03266[[2406.03266\] Technological Perspective on Digital Sovereignty (arxiv.org)] + +[StGa2018]:: +Stürmer, Matthias, et 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 et 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] + +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-KV]:: +Critères types — Acquisition et LMETA. +https://perimap.admin.ch/goto_perimap_file_47064_download.html+ + +Textes contractuels types — Développement logiciel +https://perimap.admin.ch/goto_perimap_file_47059_download.html+ + +[KBB-Perimap]:: +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[Plateforme d'apprentissage et de modèles du CCMP] (inscription requise) + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-7[] +[OSBA-VK]:: +Critères d'adjudication pour l'acquisition durable de logiciels open source | OSBA — Open Source Business Alliance + +[Sto2024]:: +Brevet de compétence 3 relatif aux critères pertinents pour les acquisitions en lien avec la nouvelle _loi fédérale sur l'utilisation des moyens électroniques pour l'exécution des tâches des autorités (LMETA), fondée sur l'art. 9 (logiciels open source)_ de Reto Stoll, 2024 + +[Stü2015]:: +Modèle d'affaires open source : valeur ajoutée de l'offre d'abonnement, 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 pour l'acquisition de logiciels open source : +https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/+, 2015 + +[W012]:: +W012 — Directives pour la souveraineté numérique au sein de l'administration fédérale, V1.0 2025 + +// end::ref-em002-7[] diff --git a/docs/partials/references.it.adoc b/docs/partials/references.it.adoc new file mode 100644 index 0000000..0915941 --- /dev/null +++ b/docs/partials/references.it.adoc @@ -0,0 +1,200 @@ +// Cfr. references.en.adoc per la motivazione di questa suddivisione. +// tag::ref-em002-tools[] +[Em002]:: +Em002 Linee guida strategiche per il software open source nell'Amministrazione federale, versione 2.0, 2025 + +[Em002-1]:: +Em002-1 Guida pratica per il software open source nell'Amministrazione federale, versione 2.0, 2025 + +[Em002-2]:: +Em002-2 Istruzioni per la pubblicazione di software open source, versione 2.0, 2025 + +[Em002-2.1]:: +Em002-2.1 Lista di controllo Valutazione preliminare OSS, versione 2.0, 2025 + +[Em002-2.2]:: +Em002-2.2 Lista di controllo Analisi e preparazione OSS, versione 2.0, 2025 + +[Em002-2.3]:: +Em002-2.3 Lista di controllo Rilascio e pubblicazione OSS, versione 2, 2025 + +[Em002-3]:: +Em002-3 Guida alle licenze OSS, versione 2.0, 2025 + +[Em002-4]:: +Em002-4 Guida alle community OSS, versione 2.0, 2025 + +[Em002-4.1]:: +Em002-4.1 Lista di controllo Community OSS, versione 2.0, 2025 + +[Em002-5]:: +Em002-5 Promemoria Strumenti OSS, versione 2.0, 2025 + +[Em002-6]:: +Em002-6 Domande frequenti sulla pubblicazione di OSS (FAQ-OSS), versione 2.0, 2025 + +[Em002-7]:: +Em002-7 Aspetti strategici degli acquisti e del software open source, versione 2.0, 2025 + +[BBL-WZK]:: +I promemoria per i servizi richiedenti dell'UFCL si trovano nella corrispondente cassetta degli attrezzi (in tedesco): 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]:: +CG della Confederazione. link:https://www.bkb.admin.ch/bkb/de/home/themen/agb.html[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] + +// end::ref-em002-tools[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[A029]:: +Standard di prodotto per il software client di automazione d'ufficio +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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-7[] +[BBL2015]:: +Promemoria: bandi di software: garantire un'ampia concorrenza; 2015; non più in vigore + +[BITKOM2024]:: +Leitfaden Open-Source-Software 2.0. 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 + +// end::ref-em002-7[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[BöB]:: +Legge federale sugli appalti pubblici (LAPub) link:https://www.fedlex.admin.ch/eli/oc/2020/126/it[https://www.fedlex.admin.ch/eli/oc/2020/126/it] + +[DigiV]:: +Ordinanza sulle prestazioni digitali e sulla trasformazione digitale nell'Amministrazione federale (ODigit) link:https://www.fedlex.admin.ch/eli/cc/2025/235/it[RS 172.019.1 – Ordinanza del 2 aprile 2025 | Fedlex] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[BBL-WL]:: +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[Direttive Open Source negli acquisti], UFCL; 2025 + +Ausilio decisionale per gli acquirenti in progetti con possibile rilevanza OSS. Contiene informazioni sulla corretta attuazione in bandi e contratti. (PDF) + +Accessibile soltanto ai servizi federali sull'intranet della Confederazione + +[BBL-CL]:: +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[Lista di controllo per l'eccezione forfettaria secondo l'art. 9 LMeCA], UFCL, 2025, + +Aiuta a esaminare e documentare se, nel singolo caso, si può rinunciare alla pubblicazione del software sviluppato. (DOCX) + +Accessibile soltanto ai servizi federali sull'intranet della Confederazione + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-MB]:: +Promemoria: acquisto di software e art. 9 LMeCA, Centro di competenza per gli acquisti pubblici della Confederazione: + +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html] + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-general[] +[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 Legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA) link:https://www.fedlex.admin.ch/eli/cc/2023/682/it[https://www.fedlex.admin.ch/eli/cc/2023/682/it] + +[Fr2012]:: +Fröhlich-Bleuler, Gianni. Open Source Compliance. Jusletter 12 novembre 2012. + +[Ga2021]:: +Gartner for Application and Software Engineering Leaders Tool: Open Source Software Governance Policy Template. Gartner, marzo 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, e Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4a ed. Monaco: C.H.Beck. 2016 + +[KuWiSa2008]:: +Kuhn, Bradley M., Williamson, Aaron; e 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. e Oppermann, K.. Narratives of digital sovereignty in German political discourse', Governance, 36(3), pagg. 693–709. 2023. Disponibile all'indirizzo: link:https://doi.org/10.1111/gove.12690[https://doi.org/10.1111/gove.12690] + +[LaWu2022]:: +Laux, Christian e Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Versione 1.0. Luglio 2022 + +[Le2023]:: +Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Presentazione del 18 settembre 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[Strategia Amministrazione federale digitale] e piano di trasformazione. + +[Sc2024]:: +Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 + +[ScScPo2017]:: +Schlauri, Simon, Schweizer, Samuel, e 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 agosto 2019). + +[St2011]:: +Straub, Wolfgang. Softwareschutz: Urheberrecht, Patentrecht, Open Source. Zurigo: 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, rapporto per il DFAE. 2024 link:https://arxiv.org/abs/2406.03266[[2406.03266\] Technological Perspective on Digital Sovereignty (arxiv.org)] + +[StGa2018]:: +Stürmer, Matthias, e 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 e 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] + +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-KV]:: +Criteri tipo — Acquisto e LMeCA. +https://perimap.admin.ch/goto_perimap_file_47064_download.html+ + +Testi contrattuali tipo — Sviluppo software +https://perimap.admin.ch/goto_perimap_file_47059_download.html+ + +[KBB-Perimap]:: +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[Piattaforma di apprendimento e modelli del CCAP] (è necessaria la registrazione) + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-7[] +[OSBA-VK]:: +Criteri di aggiudicazione per l'acquisto sostenibile di software open source | OSBA — Open Source Business Alliance + +[Sto2024]:: +Attestato di competenza 3 sui criteri rilevanti per gli acquisti in relazione alla nuova _legge federale sull'impiego di mezzi elettronici per l'adempimento dei compiti delle autorità (LMeCA), fondata sull'art. 9 (software open source)_ di Reto Stoll, 2024 + +[Stü2015]:: +Modello di business open source: valore aggiunto dell'offerta di abbonamento, 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 per l'acquisto di software open source: +https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/+, 2015 + +[W012]:: +W012 — Direttive per la sovranità digitale nell'Amministrazione federale, V1.0 2025 + +// end::ref-em002-7[] diff --git a/docs/partials/references.rm.adoc b/docs/partials/references.rm.adoc new file mode 100644 index 0000000..de3b1a8 --- /dev/null +++ b/docs/partials/references.rm.adoc @@ -0,0 +1,200 @@ +// Vesair references.en.adoc per la motivaziun da questa repartiziun. +// tag::ref-em002-tools[] +[Em002]:: +Em002 Directivas strategicas per software open source en l'administraziun federala, versiun 2.0, 2025 + +[Em002-1]:: +Em002-1 Guida pratica per software open source en l'administraziun federala, versiun 2.0, 2025 + +[Em002-2]:: +Em002-2 Instrucziuns per publitgar software open source, versiun 2.0, 2025 + +[Em002-2.1]:: +Em002-2.1 Glista da controlla Evaluaziun preliminara OSS, versiun 2.0, 2025 + +[Em002-2.2]:: +Em002-2.2 Glista da controlla Analisa e preparaziun OSS, versiun 2.0, 2025 + +[Em002-2.3]:: +Em002-2.3 Glista da controlla Relaschada e publicaziun OSS, versiun 2, 2025 + +[Em002-3]:: +Em002-3 Guida da licenzas OSS, versiun 2.0, 2025 + +[Em002-4]:: +Em002-4 Guida da communitads OSS, versiun 2.0, 2025 + +[Em002-4.1]:: +Em002-4.1 Glista da controlla Communitad OSS, versiun 2.0, 2025 + +[Em002-5]:: +Em002-5 Fegl d'infurmaziun Meds OSS, versiun 2.0, 2025 + +[Em002-6]:: +Em002-6 Dumondas frequentas davart la publicaziun da l'OSS (FAQ-OSS), versiun 2.0, 2025 + +[Em002-7]:: +Em002-7 Aspects strategics da l'acquist e dal software open source, versiun 2.0, 2025 + +[BBL-WZK]:: +Fegls d'infurmaziun per ils posts da basegn da l'UFCL sa chattan en la chascha d'utensilis correspundenta (per tudestg): 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]:: +CGC da la Confederaziun. link:https://www.bkb.admin.ch/bkb/de/home/themen/agb.html[https://www.bkb.admin.ch/bkb/de/home/themen/agb.html] + +// end::ref-em002-tools[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[A029]:: +Standard da product per software da client d'automatisaziun da biro +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] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-general[] +[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] + +// end::ref-em002-general[] +// tag::ref-em002-7[] +[BBL2015]:: +Fegl d'infurmaziun: Concurs da software: garantir ina vasta concurrenza; 2015; betg pli en vigur + +[BITKOM2024]:: +Leitfaden Open-Source-Software 2.0. 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 + +// end::ref-em002-7[] +// tag::ref-em002-general[] +// tag::ref-em002-7[] +[BöB]:: +Lescha federala davart l'acquist public (LAPub) link:https://www.fedlex.admin.ch/eli/oc/2020/126/de[https://www.fedlex.admin.ch/eli/oc/2020/126/de] + +[DigiV]:: +Ordinaziun davart las prestaziuns digitalas e la transformaziun digitala en l'administraziun federala (DigiV) link:https://www.fedlex.admin.ch/eli/cc/2025/235/de[CS 172.019.1 – Ordinaziun dals 2 d'avrigl 2025 | Fedlex] + +// end::ref-em002-7[] +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[BBL-WL]:: +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[Directiva Open Source en l'acquist], UFCL; 2025 + +Agid da decisiun per cumpraders en projects cun ina pussaivla relevanza OSS. Cuntegna infurmaziuns davart la realisaziun correcta en concurs ed en contracts. (PDF) + +Accessibel mo per posts federals en l'intranet da la Confederaziun + +[BBL-CL]:: +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[Glista da controlla excepziun integrala art. 9 EMBAG], UFCL, 2025, + +Gida tar l'examinaziun e la documentaziun, sch'i po vegnir renunzià en il cas singul a la publicaziun dal software sviluppà. (DOCX) + +Accessibel mo per posts federals en l'intranet da la Confederaziun + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-MB]:: +Fegl d'infurmaziun: acquist da software ed art. 9 EMBAG, Center da cumpetenza per l'acquist public da la Confederaziun: + +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[https://perimap.admin.ch/goto_perimap_file_46835_download.html] + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-general[] +[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 Lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG) link:https://www.fedlex.admin.ch/eli/cc/2023/682/rm[https://www.fedlex.admin.ch/eli/cc/2023/682/rm] + +[Fr2012]:: +Fröhlich-Bleuler, Gianni. Open Source Compliance. Jusletter ils 12 da november 2012. + +[Ga2021]:: +Gartner for Application and Software Engineering Leaders Tool: Open Source Software Governance Policy Template. Gartner, mars 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, e Metzger, Alex. Open Source Software: Rechtliche Rahmenbedingungen der Freien Software. 4. ed. Minca: C.H.Beck. 2016 + +[KuWiSa2008]:: +Kuhn, Bradley M., Williamson, Aaron; e 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. ed Oppermann, K.. Narratives of digital sovereignty in German political discourse', Governance, 36(3), p. 693–709. 2023. Disponibel sut: link:https://doi.org/10.1111/gove.12690[https://doi.org/10.1111/gove.12690] + +[LaWu2022]:: +Laux, Christian e Wüst, Anja. Datensouveränität – Was es zur Begriffsklärung braucht. Swiss Data Alliance. Versiun 1.0. Fanadur 2022 + +[Le2023]:: +Lehmann, David. Erfahrungen mit Open Source Freigabe beim BIT. Preschentaziun dals 18 da settember 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[Strategia Administraziun federala digitala] e plan da transformaziun. + +[Sc2024]:: +Schlauri, Simon. Charakteristika gängiger Open-Source-Lizenzen. 2024 + +[ScScPo2017]:: +Schlauri, Simon, Schweizer, Samuel, e 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 d'avust 2019). + +[St2011]:: +Straub, Wolfgang. Softwareschutz: Urheberrecht, Patentrecht, Open Source. Turitg: 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, rapport per il DFAE. 2024 link:https://arxiv.org/abs/2406.03266[[2406.03266\] Technological Perspective on Digital Sovereignty (arxiv.org)] + +[StGa2018]:: +Stürmer, Matthias, e 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 e 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] + +// end::ref-em002-general[] +// tag::ref-em002-tools[] +// tag::ref-em002-7[] +[KBB-KV]:: +Criteris models – Acquist ed EMBAG. +https://perimap.admin.ch/goto_perimap_file_47064_download.html+ + +Texts da contract models – Svilup da software +https://perimap.admin.ch/goto_perimap_file_47059_download.html+ + +[KBB-Perimap]:: +link:https://perimap.admin.ch/goto_perimap_file_46835_download.html[Plattafurma d'emprender e da models dal CCA] (ina registraziun è necessaria) + +// end::ref-em002-7[] +// end::ref-em002-tools[] +// tag::ref-em002-7[] +[OSBA-VK]:: +Criteris d'attribuziun per l'acquist persistent da software open source | OSBA – Open Source Business Alliance + +[Sto2024]:: +Attestat da cumpetenza 3 davart criteris relevants per l'acquist en connex cun la nova _lescha federala davart l'utilisaziun da meds electronics per ademplir incumbensas d'autoritads (EMBAG), sa basond sin l'art. 9 (software open source)_ da Reto Stoll, 2024 + +[Stü2015]:: +Model da fatschenta open source: plivalur da la purschida d'abunament, 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 per l'acquist da software open source: +https://www.parldigi.ch/de/sik-e-fuer-beschaffung-von-open-source-software/+, 2015 + +[W012]:: +W012 – Directivas per la suveranitad digitala en l'administraziun federala, V1.0 2025 + +// end::ref-em002-7[] diff --git a/publiccode.yml b/publiccode.yml index 7ee0694..b931fb6 100644 --- a/publiccode.yml +++ b/publiccode.yml @@ -46,7 +46,12 @@ description: - Documentation - Open Source Knowledge screenshots: - - https://github.com/swiss/opensource-guidelines/blob/e173972f2119e46d38e017064544d179e69805eb/docs/en/assets/em002-1/media/image1.png + # A page of the rendered Em002, not a source asset: it shows what this + # repository actually produces. The previous entry pointed at a diagram + # PNG through a `/blob/` URL, which serves an HTML page rather than an + # image, and at a bitmap that no longer exists now that the diagrams are + # generated from the AsciiDoc sources. + - https://raw.githubusercontent.com/swiss/opensource-guidelines/main/docs/assets/screenshots/document-map.png legal: license: CC0-1.0 maintenance: @@ -60,4 +65,5 @@ localisation: - de-CH - fr-CH - it-CH + - rm-CH - en diff --git a/tools/check-asciidoc.sh b/tools/check-asciidoc.sh new file mode 100755 index 0000000..ea3bb8e --- /dev/null +++ b/tools/check-asciidoc.sh @@ -0,0 +1,276 @@ +#!/usr/bin/env bash +# +# Fail on AsciiDoc that does not parse, on cross-references that do not +# resolve, and on citations with no reference entry. +# +# tools/check-asciidoc.sh [file.adoc...] +# +# With no arguments, checks every tracked .adoc; the git hook passes the files +# it is about to commit. +# +# git-hooks.nix ships no AsciiDoc linter, and the render pipeline is the only +# thing that reads these files -- so without this, a broken include or an +# unterminated block is first noticed by the CI render matrix, several minutes +# and five parallel jobs later. asciidoctor parses in well under a second per +# document, so the same class of mistake can be caught at commit time. +# +# Every document is checked once per language. The bodies are five +# `ifeval::["{lang}" == ""]` blocks, so a conditional left unterminated in +# the Romansh block is simply invisible while parsing as English, which is what +# a single default-language pass would do. +# +# Runs from the repository root. Both checks below resolve paths from there, and +# it is where prek invokes this in the hook and in CI. + +set -euo pipefail + +here=$(dirname "${BASH_SOURCE[0]}") +here=$(cd "${here}" && pwd) +root=$(cd "${here}/.." && pwd) +cd "${root}" + +# The five languages render-docs builds. A document that opts out of one with +# `:l10n-languages:` still has to parse in it -- the guards just yield an empty +# body -- so there is no reason to read that attribute here. +languages=(en de fr it rm) + +files=() +if [[ "$#" -gt 0 ]]; then + files=("${@}") +else + tracked=$(git ls-files '*.adoc') + while IFS= read -r file; do + [[ -n "${file}" ]] || continue + files+=("${file}") + done <<<"${tracked}" +fi + +if [[ "${#files[@]}" -eq 0 ]]; then + exit 0 +fi + +status=0 + +# --------------------------------------------------------------------------- +# Parse, convert, and fail on anything asciidoctor diagnoses at INFO or above. +# --------------------------------------------------------------------------- +# +# `--out-file -` with stdout thrown away, not `--out-file /dev/null`: asciidoctor +# special-cases that one path and returns the loaded document *without ever +# converting it* -- lib/asciidoctor/convert.rb reads +# +# when '/dev/null' then return load input, options +# +# so nothing the converter diagnoses could reach this gate at any +# --failure-level. An unresolved <> is diagnosed during conversion, which +# is why this used to be documented as out of reach: the symptom was real, the +# explanation was not. Converting for real and discarding the HTML costs nothing +# measurable (2.5s either way across the whole repository), because the parse is +# the expensive half. +# +# `--failure-level=INFO` and `--verbose` are then both needed, for different +# reasons: an unresolved cross-reference is logged at INFO, so INFO has to be +# fatal *and* has to be logged at all. asciidoctor has no --log-level; -v / +# --verbose is its only lever on the logger, and it lowers the threshold to +# DEBUG. WARN stays fatal as before -- asciidoctor otherwise prints +# "unterminated listing block" and still exits 0. +# +# Lowering the threshold to DEBUG also turns on 35 lines per language that +# open-govpress's own extensions provoke ("unknown style for literal block: +# mermaid", "unknown name for block macro: field", ditto "signature"): plain +# asciidoctor has no such extensions, so it says so, once per block. Those are +# filtered out rather than explained away in this comment, because DEBUG sits +# below INFO and can therefore never change the exit code -- the lines are noise +# by construction, and 175 of them per run would train people to stop reading +# this gate's output. The filter keys on the level label, not on the three +# messages, so a fourth open-govpress extension needs no change here and nothing +# that could ever fail the gate is hidden. +# +# One asciidoctor per language rather than per file-and-language: Ruby startup +# dominates (0.29s per invocation, whatever the document's size), so batching the +# whole repository costs 2.5s where 100 separate runs cost 29s. The price is +# paid by exactly one message: the INFO line for an unresolved cross-reference +# reads "possible invalid reference: " and names no file and no line, so a +# batched failure says which reference dangles but not where. That is worth 26 +# seconds a commit, because the key is its own locator -- `git grep -n '<&1 >/dev/null + } | { grep -v ': DEBUG: ' >&2 || true; }; then + echo "check-asciidoc.sh: failed to check as '${lang}'" >&2 + status=1 + fi +done + +# --------------------------------------------------------------------------- +# Every cited reference key has a reference entry defining it. +# --------------------------------------------------------------------------- +# +# The check above cannot do this and no log level makes it: a citation is the +# literal text `[St2024]`, and a reference entry is a description-list term +# `[St2024]::` (or, once the lists are centralised, a bibliography anchor +# `[[[St2024]]]`). Nothing connects the two, so a citation whose entry was never +# written -- or, now that the lists are moving into tagged partials, whose entry +# a `tags=` selector did not select -- renders as a bracketed label pointing at +# nothing, in silence, in asciidoctor and in open-govpress alike. +# +# asciidoctor-reducer resolves the includes and the `ifeval::` guards and prints +# the flattened source, which is the only honest way to ask what a given language +# actually ends up containing: it applies the same tag selection that will +# silently drop an entry, so a mis-tagged include shows up here as the citation +# losing its definition. It ships with the asciidoctor package devenv.nix +# already pulls in. +# +# Always the whole tracked corpus, whatever arguments were passed, because a +# citation and its entry live in different documents: only Em002 and Em002-7 +# carry reference lists, and every other document says so in prose ("The +# references ... can be found in the Em002 Strategic Guidelines"). Checking a +# document against its own entries alone would report every citation in Em002-1. +# The flip side is that this cannot catch an entry that went missing from one +# list while another list still defines the key. +marker='// check-asciidoc: file ' + +manifest='' +tracked=$(git ls-files '*.adoc') +while IFS= read -r file; do + [[ -n "${file}" ]] || continue + # Fragments are not documents -- render-docs and site-index.sh exclude them + # too. They are read through the documents that include them, which is the + # point: that is where the tag selection happens. + case "${file}" in + docs/partials/*) continue ;; + *) ;; + esac + manifest+="${marker}${file}"$'\n' + manifest+="include::${file}[]"$'\n' +done <<<"${tracked}" + +# The classes are negated rather than spelled [[:alpha:]] and [[:alnum:]] so that +# the umlaut in [BöB] is a key character whether awk reads characters (a UTF-8 +# locale) or bytes (the C locale a bare CI runner hands it). +# +# A bracketed token is a citation only when what precedes it is prose. The text +# of an inline macro looks identical -- `link:em002-2.pdf[Em002-2]` -- but the +# bracket there follows the macro target, so requiring a blank, a `_`, an opening +# quote or the start of the line in front of it separates the two. A line that is +# nothing but `[...]` is a block attribute list, never a citation. +# +# Inside a footnote the closing bracket is written `\]`, because Asciidoctor ends +# the footnote at the first bare one. The backslash belongs to the escape and not +# to the key, so it is dropped along with the bracket. +program=$( + cat <<'AWK' +BEGIN { + keychar = "[^][:space:],;:=%#*<>&+/\"'?!()|[]" + keystart = "[^][:space:],;:=%#*<>&+/\"'?!()|.0-9_[-]" + key = keystart keychar "*" + entry_dl = "^\\[" key "\\]::" + entry_bib = "^\\[\\[\\[" key "\\]\\]\\]" + citation = "(^|[[:space:]_(\"'])\\[" key "\\]" +} + +index($0, marker) == 1 { file = substr($0, length(marker) + 1); next } + +# A comment renders as nothing, so a key inside one is not a citation. The +# partials discuss their own keys in their headers, which would otherwise read +# as a dozen citations apiece. +$0 ~ /^\/\/\/\/+[[:space:]]*$/ { commented = !commented; next } +commented { next } +$0 ~ /^\/\// { next } + +$0 ~ entry_bib { k = $0; sub(/^\[\[\[/, "", k); sub(/\]\]\].*/, "", k); defined[k] = 1; next } +$0 ~ entry_dl { k = $0; sub(/^\[/, "", k); sub(/\]::.*/, "", k); defined[k] = 1; next } + +$0 ~ /^\[[^]]*\]$/ { next } + +{ + rest = $0 + while (match(rest, citation)) { + k = substr(rest, RSTART, RLENGTH) + sub(/^.*\[/, "", k) + sub(/\\?\]$/, "", k) + if (length(k) > 1 && !((k SUBSEP file) in seen)) { + seen[k SUBSEP file] = 1 + cited[++n] = k SUBSEP file + } + rest = substr(rest, RSTART + RLENGTH) + } +} + +END { + for (i = 1; i <= n; i++) { + split(cited[i], part, SUBSEP) + if (!(part[1] in defined)) print lang "\t" part[2] "\t" part[1] + } +} +AWK +) + +# Keys cited with no reference entry anywhere, deliberately left that way while +# their owner decides what they should point at. Everything else is fatal +# already; delete an entry here the moment its citation is fixed or dropped, and +# the check becomes fatal for it -- a stale entry is reported as such, so the +# list cannot quietly outlive the problem it documents. +# +# Empty, and meant to stay that way: it held OSI (docs/em002-3.adoc) and OSI2019 +# (docs/em002-1.adoc) until the owner decided what they should point at, and both +# citations were corrected. Add a key here only to park a citation an owner has +# yet to rule on, one per line with the document and the question, like +# +# known_unresolved=( +# Xy2026 # docs/em002-4.adoc -- entry promised for the 2026 revision +# ) +known_unresolved=() + +if ! unresolved=$( + for lang in "${languages[@]}"; do + printf '%s' "${manifest}" | + asciidoctor-reducer \ + --attribute lang="${lang}" \ + --attribute doctype=book \ + --output - \ + - | + awk -v lang="${lang}" -v marker="${marker}" "${program}" + done +); then + echo "check-asciidoc.sh: could not flatten the corpus to check citations" >&2 + exit 1 +fi + +pending=() +while IFS=$'\t' read -r lang file key; do + [[ -n "${key}" ]] || continue + if [[ " ${known_unresolved[*]} " == *" ${key} "* ]]; then + case " ${pending[*]-} " in + *" ${key} "*) ;; + *) pending+=("${key}") ;; + esac + else + echo "check-asciidoc.sh: ${file} (${lang}): [${key}] is cited with no reference entry" >&2 + status=1 + fi +done <<<"${unresolved}" + +for key in "${known_unresolved[@]}"; do + case " ${pending[*]-} " in + *" ${key} "*) ;; + *) + echo "check-asciidoc.sh: [${key}] now resolves; drop it from known_unresolved in ${BASH_SOURCE[0]}" >&2 + status=1 + ;; + esac +done + +if [[ "${#pending[@]}" -gt 0 ]]; then + echo "check-asciidoc.sh: still cited with no reference entry, by agreement: ${pending[*]}" >&2 +fi + +exit "${status}" diff --git a/tools/make-four-cs-svg.sh b/tools/make-four-cs-svg.sh new file mode 100755 index 0000000..349006c --- /dev/null +++ b/tools/make-four-cs-svg.sh @@ -0,0 +1,105 @@ +#!/usr/bin/env bash +# Generate the "four Cs" gear graphic, one SVG per language, into +# docs/assets/four-cs/. +# +# Why a generator rather than ten hand-written files: the graphic is four gears +# whose geometry is identical in every language and whose only translated parts +# are the "(Use)" gloss on Consumption and, in the `cases` variant, the two case +# labels. Ten copies of the same 60 teeth would drift the first time anyone +# nudged a radius. +# +# Why SVG rather than the PNGs this replaced: the labels become real text, so +# they are translatable, greppable and selectable in the PDF, and the file is a +# few kB instead of 200. The PNGs had no editable source in the repository at +# all -- this script is that source. +# +# The four C-words are deliberately NOT translated. `Consumption`, +# `Contribution`, `Collaboration` and `Creation` are terms of art -- the German, +# French, Italian and Romansh bodies all use them untranslated ("die 4 C", "les +# 4 C", "ils 4 C"), so translating them here would contradict the prose. The +# framing words around them are ordinary prose and are translated, including in +# the accessible name. +# +# Usage: tools/make-four-cs-svg.sh # regenerate every file +set -euo pipefail + +here=$(dirname "$0") +cd "${here}/.." + +out_dir="docs/assets/four-cs" +mkdir -p "${out_dir}" + +# Colours are read off the bitmaps this replaces, so the figure keeps its +# familiar look. They are the figure's own, not CD Bund tokens: this is a cited +# graphic, not a chart the project styles. +col_collab="#9e2b25" +col_consum="#7ba63f" +col_contrib="#2f6fa8" +col_create="#dd8127" + +font='Liberation Sans, Helvetica, Arial, sans-serif' + +# gear +# A gear is an annulus plus N tooth rectangles placed by `rotate()`, which keeps +# the script free of trigonometry. +gear() { + awk -v cx="$1" -v cy="$2" -v r="$3" -v w="$4" -v n="$5" -v c="$6" -v fill="$7" ' + BEGIN { + printf " \n", cx, cy, r, fill, c, w + tw = r * 0.30; th = w * 0.62 + for (i = 0; i < n; i++) { + a = 360.0 * i / n + printf " \n", \ + cx - tw / 2, cy - r - w / 2 - th + 1, tw, th + 2, tw * 0.18, c, a, cx, cy + } + }' +} + +# emit +# A non-empty adds the divider variant used by Em002-5. +emit() { + local lang="$1" use="$2" lead="$3" case_a="${4:-}" case_b="${5:-}" + local name="four-cs" title="${lead}: Consumption, Contribution, Collaboration, Creation" + if [[ -n "${case_a}" ]]; then + name="four-cs-cases" + fi + + { + printf '\n' "${title}" + printf ' %s\n' "${title}" + + # Collaboration is the gear the other three turn inside, so it is drawn + # first and left unfilled. + gear 290 312 232 40 14 "${col_collab}" none + gear 192 196 124 42 12 "${col_consum}" "#ffffff" + gear 479 206 84 34 10 "${col_contrib}" "#ffffff" + gear 428 462 67 30 10 "${col_create}" "#ffffff" + + printf ' Consumption\n' "${font}" + printf ' (%s)\n' "${font}" "${use}" + printf ' Contribution\n' "${font}" + printf ' Creation\n' "${font}" + printf ' Collaboration\n' "${font}" + + if [[ -n "${case_a}" ]]; then + printf ' \n' + printf ' %s\n' "${font}" "${case_a}" + printf ' %s\n' "${font}" "${case_b}" + fi + + printf '\n' + } > "${out_dir}/${name}.${lang}.svg" + echo "wrote ${out_dir}/${name}.${lang}.svg" +} + +emit en "Use" "The four Cs" +emit de "Nutzung" "Die 4 C" +emit fr "utilisation" "Les 4 C" +emit it "uso" "Le 4 C" +emit rm "utilisaziun" "Ils 4 C" + +emit en "Use" "The four Cs" "case a)" "case b)" +emit de "Nutzung" "Die 4 C" "Fall a)" "Fall b)" +emit fr "utilisation" "Les 4 C" "cas a)" "cas b)" +emit it "uso" "Le 4 C" "caso a)" "caso b)" +emit rm "utilisaziun" "Ils 4 C" "cas a)" "cas b)" diff --git a/tools/open-govpress.sh b/tools/open-govpress.sh new file mode 100755 index 0000000..b842c35 --- /dev/null +++ b/tools/open-govpress.sh @@ -0,0 +1,65 @@ +#!/usr/bin/env bash +# +# Run the open-govpress CLI that renders these .adoc documents to PDF. +# +# tools/open-govpress.sh render ... -o out.pdf +# +# Not meant to be called directly: the `open-govpress` devenv script is the way +# in, and it supplies the environment below from Nix. The logic lives here +# rather than in devenv.nix so that shellcheck and editorconfig-checker can see +# it -- shell embedded in a Nix string is invisible to both. +# +# 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. +# +# Environment (all set by the devenv wrapper): +# GOVPRESS_VERSION release version, also the directory name in the tarball +# GOVPRESS_URL release asset to download +# GOVPRESS_SHA256 expected checksum of that asset +# GOVPRESS_FHS FHS-env wrapper the dynamically-linked binary needs +# GOVPRESS_XVFB_RUN xvfb-run binary +# GOVPRESS_CURL curl binary +# GOVPRESS_SHA256SUM sha256sum binary + +set -euo pipefail + +: "${GOVPRESS_VERSION:?GOVPRESS_VERSION is required}" +: "${GOVPRESS_URL:?GOVPRESS_URL is required}" +: "${GOVPRESS_SHA256:?GOVPRESS_SHA256 is required}" +: "${GOVPRESS_FHS:?GOVPRESS_FHS is required}" +: "${GOVPRESS_XVFB_RUN:?GOVPRESS_XVFB_RUN is required}" +: "${GOVPRESS_CURL:?GOVPRESS_CURL is required}" +: "${GOVPRESS_SHA256SUM:?GOVPRESS_SHA256SUM is required}" + +here=$(dirname "${BASH_SOURCE[0]}") +here=$(cd "${here}" && pwd) +root=$(cd "${here}/.." && pwd) +cd "${root}" + +cache_dir="${root}/open-govpress/.cache" +archive="${cache_dir}/open-govpress-${GOVPRESS_VERSION}-linux-x64.tar.gz" +extract_dir="${root}/open-govpress/.extracted" +bin="${extract_dir}/open-govpress-${GOVPRESS_VERSION}/open-govpress" + +if [[ ! -x "${bin}" ]]; then + mkdir -p "${cache_dir}" "${extract_dir}" + + if [[ ! -f "${archive}" ]]; then + # Download to .part and rename, so an interrupted download cannot be + # mistaken for a complete one on the next run. + "${GOVPRESS_CURL}" -fL --retry 3 -o "${archive}.part" "${GOVPRESS_URL}" + mv "${archive}.part" "${archive}" + fi + + echo "${GOVPRESS_SHA256} ${archive}" | "${GOVPRESS_SHA256SUM}" -c - + tar xzf "${archive}" -C "${extract_dir}" +fi + +exec "${GOVPRESS_FHS}" "${GOVPRESS_XVFB_RUN}" -a "${bin}" --no-sandbox "${@}" diff --git a/tools/render-docs.sh b/tools/render-docs.sh new file mode 100755 index 0000000..5709b1a --- /dev/null +++ b/tools/render-docs.sh @@ -0,0 +1,70 @@ +#!/usr/bin/env bash +# +# Build the whole published site locally. +# +# tools/render-docs.sh [lang...] +# +# 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. +# +# Reached through the `render-docs` devenv script, which is also what puts +# `open-govpress` on the PATH this needs. + +set -euo pipefail + +here=$(dirname "${BASH_SOURCE[0]}") +here=$(cd "${here}" && pwd) +root=$(cd "${here}/.." && pwd) +cd "${root}" + +all_languages=(en de fr it rm) + +if [[ "$#" -gt 0 ]]; then + langs=("${@}") +else + langs=("${all_languages[@]}") +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 + +# `docs/partials/` is excluded: it holds fragments that are `include::`d into +# the documents -- the shared document map, say -- and a fragment is not a +# document. On its own it has no title and no ifeval:: block, so it would render +# as a near-empty PDF and take a row in the language index. +tracked=$(git ls-files '*.adoc' ':!docs/partials/*') + +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 + [[ -n "${doc}" ]] || continue + 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 <<<"${tracked}" + + 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-archive.sh b/tools/site-archive.sh new file mode 100755 index 0000000..a62f207 --- /dev/null +++ b/tools/site-archive.sh @@ -0,0 +1,159 @@ +#!/usr/bin/env bash +# +# Write the index of archived builds at the root of the published site. +# +# tools/site-archive.sh +# +# is the accumulated site tree, which holds a copy of every build that is +# still retained: +# +# /tags// a released version, kept forever +# /commits// a build of the published branch, newest few only +# +# Each of those carries the `build-meta.txt` that site-publish.sh wrote, and +# this page is generated purely by reading them back -- so a build that was +# pruned from the tree disappears from the listing by construction, and no +# separate bookkeeping file can drift out of sync with what is actually there. +# +# Environment: +# PUBLISH_BRANCH the branch `commits/` holds builds of, named in the page +# copy (default main; site-publish.sh passes its own) + +set -euo pipefail + +dir="${1:?usage: site-archive.sh }" +publish_branch="${PUBLISH_BRANCH:-main}" + +escape() { sed -e 's/&/\&/g' -e 's//\>/g' -e 's/"/\"/g'; } + +# escape(), but for a value already in hand rather than on stdin. Pulled out of +# the format arguments below because `"$(printf ... | escape)"` inside a command +# substitution hides the exit status of everything in the pipe. +escaped() { + local value="$1" out + out=$(printf '%s' "${value}" | escape) + printf '%s' "${out}" +} + +# Read one `keyvalue` field out of a build-meta.txt. +meta_field() { + local file="$1" key="$2" + awk -F'\t' -v k="${key}" '$1 == k { sub(/^[^\t]*\t/, ""); print; exit }' "${file}" +} + +# Emit the
  • entries for one archive directory, newest first. +# +# Sorting is on the `epoch` field rather than on the directory name: commit +# directories are named by hash, which has no useful order, and tags sort by +# release date rather than by the accident of their spelling. +emit_entries() { + local subdir="$1" rows=() metas name epoch sorted + local meta date subject subdir_html name_html subject_html when_html + + [[ -d "${dir}/${subdir}" ]] || return 0 + + metas=$(find "${dir}/${subdir}" -mindepth 2 -maxdepth 2 -name build-meta.txt | sort) + + while IFS= read -r meta; do + [[ -f "${meta}" ]] || continue + name=$(dirname "${meta}") + name=$(basename "${name}") + epoch=$(meta_field "${meta}" epoch) + rows+=("${epoch:-0} ${name} ${meta}") + done <<<"${metas}" + + [[ ${#rows[@]} -gt 0 ]] || return 0 + + sorted=$(printf '%s\n' "${rows[@]}" | sort -rn -t' ' -k1,1) + + while IFS=$'\t' read -r _ name meta; do + [[ -n "${meta}" ]] || continue + date=$(meta_field "${meta}" date) + subject=$(meta_field "${meta}" subject) + subdir_html=$(escaped "${subdir}") + name_html=$(escaped "${name}") + subject_html=$(escaped "${subject}") + when_html=$(escaped "${date%T*}") + printf '
  • %s%s%s
    • \n' \ + "${subdir_html}" \ + "${name_html}" \ + "${name_html}" \ + "${subject_html}" \ + "${when_html}" + done <<<"${sorted}" +} + +{ + cat <<'HTML' + + + + +Archived builds — Open Source Guidelines + +HTML + + # Out of the heredoc above because that one is quoted, which is what keeps + # the CSS free of accidental expansion. The branch name is a repository + # variable rather than a literal, so it goes through escape() like every + # other value that reaches the page. + branch_html=$(escaped "${publish_branch}") + + printf '

    Archived builds

    \n' + printf '

    Each entry is the complete set of documents, in all languages, as\nthey stood at that point. Released versions are kept permanently; builds of the\n%s branch are kept for the most recent commits only.

    \n' \ + "${branch_html}" + + echo '

    Releases

    ' + tags=$(emit_entries tags) + if [[ -n "${tags}" ]]; then + printf '
      \n%s\n
    \n' "${tags}" + else + echo '

    No release has been tagged yet.

    ' + fi + + printf '

    Recent builds of %s

    \n' "${branch_html}" + commits=$(emit_entries commits) + if [[ -n "${commits}" ]]; then + printf '
      \n%s\n
    \n' "${commits}" + else + echo '

    No build has been archived yet.

    ' + fi + + cat <<'HTML' + + +HTML +} > "${dir}/archive.html" + +echo "wrote ${dir}/archive.html" diff --git a/tools/site-index.sh b/tools/site-index.sh new file mode 100755 index 0000000..5bebfb6 --- /dev/null +++ b/tools/site-index.sh @@ -0,0 +1,160 @@ +#!/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 }" + +# `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." + back="All languages" ;; + de) heading="Hilfsmittel zur Veröffentlichung von Open-Source-Software" + 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." + back="Toutes les langues" ;; + it) heading="Strumenti per la pubblicazione di software open source" + 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." + back="Tut las linguas" ;; + *) echo "site-index.sh: unknown language '${lang}'" >&2; exit 1 ;; +esac + +escape() { sed -e 's/&/\&/g' -e 's//\>/g' -e 's/"/\"/g'; } + +# escape(), but for a value already in hand rather than on stdin. Pulled out of +# the format arguments below because `"$(printf ... | escape)"` inside a command +# substitution hides the exit status of everything in the pipe. +escaped() { + local value="$1" out + out=$(printf '%s' "${value}" | escape) + printf '%s' "${out}" +} + +# 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 stem + title=$(awk -v lang="${lang}" ' + /^ifeval::\["\{lang\}" == "/ { inblock = ($0 ~ "\"" lang "\"]$"); next } + /^endif::\[\]/ { inblock = 0; next } + inblock && /^= / { sub(/^= /, ""); print; exit } + ' "${src}") + if [[ -z "${title}" ]]; then + stem=$(basename "${src}" .adoc) + title="${stem}" + fi + printf '%s' "${title}" +} + +# basename -> source path, so a rendered PDF can be traced back to its document. +# `docs/partials/` is excluded: it holds fragments that are `include::`d into +# the documents, and a fragment has no PDF of its own to trace back to. +declare -A source_of +adoc_files=$(git ls-files '*.adoc' ':!docs/partials/*') +while IFS= read -r src; do + [[ -n "${src}" ]] || continue + stem=$(basename "${src}" .adoc) + source_of["${stem}"]="${src}" +done <<<"${adoc_files}" + +heading_html=$(escaped "${heading}") +lead_html=$(escaped "${lead}") +back_html=$(escaped "${back}") + +{ + cat < + + + +${heading_html} + +

    ${heading_html}

    +

    ${lead_html}

    +
      +HTML + + # index first, then the documents in natural order (em002, em002-1, em002-2-1, …). + pdf_list=$(cd "${dir}" && find . -maxdepth 1 -type f -name '*.pdf' | sort -V) + ordered=() + [[ -f "${dir}/index.pdf" ]] && ordered+=("index.pdf") + while IFS= read -r pdf; do + # find prints ./name; the prefix comes straight back off. + pdf="${pdf#./}" + [[ -n "${pdf}" ]] || continue + [[ "${pdf}" = "index.pdf" ]] && continue + ordered+=("${pdf}") + done <<<"${pdf_list}" + + for pdf in ${ordered+"${ordered[@]}"}; do + stem="${pdf%.pdf}" + src="${source_of[${stem}]:-}" + if [[ -n "${src}" ]]; then + label=$(doc_title "${src}") + else + label="${stem}" + fi + pdf_html=$(escaped "${pdf}") + label_html=$(escaped "${label}") + printf '
    • %s%sPDF
      • \n' \ + "${pdf_html}" \ + "${label_html}" \ + "${pdf_html}" + done + + cat < + + +HTML +} > "${dir}/index.html" + +echo "wrote ${dir}/index.html ($((${#ordered[@]})) documents)" diff --git a/tools/site-publish.sh b/tools/site-publish.sh new file mode 100755 index 0000000..aedae10 --- /dev/null +++ b/tools/site-publish.sh @@ -0,0 +1,205 @@ +#!/usr/bin/env bash +# +# Overlay a freshly rendered site onto the accumulated published tree. +# +# tools/site-publish.sh +# +# GitHub Pages deployments are whole-site snapshots: `actions/deploy-pages` +# replaces everything each time and offers no way to read back what is already +# published. Keeping older builds around therefore needs somewhere to remember +# them between runs, and that somewhere is the `site-history` branch -- cloned +# here, overlaid with the build that was just rendered, and pushed back. The +# caller then uploads the whole of as the Pages artifact, so the +# deployment stays a snapshot while its *contents* accumulate. +# +# Where the build lands depends on the ref: +# +# refs/tags/ -> tags// kept forever, root untouched +# the published branch -> commits// pruned to $KEEP_COMMITS, and the root +# +# The root keeps meaning "current head of the published branch", which is what +# the site has always meant. A tag archives itself without disturbing it. +# +# Which branch that is comes from $PUBLISH_BRANCH, defaulting to main. Any other +# branch is refused rather than published: this script replaces the site root, +# and the workflow's own gate is a condition in a YAML file that a future edit +# could get wrong. Two independent checks on the same variable is the point. +# +# Environment: +# GITHUB_REPOSITORY owner/repo, used to build the push URL +# GITHUB_REF_TYPE `branch` or `tag` +# GITHUB_REF_NAME branch or tag name +# GITHUB_SHA commit being published +# GITHUB_RUN_ID recorded in build-meta.txt, for tracing a build back +# GH_TOKEN token with contents:write +# PUBLISH_BRANCH the branch that owns the site root (default main) +# KEEP_COMMITS how many branch builds to retain (default 10) +# SITE_REMOTE override the push URL (tests point this at a bare repo) +# SITE_BRANCH override the accumulator branch (default site-history) +# +# Never run this under `set -x`: the push URL carries the token. + +set -euo pipefail + +site="${1:?usage: site-publish.sh }" +work="${2:?usage: site-publish.sh }" + +here=$(dirname "${BASH_SOURCE[0]}") +here=$(cd "${here}" && pwd) + +: "${GITHUB_REF_TYPE:?GITHUB_REF_TYPE is required}" +: "${GITHUB_REF_NAME:?GITHUB_REF_NAME is required}" +: "${GITHUB_SHA:?GITHUB_SHA is required}" + +branch="${SITE_BRANCH:-site-history}" +publish_branch="${PUBLISH_BRANCH:-main}" +keep="${KEEP_COMMITS:-10}" +run="${GITHUB_RUN_ID:-unknown}" + +case "${keep}" in + ''|*[!0-9]*|0) + echo "site-publish.sh: KEEP_COMMITS must be a positive integer, got '${keep}'" >&2 + exit 1 + ;; + *) ;; +esac + +[[ -d "${site}" ]] || { echo "site-publish.sh: no such directory: ${site}" >&2; exit 1; } + +if [[ -n "${SITE_REMOTE:-}" ]]; then + remote="${SITE_REMOTE}" +else + : "${GITHUB_REPOSITORY:?GITHUB_REPOSITORY is required}" + : "${GH_TOKEN:?GH_TOKEN is required}" + # The token is interpolated at run time, so the literal here is a URL shape + # rather than a credential. ripsecrets only honours the pragma on the line + # it is attached to, hence the trailing comment. + remote="https://x-access-token:${GH_TOKEN}@github.com/${GITHUB_REPOSITORY}.git" # pragma: allowlist secret +fi + +# Which slot this build occupies, and whether it also becomes the root. +short="${GITHUB_SHA:0:8}" +case "${GITHUB_REF_TYPE}" in + tag) + slot="tags/${GITHUB_REF_NAME}" + update_root=0 + ;; + branch) + [[ "${GITHUB_REF_NAME}" = "${publish_branch}" ]] || { + echo "site-publish.sh: refusing to publish branch '${GITHUB_REF_NAME}'; PUBLISH_BRANCH is '${publish_branch}'" >&2; exit 1; } + slot="commits/${short}" + update_root=1 + ;; + *) + echo "site-publish.sh: unexpected GITHUB_REF_TYPE '${GITHUB_REF_TYPE}'" >&2 + exit 1 + ;; +esac + +# Only the files are wanted, never the branch's history -- see the force-push at +# the bottom for why. A missing branch is the normal first run, not an error. +rm -rf "${work}" +if git clone --quiet --depth 1 --branch "${branch}" "${remote}" "${work}" 2>/dev/null; then + echo "cloned ${branch}" +else + echo "${branch} does not exist yet, starting an empty tree" + mkdir -p "${work}" +fi +rm -rf "${work}/.git" + +# The root holds the languages and the chooser; clearing them first is what +# makes a document that was deleted from the sources disappear from the site +# rather than linger as an orphaned PDF. `commits/`, `tags/` and `archive.html` +# are deliberately left in place -- they are the accumulated part. +if [[ "${update_root}" = 1 ]]; then + rm -rf \ + "${work}"/en \ + "${work}"/de \ + "${work}"/fr \ + "${work}"/it \ + "${work}"/rm \ + "${work}"/index.html + cp -a "${site}"/. "${work}"/ + echo "updated the site root" +fi + +rm -rf "${work:?}/${slot}" +mkdir -p "${work}/${slot}" +cp -a "${site}"/. "${work}/${slot}"/ +echo "archived the build as ${slot}" + +# Taken from the commit rather than from the clock, so re-rendering the same +# commit reproduces the same metadata instead of reshuffling the archive order. +date=$(git log -1 --format=%cI "${GITHUB_SHA}" 2>/dev/null || echo "") +epoch=$(git log -1 --format=%ct "${GITHUB_SHA}" 2>/dev/null || echo "0") +subject=$(git log -1 --format=%s "${GITHUB_SHA}" 2>/dev/null || echo "") + +printf '%s\t%s\n' \ + ref "${GITHUB_REF_NAME}" \ + type "${GITHUB_REF_TYPE}" \ + sha "${GITHUB_SHA}" \ + short "${short}" \ + date "${date}" \ + epoch "${epoch}" \ + subject "${subject}" \ + run "${run}" \ + > "${work}/${slot}/build-meta.txt" + +# Prune branch builds to the newest $keep. Tags are never pruned: a release needs +# a URL that keeps working. Ordering is by the recorded commit date, since the +# directory names are hashes and sort arbitrarily. +if [[ -d "${work}/commits" ]]; then + metas=$(find "${work}/commits" -mindepth 2 -maxdepth 2 -name build-meta.txt) + + dated="" + while IFS= read -r meta; do + [[ -n "${meta}" ]] || continue + meta_epoch=$(awk -F'\t' '$1 == "epoch" { print $2; exit }' "${meta}") + meta_dir=$(dirname "${meta}") + dated+=$(printf '%s\t%s\n' "${meta_epoch}" "${meta_dir}")$'\n' + done <<<"${metas}" + + stale=() + if [[ -n "${dated}" ]]; then + pruned=$(printf '%s' "${dated}" | sort -rn -t$'\t' -k1,1 | tail -n "+$((keep + 1))") + while IFS=$'\t' read -r _ stale_dir; do + [[ -n "${stale_dir}" ]] || continue + stale+=("${stale_dir}") + done <<<"${pruned}" + fi + + for stale_dir in ${stale+"${stale[@]}"}; do + rm -rf "${stale_dir}" + pruned_name=$(basename "${stale_dir}") + echo "pruned ${pruned_name}" + done +fi + +# Passed on so the archive page names the branch it is actually listing builds +# of, rather than saying "main" on a site published from somewhere else. +PUBLISH_BRANCH="${publish_branch}" "${here}/site-archive.sh" "${work}" + +# Regenerate the chooser so it picks up the archive link. Skipped when the root +# is still empty, which happens if a tag is pushed before main has ever built -- +# a chooser listing no languages would be worse than none at all. +for lang in en de fr it rm; do + if [[ -d "${work}/${lang}" ]]; then + "${here}/site-root.sh" "${work}" + break + fi +done + +# One parentless commit, force-pushed. PDFs are re-rendered on every run and so +# are new blobs even when their content is unchanged; keeping history would add +# the full weight of the site to the branch every time, and deleting a pruned +# directory at the tip would reclaim none of it. The branch is derived output, +# so discarding its history costs nothing that cannot be re-rendered. +git -c init.defaultBranch=publish init -q "${work}" +git -C "${work}" add -A +git -C "${work}" \ + -c user.name='github-actions[bot]' \ + -c user.email='41898282+github-actions[bot]@users.noreply.github.com' \ + -c commit.gpgsign=false \ + commit -q -m "Publish ${GITHUB_REF_NAME} (${short})" +git -C "${work}" push -q --force "${remote}" "HEAD:refs/heads/${branch}" +echo "pushed ${slot} to ${branch}" diff --git a/tools/site-root.sh b/tools/site-root.sh new file mode 100755 index 0000000..bd952bd --- /dev/null +++ b/tools/site-root.sh @@ -0,0 +1,99 @@ +#!/usr/bin/env bash +# +# Write the language chooser at the root of the published site. +# +# tools/site-root.sh +# +# Lists only the language directories that were actually built, so a language +# whose render job failed is absent rather than a dead link. + +set -euo pipefail + +dir="${1:?usage: site-root.sh }" + +# Endonyms, left untranslated by convention: a reader looking for their own +# language recognises its own name, not its name in someone else's. +label_of() { + case "${1}" in + en) echo "English" ;; + de) echo "Deutsch (Schweiz)" ;; + fr) echo "Français (Suisse)" ;; + it) echo "Italiano (Svizzera)" ;; + rm) echo "Rumantsch (Svizra)" ;; + *) echo "${1}" ;; + esac +} + +{ + cat <<'HTML' + + + + +Open Source Guidelines + +

      Open Source Guidelines

      +

      Tools for publishing open source software in the Swiss Federal +Administration. Choose a language.

      +
        +HTML + + for lang in en de fr it rm; do + [[ -d "${dir}/${lang}" ]] || continue + label=$(label_of "${lang}") + printf '
      • %s%s
        • \n' \ + "${lang}" "${label}" "${lang}" + done + + cat <<'HTML' +
      + + +HTML +} > "${dir}/index.html" + +echo "wrote ${dir}/index.html"