Reuse compliance

.reuse/dep5

@@ -1,7 +1,7 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: <YOUR-REPO-NAME>
-Upstream-Contact: <YOUR-CONTACT (MAIL ADDRESS ETC.)>
-Source: <https://github.com/sap/YOUR-REPO-NAME>
+Upstream-Name: Kyma
+Upstream-Contact:
+Source: https://github.com/sap/community-modules
 Disclaimer: The code in this project may include calls to APIs ("API Calls") of
  SAP or third-party products or services developed outside of this project
  ("External Products").
@@ -24,14 +24,6 @@ Disclaimer: The code in this project may include calls to APIs ("API Calls") of
  you any rights to use or access any SAP External Product, or provide any third
  parties the right to use of access any SAP External Product, through API Calls.
 
-Files: <YOUR-FILE-OR-FOLDER-LIST>
-Copyright:  <YEARS-RELEVANT-FOR-YOUR-PROJECT> SAP SE or an SAP affiliate company and <YOUR-PROJECT-NAME> contributors
+Files: *
+Copyright: 2023 SAP SE or an SAP affiliate company and Kyma contributors
 License: Apache-2.0
-
-Files: <THIRD-PARTY-FILE-OR-FOLDER-LIST>
-Copyright: <COPYRIGHT-OF-THIRD-PARTY-CODE>
-License: <LICENSE-OF-THIRD-PARTY-CODE>
-
-Files: <ANOTHER-THIRD-PARTY-FILE-OR-FOLDER-LIST>
-Copyright: <COPYRIGHT-OF-ANOTHER-THIRD-PARTY-CODE>
-License: <LICENSE-OF-ANOTHER- THIRD-PARTY-CODE>

README.md

@@ -1,8 +1,10 @@
 # Kyma community modules
 
-
 > **This repository contains an early prototype, and is not meant to be used in the production use case. Feel free to try it out, leave feedback, and report issues.**
 
+## Status
+
+[![REUSE status](https://api.reuse.software/badge/github.com/kyma-project/community-modules)](https://api.reuse.software/info/github.com/kyma-project/community-modules)
 
 ## Overview
 
@@ -21,18 +23,21 @@ npm install -g kyma
 ```
 
 Now you can see available kyma modules and their versions:
+
 ```
 kyma modules
 ```
 
 You can deploy one or more modules (add option `--dry-run` to see kubectl commands without executing them):
+
 ```
 kyma deploy -m serverless nats eventing --defaultConfig --dry-run
 ```
 
 You can provide the module version by adding `:<version>` sufix to the module name. If not provided the version from the provided channel will be used, or the latest version if channel is not specified.
 
 You can also start the web interface locally:
+
 ```
 kyma ui
 ```
@@ -46,38 +51,42 @@ Sample view for managed Kyma Runtime:
 
 ![](modules-ui.png)
 
-
 ## Run (develop) locally
 
 Prepare your development cluster and configure kubectl (KUBECONFIG). Then execute:
+
 ```
 npm install
 npm run build-modules
 npm run dev
 ```
-Now open the provided URL, e.g.: `http://localhost:5173`
 
+Now open the provided URL, e.g.: `http://localhost:5173`
 
 ## Module contribution guideline
 
-The module defines a single Kubernetes custom resource (CR) and a controller that manages it. The controller is responsible for the lifecycle of the module. It creates and deletes the module's resources based on the custom resource state. 
+The module defines a single Kubernetes custom resource (CR) and a controller that manages it. The controller is responsible for the lifecycle of the module. It creates and deletes the module's resources based on the custom resource state.
 
 ### Dependencies
+
 The module is self-contained and should not depend on any other Kyma components directly. The only exception is the dependency to the APIs provided by other modules. Such dependencies should be handled by the controller in the transparent way, by reporting missing APIs and suggesting the installation of the required modules.
 
 ### Releases
 
 The module release should be versioned and follow the [semantic versioning](https://semver.org/) rules. Two artifacts are released for each module version:
+
 - kubernetes manifest that deploys the module operator (CRD, RBAC, Deployment, Service, etc.)
 - default configuration for the module (custom resource)
 The new release should handle the previous version of the module configuration. The module should be able to upgrade the configuration from the previous version to the current one. The upgrade process should be handled by the controller. The module provider should test upgrade scenarios to ensure that no additional manual steps are required to upgrade the module.
 
 ### Configuration
+
 The default configuration for the module should be provided as a Kubernetes custom resource and should be applied only once during module installation. Once the configuration is applied it is owned by the user (admin) and should not be modified by the module. The module should not modify the configuration except for the cases when the configuration is migrated to the new version. The module should not delete the configuration. The configuration should be deleted by the user (admin) before the module is uninstalled.
 
 ## Adding a new module
 
 Edit the `modules.js` file and add a new entry to the `modules` list. The entry should contain the following fields:
+
 - `name` - the name of the module
 - `documentation` - the link to the module documentation
 - `repository` - the link to the module repository
@@ -86,8 +95,8 @@ Edit the `modules.js` file and add a new entry to the `modules` list. The entry
 - `latestGithubRelease` - the information about the latest GitHub release of the module
 - `versions` - the list of the module versions. Each version can override the `latestGithubRelease` information by providing the `deploymentYaml` and `crYaml` fields with urls to the deployment and CR manifests.
 
-
 Sample entry:
+
 ```js
   {
     "name": "btp-operator",
@@ -116,12 +125,13 @@ Sample entry:
   }
 ```
 
-
 If you want to test your module, you can have to regenerate modules:
+
 ```
 npm run build-modules
 npm run dev
 ```
+
 ## Contributing
 
 For standard contribution rules see [CONTRIBUTING.md](CONTRIBUTING.md).