Delete outdated notice

[SebastianSchildt]

NOTICE is outdated and not used anymore

(all required dependencies are seen up-to-date in package manager files, and exact transitive dependencies depend on the build environment, and as such can not be documented in code anyway. For our release artifacts we DO generate sboms, and add them to the artifacts where they belong)

[SebastianSchildt]

@erikbosch can you test/check if/how that affects release workflow and maybe give me pointers howto fix?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.74%. Comparing base (e628c46) to head (3a80326).
Report is 4 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #13      +/-   ##
==========================================
+ Coverage   48.61%   48.74%   +0.12%     
==========================================
  Files          31       31              
  Lines       10879    10839      -40     
==========================================
- Hits         5289     5283       -6     
+ Misses       5590     5556      -34     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[erikbosch]

If we are to remove NOTICE.md we should also remove it from https://github.com/eclipse-kuksa/kuksa-databroker/blob/main/.github/workflows/create_draft_release.yml#L93, then running that workflow should be no problem. It "entered" the release as the release action I created was based on https://github.com/eclipse/kuksa.val.services/blob/main/.github/workflows/release.yml where we also include NOTICE.md

But I am not sure if we "just" shall delete it. First, many of our license headers as of today refer to the NOTICE file like this:

https://github.com/eclipse-kuksa/kuksa-databroker/blob/main/databroker/src/broker.rs

/********************************************************************************
* Copyright (c) 2022 Contributors to the Eclipse Foundation
*
* See the NOTICE file(s) distributed with this work for additional
* information regarding copyright ownership.
*
* This program and the accompanying materials are made available under the
* terms of the Apache License 2.0 which is available at
* http://www.apache.org/licenses/LICENSE-2.0
*
* SPDX-License-Identifier: Apache-2.0
********************************************************************************/

If using our style of copyright line it seems to be recommended practice to have a NOTICE file, see https://www.eclipse.org/projects/handbook/#ip-copyright-headers. For kuksa-incubation we have a NOTICE as well, but without third party info. So should we note have a notice file and include it in the release as long as we refer to it from license headers, as it says "See the NOTICE file(s) distributed with this work". If it is OK to remove the NOTICE file, is it then a need to keep the reference in the license header?

The Eclipse recommendations on Notice file seem to be quite rigid and possibly outdated if a project auto-generate SBOMs. A pragamatic way if we decide to keep the NOTICE file could possibly be to instead of stating third party licenses explain where to find that info, i.e. explain how/where you can find the data for a specific release, latest main or your specific build.

We should better come up with "our preferred way" and then try to align that in all eclipse-kuksa repos

[SebastianSchildt]

Didn't want to change all headers (and potentially violate the requirment/recommendation to have a NOTICE file). I liked the KUKSA incubation version and adapted it.

May understanding would be, the only time we declare Third party licenses in a NOTICE.m would be if we copy some code of other projects INTO this repository (i.e. take some MIT code form somewhere, check it in, potentially even adding Apache license), in that case we would need to reference this. For dependencies during the build process a static notice is impossible. I added a general segment explaining about dependencies.

[erikbosch]

Some minor spelling errors that we better shall fix before merging, but in general looking good

[SebastianSchildt]

Done, still needs a "fresh" approve

[lukasmittag]

LGTM