eclipse-kuksa / kuksa-databroker

A modern in-vehicle VSS (Vehicle Signal Specification) server written in RUST
https://eclipse-kuksa.github.io/kuksa-website/
Apache License 2.0
12 stars 11 forks source link

Delete outdated notice #13

Closed SebastianSchildt closed 2 months ago

SebastianSchildt commented 3 months ago

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 commented 3 months ago

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

codecov-commenter commented 3 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

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

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

Additional details and impacted files ```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

erikbosch commented 3 months ago

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 commented 3 months ago

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.

SebastianSchildt commented 2 months ago

Done, still needs a "fresh" approve