Address Licensing/ToS

[brian-comply0]

Description

As an adopter of the OSCAL REST OpenAPI Specification I need some assurance that this specification will remain open sourced following my adoption of it, so that I can invest in creating an implementation without losing the right to continue using the standard in the future.

Acceptance Criteria

• [ ] An appropriate license has been selected.
• [ ] Terms of Service has been discussed
• [ ] The OpenAPI specification file includes license information in the info section
• [ ] If a ToS is needed, the OpenAPI specification file includes TOS information in the info section

Additional Notes

The following key considerations should also be addressed:

• we need to assure adopters that the spec will remain free and open after they invest time/resources in adopting (perpetual?)
• adopters should have to follow the spec strictly to claim compliance (not typically covered in licensing terms, but would be great if we found a way to ensure this)
• orgs who modify the spec on their own shouldn't be able to claim its a new version of the spec (companies should be able to create a variation that gives them a competitive advantage, and then push it on others)
• adopters shouldn't have to worry about copyright attribution

[brian-comply0]

This is the syntax for ToS and license information is:

- info
  - termsOfService: https://example.com/terms/
  - contact:
    - name: API Support
    - url: https://www.example.com/support
    - email: support@example.com
  - license:
    - name: Apache 2.0
    - url: https://www.apache.org/licenses/LICENSE-2.0.html

[brian-comply0]

Note, this repository already shows it is covered under the Creative Commons license https://github.com/EasyDynamics/oscal-rest/blob/develop/LICENSE.

For now, I have updated the OpenAPI spec to include this statement and the above link. We should still revisit this with our lawyers at an appropriate time.

For now, I think it is important for anyone electing to adopt the specification that they can do so without fear of losing the rights to use it later.

[brian-comply0]

Addressed in PR #99