docs: Update README and LICENSE, add CHANGELOG, and import archetype

.github/dependabot.yml

@@ -0,0 +1,7 @@
+version: 2
+updates:
+  # Maintain dependencies for GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "daily"

.github/workflows/autobug.yaml

@@ -0,0 +1,22 @@
+name: Auto Assign Issues to Triage column in Sprint Planning Project Board
+
+on:
+  issues:
+    types: [opened]
+
+permissions:  # added using https://github.com/step-security/secure-workflows
+  contents: read
+
+jobs:
+  issue_opened:
+    name: issue_opened
+    runs-on: ubuntu-latest
+    steps:
+      - name: 'Move issue to "Triage"'
+        uses: leonsteinhaeuser/project-beta-automations@d1c1261558118c0876fdb2b57a649303925e5a70 # v2.1.0
+        with:
+          gh_token: ${{ secrets.MY_GITHUB_TOKEN }}
+          organization: atsign-foundation
+          project_id: 8
+          resource_node_id: ${{ github.event.issue.node_id }}
+          status_value: "Triage"

CHANGELOG.md

@@ -0,0 +1,17 @@
+# 1.0.2
+
+- Established this CHANGELOG
+- LICENSE updated to reflect fork
+- README linting and note on fork
+- Copy boilerplate from archetype
+
+# 1.0.1
+
+- Support for OpenBSD and NetBSD
+- Thread Safety for C11+ Compilers
+- Refactored uuid4.h to include/uuid/ directory
+- CMake subdirectory AND installation compatability
+
+# 1.0.0
+
+- Initial fork from [rxi/uuid4](https://github.com/rxi/uuid4)

CONTRIBUTING.md

@@ -0,0 +1,168 @@
+<h1><img width=250px src="https://atsign.dev/assets/img/atPlatform_logo_gray.svg?sanitize=true"></h1>
+
+# Contributing guidelines
+
+We 💙 [Pull Requests](https://help.github.com/articles/about-pull-requests/)
+for fixing issues or adding features. Thanks for your contribution!
+
+Please read our [code of conduct](code_of_conduct.md), which is based on
+[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.0-4baaaa.svg)](code_of_conduct.md)
+
+For small changes, especially documentation, you can simply use the "Edit" button
+to update the Markdown file, and start the
+[pull request](https://help.github.com/articles/about-pull-requests/) process.
+Use the preview tab in GitHub to make sure that it is properly
+formatted before committing. Please use conventional commits and follow the
+semantic PR format as documented
+[here](https://github.com/atsign-foundation/.github/blob/trunk/atGitHub.md#semantic-prs).
+A pull request will cause integration tests to run automatically, so please review
+the results of the pipeline and correct any mistakes that are reported.
+
+If you plan to contribute often or have a larger change to make, it is best to
+setup an environment for contribution, which is what the rest of these guidelines
+describe. The atsign-foundation GitHub organization's conventions and
+configurations are documented
+[here](https://github.com/atsign-foundation/.github/blob/trunk/atGitHub.md).
+
+## Development Environment Setup
+
+### Prerequisites
+
+``` sh
+# show how to install the tools needed to work with the code here
+```
+
+### GitHub Repository Clone
+
+To prepare your dedicated GitHub repository:
+
+1. Fork in GitHub <https://github.com/atsign-foundation/uuid4>
+2. Clone *your forked repository* (e.g., `git clone [email protected]:yourname/uuid4`)
+3. Set your remotes as follows:
+
+   ```sh
+   cd uuid4
+   git remote add upstream [email protected]:atsign-foundation/uuid4.git
+   git remote set-url upstream --push DISABLED
+   ```
+
+   Running `git remote -v` should give something similar to:
+
+   ```text
+   origin  [email protected]:yourname/uuid4.git (fetch)
+   origin  [email protected]:yourname/uuid4.git (push)
+   upstream        [email protected]:atsign-foundation/uuid4.git (fetch)
+   upstream        DISABLED (push)
+   ```
+
+   The use of `upstream --push DISABLED` is to prevent those
+   with `write` access to the main repository from accidentally pushing changes
+   directly.
+
+### Development Process
+
+1. Fetch latest changes from main repository:
+
+   ```sh
+   git fetch upstream
+   ```
+
+1. Reset your fork's `trunk` branch to exactly match upstream `trunk`:
+
+   ```sh
+   git checkout trunk
+   git reset --hard upstream/trunk
+   git push --force
+   ```
+
+   **IMPORTANT**: Do this only once, when you start working on new feature as
+   the commands above will completely overwrite any local changes in `trunk` content.
+1. Edit, edit, edit, and commit your changes to Git:
+
+   ```sh
+   # edit, edit, edit
+   git add *
+   git commit -m 'A useful commit message'
+   git push
+   ```
+
+1. How to run tests:
+
+   ``` sh
+   # explain tests here
+   ```
+
+1. Open a new Pull Request to the main repository using your `trunk` branch
+
+## atLibrary release process
+
+The Atsign Foundation produces several widgets and libraries that the app developer
+can make use of to develop apps on atProtocol. These libraries are developed in
+Dart & Flutter and published to [pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image1.png "Version flow")
+
+## Following the changes
+
+The Atsign Foundation publishes libraries and widgets to
+[https://pub.dev/publishers/atsign.org/packages](https://pub.dev/publishers/atsign.org/packages).
+Each of these libraries contains a tab called “Changelog” that shows various
+published versions and a short description of what changes that went in.
+
+![alt_text](images/image2.png "Changelog screenshot")
+
+Also the “Versions” tab shows the versions published in the reverse
+chronological order.
+
+![alt_text](images/image3.png "Versions screenshot")
+
+## Reporting a bug
+
+The best place to start reporting bugs on the libraries published by
+atProtocol would be the “View/report issues” link available on
+[pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image4.png "View/report issues highlight")
+
+Once the link is clicked, one should be redirected to GitHub repo where the
+issue can be reported by clicking on the “New issue” button.
+
+![alt_text](images/image5.png "Issues list")
+
+Clicking on the  “New issue” button should take you to the screen to choose
+where the issue is a Bug or an Enhancement.
+
+![alt_text](images/image6.png "Choose Bug report")
+
+Upon clicking on the “Get started” button against the “Bug Report” you should
+be directed to a page with a bug template provided by Atsign. Filling
+out all of the fields in the template gives Atsign a better chance to
+reproduce and fix the bug.
+
+![alt_text](images/image7.png "Filling a Bug report")
+
+## Bug fix and delivery process
+
+* Bugs will initially be placed into the Sprint Planning Board so that they
+  can be triaged, estimated and scheduled.
+* Once work on a bug is scheduled one or more engineers will be assigned to
+  fixing the bug, and story points will be allocated to match the time
+  estimated to fix the bug.
+* Progress on fixing the bug will be updated in the associated GitHub issue,
+  and reviewed during subsequent sprint planning meetings where necessary.
+* Once a fix is created we will work with the reporter to ensure that the fix
+  is appropriate to their needs, and where possible this should happen prior
+  to release to pub.dev
+
+## Closure of the bug
+
+* Where possible the issue associated with the bug should be closed by mutual
+  consent with the reporter. This could be:
+  * The reporter closing the issue because they have found a workaround.
+  * The reporter closing the issue because they are satisfied with a fix
+  provided.
+  * A team member closes the issue after the reporter leaves a comment
+  indicating that they are happy for it to be closed.
+* If the reporter does not respond within 14 calendar days then we must assume
+  that they no longer have an interest in fixing the bug and work in progress
+  can be closed out at the team’s discretion.

LICENSE

@@ -1,5 +1,6 @@
 
-Copyright (c) 2018 rxi
+Original Copyright (c) 2018 rxi
+Further work Copyright (c) 2024 Atsign
 
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of

README.md

@@ -1,8 +1,17 @@
 # uuid4
+
 A tiny C library for generating [uuid4](http://www.ietf.org/rfc/rfc4122.txt)
 strings.
 
-### Usage
+This repo has been forked from [rxi/uuid4](https://github.com/rxi/uuid4)
+in order to:
+
+* achieve greater compatability with the
+[at_c SDK](https://github.com/atsign-foundation/at_c)
+* provide compatability with ESP32
+
+## Usage
+
 [uuid4.c](src/uuid4.c?raw=1) and [uuid4.h](src/uuid4.h?raw=1) should be
 dropped into an existing project. The library contains two functions:
 one to initialize the library and one to generate a uuid4 string and
@@ -17,7 +26,7 @@ printf("%s\n", buf);
 
 `uuid4_generate()` is not thread-safe.
 
-### License
+## License
+
 This library is free software; you can redistribute it and/or modify it
 under the terms of the MIT license. See [LICENSE](LICENSE) for details.
-

SECURITY.md

@@ -0,0 +1,41 @@
+<h1><img width=250px src="https://atsign.dev/assets/img/atPlatform_logo_gray.svg?sanitize=true"></h1>
+
+# Atsign Foundation Open Source Security Policies and Procedures
+
+This document outlines security procedures and general policies for the
+Atsign Foundation Open Source projects as found on
+<https://github.com/atsign-foundation>.
+
+* [Reporting a Vulnerability](#reporting-a-vulnerability)
+* [Disclosure Policy](#disclosure-policy)
+
+## Reporting a Vulnerability
+
+The Atsign Foundation team and community take all security vulnerabilities
+seriously. Thank you for improving the security of our open source
+software. We appreciate your efforts and responsible disclosure and will
+make every effort to acknowledge your contributions.
+
+Report security vulnerabilities by emailing the Atsign security team at:
+
+    [email protected]
+
+The lead maintainer will acknowledge your email within 24 hours, and will
+send a more detailed response within 48 hours indicating the next steps in
+handling your report. After the initial reply to your report, the security
+team will endeavor to keep you informed of the progress towards a fix and
+full announcement, and may ask for additional information or guidance.
+
+Please report security vulnerabilities in third-party modules to the person
+or team maintaining the module.
+
+## Disclosure Policy
+
+When the security team receives a security bug report, they will assign it
+to a primary handler. This person will coordinate the fix and release
+process, involving the following steps:
+
+* Confirm the problem and determine the affected versions.
+* Audit code to find any potential similar problems.
+* Prepare fixes for all releases still under maintenance. These fixes
+  will be released as fast as possible to pub.dev where applicable.