On Monday, December 11, 2023 at 12:50:10 PM UTC-7 Basil wrote:
Library plugins are inconsistently licensed: sometimes, they adopt the license of the wrapped library, while in other cases, they follow the MIT license as normally used by Jenkins plugins. Does anybody have a preference as to what we should recommend? I think that we should recommend that the library plugin should use the same license as the wrapped library. The changes made to wrap the library into the plugin are usually not very large and it feels more consistent to me to use the license from the larger body of code that is being wrapped. In this case, I'm favoring the license of the wrapped component over the MIT license preference of Jenkins core and the Jenkins project. In order to match that recommendation, I would need to change the license of the Apache HttpComponents Client 4.x API plugin <https://plugins.jenkins.io/apache-httpcomponents-client-4-api/> from MIT to Apache. A stackoverflow article <https://opensource.stackexchange.com/questions/7384/proper-way-of-migrating-mit-licensed-code-to-apache-2-0-license> indicates that the Apache license is a superset of the MIT license, so I think it would be enough to change the license text from MIT to Apache, without asking each of the contributors if their contribution can be assigned the Apache license. Are there special steps that need to be taken when changing a license from MIT to Apache? Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5aea3749-979e-4d85-b971-8c98ecc0f10fn%40googlegroups.com.
