Clarification on the purpose of the API license?

[harrisj]

In the Swagger 2.0 specification, there is support for adding a License as one of the informational fields and the description for this is License information for the exposed API.

This seems a bit ambiguous, since a license could potentially be understood to apply to one or more of the following contexts:

1. Use of the API. This situation seems to be already handled by the termsOfService section though.
2. Data retrieved from the API
3. The specification JSON/YAML for the API indeed, there is a license for the Swagger 2 specification
4. Client/server code generated via swagger-codegen could some licenses theoretically extend to that?

I am guessing that the item 3 is the intended use for the license field, but I will admit that at first I thought it was meant for the first case and I could not see how a license would actually apply. Is it possible to get some clarification of how licenses should be picked here and where they do and do not apply?

[MikeRalphson]

I think the key word here is exposed.

1. Correct, covered by termsOfService
2. If covered at all this would also be via the termsOfService
3. My reading of the specification is that the license covers the entire design of the exposed API, so it would also include any features not included in the OpenAPI document [1]
4. In this case, generally not. Code generated by swagger-codegen is covered by the following clause:

When code is generated from this project, it shall be considered AS IS and owned by the user of the software. There are no warranties--expressed or implied--for generated code. You can do what you wish with it, and once generated, the code is your responsibility and subject to the licensing terms that you deem appropriate. [2] [3]

The license effectively tells you if/how you could re-implement and/or relicense the exposed API design.

[1] a PR to improve the clarity of the wording may be beneficial
[2] Other codegen projects will have their own licensing rules
[3] I suppose a custom license could attempt to forbid the use or distribution of generated code, but whether that would be enforceable is another matter

[MikeRalphson]

Closing due to inactivity - but please feel free to reopen the issue if necessary.

[adulau]

I would like to reopen this because it's still very unclear in the specification of what is exactly the license coverage:

• The data exposed via the API
• The API design (which I doubt as this is clearly not original enough to be covered by copyright)
• The back-end software of the API

Is there an archive somewhere where the license field has been added and the reasoning behind?

[StephanBijzitter]

I second this question. I'm creating a definition for an internal api that third parties (customers of ours) can get access to to manage their accounts/information. The code itself is never exposed; only the swagger .json file is loaded and that's really it. What's a license got to do with that?

[frankreno]

Agree with the above comments on this issue. The current definition of license in the docs is too vague and does not offer what it should be about. This issue should be reopened to be looked at to make the documentation more explicit and concrete on the purpose of this field.

[darrelmiller]

The license effectively tells you if/how you could re-implement and/or relicense the exposed API design.
I agree with Mike's comment regarding the intent of the license. The API description is a creative artifact that is not all that different to source code.

There seems to be support for clarifying the wording in the specification, so let's find some text that folks are comfortable with. Would the following addition be sufficient?

4.8.4 License Object §
License information for the exposed API. The referenced license defines acceptable usage of the API description.

[IMSoP]

4.8.4 License Object §
License information for the exposed API. The referenced license defines acceptable usage of the API description.

This feels almost contradictory to me - the first sentence says it's for "the API", the second is for "the API description". Do you need the first sentence at all if you have the second?