License for library plugins

[Basil Crow]

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?

[Olivier Lamy]

Regarding Apache librairies this can be anything but maybe better to
stick with original license if possible.

Please note for trademark reasons, the real name to use when
mentioning Apache software is not commons-foo but Apache commons-foo
Furthermore, it would be nice to include the LICENSE file in the
distributed hpi. I can't see it

unzip -l commons-text-api-1.11.0-95.v22a_d30ee5d36.hpi
Archive: commons-text-api-1.11.0-95.v22a_d30ee5d36.hpi
Length Date Time Name
--------- ---------- ----- ----
0 12-05-2023 16:35 META-INF/
1082 12-05-2023 16:35 META-INF/MANIFEST.MF
0 12-05-2023 16:35 WEB-INF/
0 12-05-2023 16:35 WEB-INF/lib/
0 12-05-2023 16:35 META-INF/maven/
0 12-05-2023 16:35 META-INF/maven/io.jenkins.plugins/
0 12-05-2023 16:35
META-INF/maven/io.jenkins.plugins/commons-text-api/
246659 12-05-2023 16:35 WEB-INF/lib/commons-text-1.11.0.jar
2622 12-05-2023 16:35 WEB-INF/lib/commons-text-api.jar
947 12-05-2023 16:35 WEB-INF/licenses.xml
2362 12-05-2023 16:35
META-INF/maven/io.jenkins.plugins/commons-text-api/pom.xml
88 12-05-2023 16:35
META-INF/maven/io.jenkins.plugins/commons-text-api/pom.properties
--------- -------


It's in the git repo, but it is not included in the distribution,
which is usually a good idea when redistributing Apache software or
even in this case, when the repackaging is under Apache license.

> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrSPdWJFoJpxx3YtyqKuQ7r49Cai30mfvXg1yUP2CcFQw%40mail.gmail.com.

--
Olivier

[Mark Waite]

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 from MIT to Apache.  A stackoverflow article 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

[Jesse Glick]

On Tue, Dec 12, 2023 at 7:44 AM Mark Waite <mark.ea...@gmail.com> wrote:

The changes made to wrap the library into the plugin are usually not very large

Well. In https://github.com/jenkinsci/apache-httpcomponents-client-4-api-plugin/blob/d43026ee871292547b224f11d6a2016303720165/src/main/java/io/jenkins/plugins/httpclient/RobustHTTPClient.java#L2-L4 for example the code does not consist of “changes” to the wrapped library, it is fresh Jenkins-specific development; and while not large it is certainly not trivial (well above the threshold considered significant for copyright). I think it is appropriate for the plugin to remain under the  MIT license like most of the rest of Jenkins code. Obviously the JAR it bundles is under a different license, but so what? The license refers to the source files in the repository.

As to plugins which bundle a third-party library and have absolutely nothing in `src/` other than `src/main/resources/index.jelly`, I guess it is less confusing to just mark the plugin with the same license, though I am not sure it makes any practical difference since the only conceivably significant “source” would be in `pom.xml` and this is most often pure boilerplate plus predictable `<dependencies>`. (Or `cd.yaml`, which is almost always just a copy from template.)

[Basil Crow]

This is a subjective question, but I feel that when the only thing in
src/main is src/main/resources/index.jelly the wrapper should be
licensed the same way as the library being wrapped, because our own
contribution to production code is de minimis. It seems strange to use
a different license when our unique contribution is just build/test
code. In cases where our contribution to src/main is nontrivial then I
am fine with applying our own MIT license to the plugin.

[Basil Crow]

I proposed a (soft) recommendation to the documentation in
https://github.com/jenkins-infra/jenkins.io/pull/6936.

[Mark Waite]

On Tuesday, December 12, 2023 at 6:37:18 AM UTC-7 Jesse Glick  wrote:

I like that very much.  That would keep the Apache HTTP Components 4 library as MIT licensed but might guide other plugins to adopt the license of the library they wrap.