User License Elections proposal

[jeremyong-az]

User License Elections

Problem Statement

O3DE, being an open source project, is predominantly powered by open-source code and open-source dependencies. However, it is impractical to restrict all runtime license usage strictly to open-source licenses. Some binary redistributable libraries may be needed in a shipping product, including for example:

• The DirectX12 runtime
• NVIDIA’s Aftermath DLL
• The Windows PIX event runtime

The usage of these binaries and associated headers may require the user to accept a license before compiling and using the engine. Currently, the user would be required to download these dependencies manually, passing dependency paths to the CMake configuration step to use.

What we would like is a more turnkey approach, which does much of the heavy lifting of fetching, configuring, and building the dependencies as needed, while still gating product usage until the user accepts all relevant licenses. In the case that a dependency is optional, rejecting the license should simply cause the project to build and run without the optional dependency. A mechanism is also needed for the user to elect a different set of licenses at a later point in time, with the project build configuration adjusting accordingly.

Proposed Solution

A new user_license_elections.json file in the user’s .o3de config folder will be used to indicate the acceptance status of each dependency with a non-OSS license. This file may be different depending on the host platform, and the general structure of the file looks like:

// .o3de/user_win32_license_elections.json
{
    licenses: [
        {
            "name": "WinPixEventRuntime",
            "required": false,
            "purpose": "The Windows PIX event runtime is used to provide data for CPU and GPU profiling, debugging, and instrumentation with the PIX tool.",
            "version": "1.0.220124001",
            "license_uri": "https://www.nuget.org/packages/WinPixEventRuntime/1.0.220124001/License",
            "accepted": false
        },
        {
            "name": "Microsoft.Direct3D.D3D12"
            "required": true,
            "purpose": "The D3D12 runtime is required to leverage the latest features and validation with the Windows D3D12 RHI backend.",
            "version": "1.606.3",
            "license_uri": "https://www.nuget.org/packages/Microsoft.Direct3D.D3D12/1.606.3/License",
            "accepted": true
        }
    ]
}

The file contains an array of objects, associated licenses, version data, a URI referring to the license. Crucially, each entry in the array has an accepted field with a simple boolean value indicating if the user has accepted the license terms for that entry. By default, licenses are not accepted.

Specifying the licenses themselves occurs on a per-gem basis, leveraging a similar format to the file above (possibly using the setreg mechanism). These files are aggregated as part of the configure or install process, and the elections themselves are defined using a process described next.

Accepting licenses occurs via two mechanisms, modifying the file entries above via script or installer, or passing CMake variables that indicate license acceptance. If using the installer, the user must be prompted with a screen listing each dependency, with a link to view the license, a brief description about the dependency usage, and a checkbox to either accept or reject the license. The elections are checked at configuration time in CMake. If a required dependency isn’t met, the configuration will terminate immediately with an error message indicating what went wrong.

To avoid needing multiple configuration attempts to discover what licenses are needed, the O3DE CMake file will populate required and optional licenses early-on, prior to configuration other targets. If user intervention is needed, the configuration will emit an error message and fail immediately with instructions on how to proceed. Among the existing scripts for managing project registry settings, two additional scripts will be provided to accept all licenses, or strictly required ones. Later, an interactive script may be provided to interactively make an acceptance election on licenses one at a time. Early on though, the burden of additional licenses is expected to be small, so this interactive script may be deferred till a later time.

Finally, as an alternative to modifications to the configuration file above, individual licenses may be accepted by passing appropriate CMake variables directly at generation time (either via the CMake GUI configurator or on the command line). The general structure of the CMake variable tied to a particular license is ACCEPT_LICENSE_[LICENSE_NAME]_[VERSION]. While cumbersome to type, it would be discoverable through the CMake GUI and storable in a presets file.

To make additions, modifications, or deletions from the authoritative license elections file, TSC approval is needed. This already would be the case given that licenses outside MIT and Apache 2 licenses are subject to TSC approval, but we are mentioning this again here for clarity.

FAQ

• Are non-OSS runtimes/libraries really required?
  • Yes, for all practical purposes. For DX12 for example, all new features are being deployed against the new runtime with redistributable license requirements. Note that we already depended on such licenses, but the mechanism to require the user accept the external agreement was generally provided through outside means. In the case of DX12, users accepted that agreement prior when installing the Windows SDK through the Visual Studio installer.
• What if a user elects not to accept an agreement?
  • Such a user will still be able to use the engine on platforms that do not carry the same requirements.
• How will the dependencies themselves be distributed?
  • This proposal/RFC is independent of the mechanism by which O3DE distributes packages, which could be through the 3p-package-source repository, the use of CMake’s FetchContent module, or some other mechanism entirely.
• Will requiring manual license elections become the norm?
  • No. Such dependencies are included only as a last resort if there are no other options. Note that for optional dependencies, we may adopt a more relaxed stance, especially for tooling support. In general though, as an OSS project, O3DE will continue to prioritize OSS solutions.

[jeremyong-az]

TODO: Clarify where licenses are stored (on gems) and setreg/cmake implications. (this is done)

[moraaar]

I think this is a great proposal to make easier to deal with non-OSS licenses in O3DE. Having to manually download 3rdParty SDK/libs, install them, or place them in the right folders, is a very tedious process for users. The setup of the engine should be as easy, seamless and quick as possible.

One of the main points when to check for non-OSS licenses could be when enabling gems. For example, DirectX12 runtime dependency comes from Atom gem (on windows platform only), if some customer doesn't need to enable Atom gem for whatever reason then they shouldn't need to accept DX12 license.

For gems that are distributed enabled by default (like Atom) I guess the user would need to accept it at an earlier point. For gems not enabled by default, it seems fit that the system would ask to accept the non-OSS license when the user attempts to enable the gem and if the user declines the license then the gem just doesn't get enabled (that's if the license is mandatory for the gem to function, if it's an optional one the gem can still be enabled but with limited functionality).

[moraaar]

Another user case that I've encountered that would fit with this proposal is the Oculus OpenXR Mobile SDK, which is necessary for the OpenXR gem we are currently developing. At the moment the user has to go to the oculus website, accept the license, download the sdk and place it in an specific folder inside the gem. This is a very tedious setup process for the gem and it'd be great to improve this.

Lastly, I'd like to quickly mention Wwise and I think its gem for O3DE is a similar situation whose setup could also benefit from this proposal.

[moraaar]

[Just a thought] The proposal doesn't mention restricted platforms, but I was thinking that maybe there is a larger story here for this proposal to also accept restricted platforms SDKs in the future? It's ok if we don't want to dive into this yet, but I thought it was worth bringing it up as it might be worth keeping it under our radar.

[lemonade-dm]

I don't think we should get in between any agreements of a customer trying to access restricted platform SDKs with their vendors.
Primarily in that case, we can't download those SDKs on the user behalf.

This particular system is to streamline the process of a user accepting a non-OSS license and downloading a proprietary SDK for the user.

For restricted platform SDKs, this system doesn't provide any benefit for the user as O3DE cannot download the SDK for the user, futhermore it would potentially require exposing information about the SDK which gets into legal agreement gray areas I imagine thge O3DF would like to avoid.

[jeremyong-az]

Yea agreed, we won't be touching restricted platforms (only proprietary but available platforms for this initial proposal).

[lemonade-dm]

Can a user still use these redistributable libraries even when the license hasn't been accepted through SDK?
For the WinPixEventRuntime if the user already has it installed and therefore accepted the license between them and Microsoft, they shouldn't need to fill out another prompt with O3DE to use the WinPixEventRuntime.

Simply will the detection mechanism first detect if the redistributable is on the user machine before prompting them to accept a non-OSS license?

[lemonade-dm]

One other aspect I worry about is the "politics" side that determines what gets added to license file.
There could be conflicts between commercial partners and open-source partners about making license elections available on Linux.

[jeremyong-az]

The WinPixEventRuntime version actually needs to be locked with the engine due to API changes, so here we would want to vendor it like any other 3p library (similar to the dx12 runtime). As for politics, the TSC being the final arbiters would definitely need to take that into consideration for every library approved for use with this mechanism and OSS partners would be part of that conversation.

[tkothadev]

Would we also want to consider a similar mechanism on a per project basis? I could see a user having different preferences depending on the kind of project they're making.

[jeremyong-az]

Good question. This was discussed briefly at a recent meeting. I think it'd be useful to have such a mechanism eventually, but imagine it's an unlikely use case that would add complexity (license elections may be per-project, or per-engine install). At least for the SDKs proposed currently, I'd estimate that the folks that wouldn't actually be comfortable with, e.g. the WinPixEventRuntime when developing on Windows is effectively 0%, but we still need to secure the user's permission to vendor the SDK on their behalf. When we actually draft the official RFC, we can solicit more feedback on this point from community members in SIG build and SIG platform.