oscal-rest icon indicating copy to clipboard operation
oscal-rest copied to clipboard

Address Licensing/ToS

Open brian-ruf-ezd opened this issue 1 year ago • 1 comments
trafficstars

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-ruf-ezd avatar May 21 '24 20:05 brian-ruf-ezd

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: [email protected]
  - license:
    - name: Apache 2.0
    - url: https://www.apache.org/licenses/LICENSE-2.0.html

brian-ruf-ezd avatar May 21 '24 20:05 brian-ruf-ezd

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-ruf-ezd avatar Jun 03 '24 19:06 brian-ruf-ezd

Addressed in PR #99

brian-ruf-ezd avatar Jun 04 '24 14:06 brian-ruf-ezd