<!-- The EMO is using this template to track the status of Restructuring reviews. There's help in the Eclipse Foundation Project Handbook https://www.eclipse.org/projects/handbook/ Parts of this issue can initially be left blank to be filled in during the review. Set the title of this issue to the project's id, e.g., "technology.dash Restructuring Review" You can delete the comments (or not). --> ## Restructuring rationale <!-- Provide relevant links to the restructuring review, e.g. review record, public discussions, links to messages in the public mailing lists. --> **Keyple - restructuring review - more permissive license for extension APIs & usage examples** PMI link: [Project restructuring record](https://projects.eclipse.org/projects/iot.keyple/reviews/eclipse-keypler-2025.03-review) The project team is requesting a restructuring review to address the following issues: <!-- Provide a brief explanation of the reasons you need a restructuring review together with some context. --> **For Keyple 'extension API' and 'usage example' elements, we are requesting the possibility of adopting a more permissive license.** The Keyple project currently includes 43 repositories on GitHub: - 24 repositories contain the code for 24 active Keyple library components - 7 repositories correspond to Keyple API components - 2 repositories offering examples of best practice for implementing Keyple components - 2 repositories to host the project website - 6 repositories used for continuous integration - 2 archives of the first trial of the project, which was then in the form of a single library (before being split into multiple libraries, and before the introduction of extension APIs) |||| | ------ | ------ | ------ | |Component|API| keyple-common-java-**api** / keyple-common-cpp-**api** / keyple-distributed-local-java-**api** / keyple-distributed-remote-java-**api** / keyple-plugin-java-**api** / keyple-plugin-cpp-**api** / keyple-plugin-storage-card-java-**api** | |Component| Library | keyple-card-calypso-crypto-legacysam-java-**lib** / keyple-card-calypso-crypto-pki-java-**lib** / keyple-card-calypso-java-**lib** / keyple-card-calypso-cpp-**lib** / keyple-card-generic-java-**lib** / keyple-card-generic-cpp-**lib** / keyple-distributed-local-java-**lib** / keyple-distributed-network-java-**lib** / keyple-distributed-remote-java-**lib** / keyple-plugin-android-nfc-java-**lib** / keyple-plugin-android-omapi-java-**lib** / keyple-plugin-cardresource-java-**lib** / keyple-plugin-pcsc-java-**lib** / keyple-plugin-pcsc-cpp-**lib** / keyple-plugin-stub-java-**lib** / keyple-plugin-stub-cpp-**lib** / keyple-service-java-**lib** / keyple-service-cpp-**lib** / keyple-service-resource-java-**lib** / keyple-service-resource-cpp-**lib** / keyple-util-java-**lib** / keyple-util-cpp-**lib** / keypleless-distributed-client-kmp-**lib** / keypleless-reader-nfcmobile-kmp-**lib** | |Support| examples of use & good practice | keyple-java-**example** / keyple-cpp-**example** | |Support| Continuous Integration | .eclipsefdn / .github / keyple-actions / keyple-cpp-meta / keyple-integration-java-test / keyple-ops | |Support| Website | keyple-website / keyple-api-docs | |Archived Component| Library | keyple-java / keyple-cpp | All these repositories (except the otterdog setting repository) are currently published under the EPLv2 license. This is a choice that is perfectly suited to library-type components, for which it is important to offer behaviour guarantees for any integration, and for which any optimization or correction by a user needs to be shared with the community. - The API components are intended to enable the development of extensions to the Keyple project: these extensions must be able to be realized without license conditions. **→ we therefore propose to switch the 7 Keyple APIs repositories to the MIT license.** - Similarly, the point of the good practice examples for implementing Keyple components is that they should be massively adopted by users so that Keyple is properly integrated. There is no need modifications' restitution for these elements; on the contrary, the adoption must be facilitated. **→ We therefore propose to switch the 2 usage example repositories to the MIT license.** ## Expected infrastructure changes <!-- The project team should list the expected infrastructure changes in this section, e.g. new project name and shortname, which repositories to move, repositories that need to be archived, committer's databases to be merged/splitted, etc. --> The following infrastructure changes are requested by the project team: <!-- - Project name - Committers - Project repositories - CI instance - Mailing list --> - Other(s) - addition of the MIT license usage to the PMI page (https://projects.eclipse.org/projects/iot.keyple ) ## Restructuring To-Do list In order to implement the proposed changes, we need to complete the following: - [x] EMO (ED) approval - [x] PMC approval - [x] Project community informed using public channels (i.e. dev mailing list and/or forums) - [ ] Releng team informed (add @fgurr) - [ ] IT team informed (add @webmaster) - [ ] Infrastructure changes implemented <!-- If the restructuring review is related to a specification project you'll need the Specification committee approval - [ ] Spec committee approval -->