Clarification on open source licensing regard to copyleft (AGPLv3)

[imcotton]

While preparing the draft for my project submission proposal, I encountered the following license requirements:

OSI-approved permissive open source licenses, Apache 2.0 by default

This requirement was unexpected, as I did not anticipate that GPL licenses would be excluded by a subsidiary of the Linux Foundation (the OWF).

The project (https://sign-poc.js.org) I am preparing is licensed under AGPLv3 (SPDX ID: AGPL-3.0-only). My general open source licensing practices are:

• MIT: For libraries, SDKs, or trivial samples
• AGPL: For fully functional applications or websites

This project is a frontend-only static web application that functions as a standalone OAuth IdP, interacting only via URL redirections.

I would like to confirm if the license requirement is rigid in this context. If so, it would be helpful to highlight this restriction in the foundation's guidelines.

Disclaimer: As the solo independent developer who holds the full copyright for this project, while re-licensing is possible, it would be considered only as a last resort.

[tkuhrt]

@imcotton : Thank you for opening this issue. We talked about this in today's Technical Advisory Council meeting (recording). We have not come to any conclusion at this point regarding the license requirements. We will keep you informed if we do make any changes. If we do keep it as is, where are you suggesting that we add details on the restriction?

[imcotton]

Appreciate the TAC’s efforts and attention in addressing the topic.

Given the Linux Foundation's emphasis on supporting a broad range of open-source licenses and promoting inclusivity, the rationale behind the exclusion of non-permissive licenses, such as the A/GPL, from the current documentation is not entirely clear. I only became aware of the license requirements while completing a draft proposal submission through the issue template, rather than finding them in the Foundation's core mission statement.

It would be helpful to understand whether this decision was made with specific intent or if it was an unintended gap. If this choice was deliberate, the guidelines should specifically highlight the decision, with detailed reasoning linked in the documents. This approach would ensure clarity and transparency, helping contributors better understand how this aligns with the Foundation's broader mission of fostering an inclusive open-source ecosystem.