You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Correctness and Quality - the content must work and appear as described and meet a minimum quality bar to prevent spam, duplication and meet user expectations.
Security and Privacy- the content must not be malicious or compromise the privacy of users per the O3D Foundation’s security and privacy policies.
Legal - the content must have an O3D Foundation compatible license and meet O3D Foundation legal restrictions including the O3D Foundation’s restrictions on patent-encumbered code, restricted proprietary content, age-limited content and content ownership. O3D Foundation also determines the terms the submitter accepts when submitting content.
What is the motivation for this suggestion?
The O3DE community owns and maintains many optional gems, projects and templates that are useful but do not belong in the main o3de repository and are instead hosted in other repositories like o3de-extras.
This approval process can be used as a model for other O3DE remote repositories, especially those with different licenses and ownership requirements.
Suggestion design description:
Initially, SIG content will define and own the approval process until a new SIG is formed or chosen that is more suited.
To add/update/remove content, a user will create a GitHub PR in the https://github.com/o3de/canonical.o3de.org repository from a pre-existing template for adding/updating/removing content.
The approval PR will target the development branch which is used for staging/testing.
Before the GitHub PR can be merged it must:
Have an automated GitHub Action run that attempts to verify O3D Foundation content policies:
scans for viruses and restricted code that uses licenses that are incompatible with O3DE or comes from external sources with incompatible licenses or usage.
validates content requirements based on the type of content (gem, project, template, etc.)
the o3de python module has .json validation functions for each content type
checks for duplicates and possible spam
Be downloaded and checked by a SIG content maintainer or reviewer to verify
the contributed code and/or art abides by the O3DE contribution guidelines and policies.
if code is included, the code compiles and functions as described - exhaustive testing is not required
all new 3rd party dependencies are available via a package source the user has already approved or the O3DE 3rd party package system
An example of an already approved package source would be a built in Linux package source from the Linux distro provider like the Canonical repositories for Ubuntu.
if art is included it works in O3DE and Asset Processor does not throw errors
if the content uses a source_control_uri, that the source_control_ref is a git commit hash
no pre-built binaries from outside sources are including in the content or archive. Any pre-built binaries should be compiled and signed by O3DE.
included CMake scripts do not download additional content that has not been approved or is not hosted by O3DE
If an archive (.zip) is submitted, after validation, the archive is uploaded to the O3DE binaries S3 bucket so the content cannot be changed maliciously and so that it can be retrieved from a URL bearing an O3DE affiliated certificate.
It is recommended that archive files submitted for approval are publicly available in a GitHub release in the same GitHub repository that hosts the source for the content
It is recommended that archive files should include a SHA256 hash to validate the contents and be GPG signed to validate the source.
After the GitHub PR part of the approval processes is complete the changes are merged to the development branch where the changes can be tested.
Testing using the latest compatible release of O3DE on the primary platform for the content should at minimum include:
downloading the content verifying the SHA256 hash is correct
any new Gems can be added to a project and it compiles if needed and the Editor opens and the content is available
any new Project compiles and the Editor opens
any new Templates can be used to create viable Gems or Projects
When testing is complete, the changes are reverted or fixed if testing fails, otherwise the changes are merged to the main branch making the changes publicly available.
Content meets the O3DE requirements for public distribution
What are the disadvantages of the suggestion?
Time, resources and effort are required to validate and approve content
Are there any alternatives to this suggestion?
A standalone website with database backend could be created with forms similar to Godot's asset library
This approach requires more resources and effort than we currently have
The 3rd party package system could be used
The 3rd party system is primarily set up for hosting source and binaries and not art, but it is hosted in S3 so it's possible the approval processes could be combined.
check how recently the user account was created - spam bot accounts will usually be recent
How do we handle commercial licenses and closed source?
This initial approval process for https://canonical.o3de.org/ is designed to support content that is compatible with the O3DE contributor guidelines for code, which does not allow for commercial licenses or closed source.
As part of the RFC we should gauge the interest of O3DF members in supporting commercially licensed content as part of https://canonical.o3de.org/, a separate O3DE remote repository, or multiple remote repositories not owned by O3DF.
How do we handle monetized content (can owners sell or gate stuff behind paywalls)?
Currently this is capability is not included in the https://canonical.o3de.org/ repository and we should discuss if we want to mix that content with completely free and open source content, or keep the O3DE canonical content compatible with O3DE contributors guidelines and use non-O3DE controlled remote repositories for everything else.
For example, PopcornFX and Kythera both provide gems under different licenses and if O3DE were to take on hosting and management of this kind of content there may be additional legal and security considerations. It may be simpler for O3DE to recommend remote repositories that are managed by PopcornFX and Kythera where they manage their own content.
The text was updated successfully, but these errors were encountered:
Summary:
Publicly available remote content hosted in https://github.com/o3de and in https://o3debinaries.org/ that is linked to from https://canonical.o3de.org/repo.json must be approved following an established process to ensure:
What is the motivation for this suggestion?
Suggestion design description:
Initially, SIG content will define and own the approval process until a new SIG is formed or chosen that is more suited.
To add/update/remove content, a user will create a GitHub PR in the https://github.com/o3de/canonical.o3de.org repository from a pre-existing template for adding/updating/removing content.
The approval PR will target the development branch which is used for staging/testing.
Before the GitHub PR can be merged it must:
After the GitHub PR part of the approval processes is complete the changes are merged to the development branch where the changes can be tested.
When testing is complete, the changes are reverted or fixed if testing fails, otherwise the changes are merged to the main branch making the changes publicly available.
Technical design description
The https://github.com/o3de/canonical.o3de.org repository does not contain any actual content, just the repo.json file that links to content hosted in https://github.com/o3de repositories and in https://o3debinaries.org/
The repo.json in the main branch of https://github.com/o3de/canonical.o3de.org is made public using AWS S3 and CloudFront
The engine.json in https://github.com/o3de/o3de contains the https://canonical.o3de.org/ remote repository URL so that every user has access to the content in the main branch by default
When content is staged in the development branch users can test it by adding the remote repository URL https://raw.githubusercontent.com/o3de/canonical.o3de.org/development/src
What are the advantages of the suggestion?
What are the disadvantages of the suggestion?
Are there any alternatives to this suggestion?
What is the strategy for adoption?
Are there any open questions?
As part of the RFC we should gauge the interest of O3DF members in supporting commercially licensed content as part of https://canonical.o3de.org/, a separate O3DE remote repository, or multiple remote repositories not owned by O3DF.
For example, PopcornFX and Kythera both provide gems under different licenses and if O3DE were to take on hosting and management of this kind of content there may be additional legal and security considerations. It may be simpler for O3DE to recommend remote repositories that are managed by PopcornFX and Kythera where they manage their own content.
The text was updated successfully, but these errors were encountered: