Keyple - license for extension APIs and demonstration examples
All Eclipse Keyple project repositories are defined under the EPL-2 license. We attach great importance to the “copyleft” property of this license for Keyple library-type components, so that any improvements or modifications are returned to the project.
The Keyple project also implements the APIs defined by the Eclipse Keypop project: the Keypop project contains only interfaces. When we initiated the Keypop project, we followed the EMO team's advice to adopt the MIT license for the Keypop’s components. This was a very good choice, as the aim was to offer a high degree of permissiveness for solutions implementing the Keypop APIs. We have had feedback from manufacturers who have been able to adopt these interfaces thanks to this permissiveness.
The Keyple project currently includes 37 GitHub repositories:
- 30 repositories hosting code for components :
- 6 APIs
- and 24 libraries
- 7 support repositories
- 2 repositories hosting code for demonstration examples
- 3 repositories to manage the continuous integration process
- and 2 repositories to host the project website
| API Component | 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 |
| Library component | 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 |
| examples of use & good practice | keyple-java-example / keyple-cpp-example |
| Continuous Integration | keyple-actions / keyple-cpp-meta / keyple-integration-java-test |
| Website | keyple-website / keyple-api-docs |
At present, all these 37 repositories are licensed under the EPL, but the elements that really need copyleft protection are the 24 library components.
The purpose of these 6 Keyple APIs is to enable extensions to be implemented for the Keyple solution.
- The Keyple project includes some extension libraries that implement these APIs.
- But these APIs are also intended to be implemented by third-party extensions that may not be open source. To fully meet this need, it would therefore seem more appropriate to switch these 6 APIs currently licensed under the EPL to the MIT license.
Likewise, for the 2 example repositories, copyleft is unnecessary: the idea is for users to be inspired as much as possible by the best practices of these examples in their Keyple-based solutions. I therefore think it would be useful to switch these examples to the MIT license as well.
For the continuous integration and website repositories, I have no opinion on the appropriate license. Would you have an opinion?
The project's PMI page indicates that the project's content can be licensed under BSD-3 and EPL: this choice had been made at the start of the project to allow permissiveness. But in the end, probably due to a lack of know-how, we set all repositories under EPL license by default. Even if BSD-3 and MIT have a similar permissiveness, I think the MIT license is better suited to extension API licenses and implementation examples.
So,
- Can I switch the API and example repositories of the Keyple project to the MIT license (by updating the license file of the concerned repositories)?
- Does the PMI page need to be updated?
