Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[REQ] Support for code licensing

See original GitHub issue

Is your feature request related to a problem? Please describe.

OpenAPI v3 supports supplying licensing information.

Describe the solution you’d like

It would make sense to propagate this information into the generated code, for example creating a LICENSE file in the root of the package, also allowing the generators access to this information, for example in php you’d add the license information to composer.json.

Issue Analytics

State:
Created 3 years ago
Comments:8 (8 by maintainers)

Top GitHub Comments

1reaction

dkarlovicommented, Oct 20, 2020

Sure, not a problem, seems like a weird middle ground to me, but that’s just my POV.

0reactions

jimschubertcommented, Oct 20, 2020

Yeah. It’s one of those weird things where we assume adding the license is the right thing to do, but it carries far more weight.

As I said, we pass all details from the input spec to the templates. If a user is doing spec-first development, they can easily pull the license into a generated source file via custom templating. Since we’re just passing along properties, we’re not “owning” anything about license application. It’s really the best option we have which will cover things for the whole community and remove the maintenance burden from the tool.

I agree licensing the code makes the most sense. I’d begun a separate tool which users could run on a repo before releasing or open sourcing: https://github.com/jimschubert/ossify/. I put the idea aside when the pandemic started because I have two small kids and a little less time for open source.