accept all OSI approved licences

[jamesgeddes]

I would like to propose that we expand the set of licences that OpenTofu accepts for providers to include all those approved by the Open Source Initiative (OSI), rather than the currently permitted subset.

The current restrictions exclude a number of OSI-approved licences, which creates a barrier for contributors whose work is licensed under these terms. For example, all of the code I publish is licensed under the GPL or AGPL, which means I am currently unable to contribute a provider to the project, despite its compliance with OSI’s definition of open source.

I tried to find a rationale for this limitation, but I was unable to locate any explanation in the documentation, issue history, or discussions. If this has already been considered, I apologise for missing it, and would appreciate being pointed to the relevant context.

To support any technical implementation, I have contacted the Open Source Initiative to ask whether they can provide an authoritative, machine-readable list of all OSI-approved licences. If such a source is available, it could simplify validation and help ensure our policy remains aligned with widely recognised standards.

I believe accepting all OSI-approved licences would be a more inclusive and consistent approach that reflects the values of the broader open source ecosystem, and I hope it is something we can consider.

[Yantrio]

Hi @jamesgeddes. Thanks for raising this.

Firstly, the code in this repository is only used to scrape the documentation that powers search.opentofu.org. If the license of the provider is not allowed by this reposistory then the provider would still be available just without documentation.

The reason we chose this limited set of licenses is to err on the side of caution, we were not sure around the defintion of "derivative works" of the documentation in these repositories and if allowing these licenses would have any implications for opentofu.

For this reason, we will still support the provider in the registry, but for now we do not display documentation on search.opentofu.org

[jamesgeddes]

Thank you for the clarification. I appreciate the cautious approach and understand that licensing questions can be complex, particularly where concerns about “derivative works” and documentation reuse are involved.

That said, I believe the current policy may be unnecessarily restrictive and not well-aligned with the wider open source ecosystem.

The licences currently permitted are all OSI-approved, which is a strong baseline, but several major OSI-approved licences, including the GPL, AGPL, and LGPL families, are excluded. These are widely used across the open source community, and the current restriction introduces inconsistency and may discourage participation from contributors whose work is licensed under those terms.

I fully understand wanting to avoid legal ambiguity, but in this case, I am not convinced that indexing or displaying documentation metadata for providers licensed under the GPL family constitutes a derivative work (IANAL). The registry is not incorporating GPL-licensed code into OpenTofu itself, it is simply listing metadata and rendering documentation, as many hosting platforms do (e.g. GitHub, GitLab, Docker Hub). This kind of use is widely accepted and does not typically trigger the derivative works clause of the GPL.

If the Open Source Initiative are able to share any advice or suggestions, that would be helpful in providing clarity on this point, both regarding the implications of displaying provider documentation, and in supporting a move toward a more consistent licence policy.

In the meantime, I would strongly encourage OpenTofu to consider adopting a policy that defers to OSI approval by default, unless there is a specific, documented legal concern that warrants exclusion. This would promote consistency, reduce uncertainty, and align with broader open source norms.

Thank you again for taking the time to respond and for your work on the registry.

[apparentlymart]

For the sake of comparison, the Go project also has a policy for what licenses they consider acceptable for rendering documentation on their closest equivalent of our registry UI, pkg.go.dev: https://pkg.go.dev/license-policy

I note both that they accept various specific whole-project copyleft licenses and they express that their intention is to accept all OSI-approved licenses on request, even if some are currently not accepted. I gather from previous discussion on this policy that it was crafted in collaboration with Google's legal team, but of course I don't know exactly what was discussed and prioritized in that collaboration.

Of course this is much more a legal question than a technical question and so I imagine we'd need to seek legal advice on any change to the current policy rather than unilaterally making a decision immediately here.

[jamesgeddes]

Agreed, this is indeed more of a legal question than a techincal one. I guess the Linux Foundation must have/have access to lawyers, right? How do we seek official advice on this?

[apparentlymart]

Yes, we do have access to lawyers already. By my comment I only meant that we're unlikely to be able to answer this question quickly because nobody who regularly monitors issues here is qualified to give legal advice, and so we'll need to discuss this elsewhere first and then report back.

[jamesgeddes]

Fair enough, thanks @apparentlymart . I will look forward to hearing further.