AMD GitHub.com Open Source Development

AMD GitHub.com Open Source Development

A subset of the AMD GitHub repositories related to embedded platforms such as Kria SOM are now developed entirely in public GitHub repositories with a goal of a lower barrier for community contributions and faster update cycles.

These repositories do not have a tight coupling to AMD tools releases but might have coupling to non-AMD open-source dependencies. This page lists repos that are using this fully public development repository and clarifies additional checks put in place for public contributions.

Table of Contents

List of Open Source Repositories associated with Kria SOM

License Checks

 

To prevent the license files in each repositories from being altered accidentally, there is a license check script to validate any license changes made in each Pull Request through GitHub Actions. This ensures that all contributions comply with approved licenses. If a pull request fails with a license check, please ensure that the license has not been accidentally altered and that no special characters have been introduced.

When adding a new file to the repository, ensure that you include the approved license, which can be found in the repository's LICENSE file.

License Guidelines

When adding new files to a repository, it's important to include the correct license information based on the repository's existing practices. As there is no standardized location or format followed across all repositories, please follow the steps below to ensure proper license usage:

  1. Check the Repository's LICENSE File:

    • All repositories include a LICENSE.md or LICENSE file. This file can contain the full license text or instructions on how to apply the license to new files.

    • If the repository provides the actual license content in the LICENSE.md file, this content can usually be copied directly into the new source files.

  2. Repositories with Additional License Explanations:

    • Some repositories have the actual license content along with additional explanations in the LICENSE.md file.

    • In such cases, refer to the existing source files in the repository to find the correct license content that should be added to the new files. This ensures consistency with the current files in the repository.

  3. Steps for Adding License to New Files:

    • If the repository has a consistent license format (visible in the source files), follow this format in the new file being added.

    • If the repository includes the full license content in LICENSE.md, use the relevant portion as a header in the new file.

    • For any uncertainties regarding which license to use, check the existing files or contact the repository maintainer for clarification.

  4. Contacting the Maintainer for Clarification:

    • If the correct license format is unclear, reach out to the repository maintainer via email or leave a comment on the pull request for further guidance.

If intentionally introducing a new type of license, please contact the maintainer via email or by leaving a comment on the pull request. This will enable the maintainer to evaluate the necessity of the new license type and offer appropriate guidance.

Auto comments from the license check script

  • Approved License: Indicates that the file contains an approved license.

  • Not Approved License: Indicates that the file contains a license that is not approved.

  • No License Change: Indicates that there is no change in the license content for modified files.

  • No License Content Found: Indicates that the added file contains no license content.

  • License Check Passed: The overall status indicates all licenses are approved.

  • License Check Failed: The overall status indicates one or more licenses are not approved.

 

 

 

 

© Copyright 2019 - 2022 Xilinx Inc. Privacy Policy