Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Source release: ship only the top-level LICENSE and NOTICE, not the subdirectory copies

Offen
  • Stimmt etwas nicht?
#268 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker
Bereich
build-system, release

Rechercherichtung

Start with no-release.txt and the listed Dockerfiles, especially oplugins-op/Dockerfile, streamer/Dockerfile, admin-api/Dockerfile, and the runtime image Dockerfiles. Trace how source archives and image builds consume the license files, then verify that the source tarball contains only the intended top-level files while image builds still receive their required licensing files.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

The 0.9.0-incubating-RC7 source release (apache-openserverless-0.9.0-incubating-src.tar.gz) contains the top-level LICENSE, NOTICE and DISCLAIMER, plus 85 more LICENSE/NOTICE/DISCLAIMER files in subdirectories. They come from the submodules and from each runtime image directory:

  • one set per submodule: admin-api/, build/, cli/, devcontainer/, oplugins/, oplugins-op/, runtimes/, streamer/, testing/;
  • one set per runtime image: runtimes/runtime/{go,java,nodejs,python}/*/ and runtimes/experimental/*/;
  • build/openwhisk/LICENSE.txt, NOTICE.txt and licenses/LICENSE-spray.txt (from the vendored OpenWhisk sources);
  • cli/tests/oplugins/LICENSE (test data).

Together they run to about 94,000 lines (runtimes/LICENSE alone is 37,204 lines).

Please ship only the top-level LICENSE and NOTICE in the source release, and leave the subdirectory ones out (e.g. via no-release.txt).

Why

For the source release, the top-level LICENSE and NOTICE are the ones that count. The subdirectory files mostly describe something else: the container images built from each directory, which bundle OS packages, language runtimes and dependencies that are not in the source release. Shipping them in the source tarball is confusing for users and reviewers, who cannot tell which file applies to what. It also means the same facts are maintained in many places, and they have already drifted apart. In RC7:

  • oplugins/LICENSE and oplugins-op/LICENSE state that the source distribution "is licensed in its entirety under the Apache License, Version 2.0". The top-level LICENSE correctly lists MIT, ISC and BSD-3-Clause code in the source (the pre-built JavaScript bundles), and there is more that is not yet listed (#260).
  • 20 of the subdirectory LICENSE/NOTICE files refer readers to a WARN file, but no-release.txt removes every WARN file from the source release.
  • 19 of the subdirectory NOTICE files say Copyright 2024 The Apache Software Foundation; the top-level NOTICE and 8 others say Copyright 2024-2026.
  • oplugins-op/LICENSE says the operator bundles gradlew/gradlew.bat and ConcurrentMapBackedCache.scala; neither exists under oplugins-op/.
  • Third-party content that should be attributed (cert-manager #263, Kvrocks #262, Milvus #260) is missing from the subdirectory files as well as the top-level ones. So there are two places to fix instead of one, and no place that is complete.

With only the top-level files, there is one place to review and keep correct for each release.

Things to handle

  1. Image builds use these files. 26 Dockerfiles COPY their directory's DISCLAIMER LICENSE NOTICE into the image (e.g. oplugins-op/Dockerfile:152, streamer/Dockerfile:30, admin-api/Dockerfile:47, every runtimes/runtime/*/*/Dockerfile, build/standalone/Dockerfile:47). The images do need their own LICENSE/NOTICE (as convenience binaries), so dropping the files from the source tarball needs one of:
    • generate the image LICENSE/NOTICE at image build time (they are largely derived from the image contents anyway); or
    • keep them in git but outside the source release, and have the image build (CI) supply them; or
    • if they must stay in the source tree, rename them (e.g. LICENSE-image, NOTICE-image) and add a first line saying they describe the container image, not the source, so they are not mistaken for the source release's licensing.
  2. The top-level LICENSE points at build/openwhisk/licenses/LICENSE-spray.txt. Either keep that one file, or inline the Spray licence text in the top-level LICENSE. The Spray licence is Apache-2.0, already reproduced there.
  3. build/openwhisk/LICENSE.txt / NOTICE.txt are the vendored OpenWhisk project's own files. The top-level NOTICE already carries the OpenWhisk attribution, so they can go too.
  4. Optional: the same applies to the 27 subdirectory DISCLAIMER files, which duplicate the top-level DISCLAIMER.

Related: #260, #262, #263, #267.

Vorherrschende Sprache
Python
Sterne
576
Forks
29
Ø Merge
7 Std. 7 Min.
Gemergte PRs (30 T.)
5

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/openserverless

Alle Issues in apache/openserverless

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.